From noreply@sourceforge.net Sun Jul 1 17:18:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Jul 2001 09:18:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-432786 ] Python 2.1 test_locale fails Message-ID: Bugs item #432786, was opened at 2001-06-13 07:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432786&group_id=5470 Category: Extension Modules Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Paul M. Dubuc (dubuc) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.1 test_locale fails Initial Comment: I'm building Python 2.1 on Solaris 2.6. When I 'make test', the test_locale module is the only one that fails: test test_locale failed -- Writing: "'%f' % 1024 == '1024.000000' != '1,024.000000'", expected: '' ... The actual stdout doesn't match the expected stdout. This much did match (between asterisk lines): ********************************************************************** test_locale ********************************************************************** Then ... We expected (repr): '' But instead we got: "'%f' % 1024 == '1024.000000' != '1,024.000000'" ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-01 09:18 Message: Logged In: YES user_id=21627 The official ISO POSIX locale definition for en_US is at ftp://std.dkuug.dk/i18n/WG15-collection/locales/en_US In this file, you can see thousands_sep "<,>" grouping 3;3 So clearly, Solaris and Irix don't comply with this definition. Unless the vendors have some good story for that deviation, I'd say it is a bug in these systems. It is not surprising they show the same bug, though - they probably use the same sources. ---------------------------------------------------------------------- Comment By: Robert Minsk (rminsk) Date: 2001-06-25 14:10 Message: Logged In: YES user_id=132786 The SGI has the same locale problem as Solaris. Is this a bug with the locale defination on linux? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-16 00:53 Message: Logged In: YES user_id=21627 That appears to be a bug in Solaris 2.6. To see the problem, please try the following program import locale locale.setlocale(locale.LC_ALL,"en_US") c=locale.localeconv() print c['grouping'],repr(c['thousands_sep']) In the en_US locale, the thousands separator *should* be a comma, but Solaris 2.6 reports that this locale has no thousands separator. For locale information, Python relies on what the operating system reports. As it is an OS bug, I'm closing the report as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432786&group_id=5470 From noreply@sourceforge.net Mon Jul 2 09:58:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Jul 2001 01:58:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-437472 ] MacPy21: sre "recursion limit" bug Message-ID: Bugs item #437472, was opened at 2001-06-29 14:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437472&group_id=5470 Category: Regular Expressions Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) >Summary: MacPy21: sre "recursion limit" bug Initial Comment: As of Python 2.0, the sre module had bug wherein a "RuntimeError: maximum recursion limit exceeded" would be raised whenever an expression matched something on the order of 16,000+ characters. The bug, nominally fixed in time for Python 2.1, is still present in MacPython 2.1, as evidenced by the following transcript copied from an interactive session with the interpreter. Note success with pre module, however. It makes me curious, since the bug appears to be fixed in WinPython 2.1, whether the correct source was used when compiling MacPython 2.1.... ========== Python 2.1 (#92, Apr 24 2001, 23:59:23) [CW PPC GUSI2 THREADS] on mac >>> import sre, pre, string >>> l = ["XXX", "%"*20000, "XXX"] >>> sre_regex = sre.compile(r"XXX.*?XXX") >>> match_object = sre_regex.search(string.join(l)) Traceback (most recent call last): File "", line 1, in ? RuntimeError: maximum recursion limit exceeded >>> ### Above error first reported upon release of sre with Python 2.0 ### >>> ### Bug supposedly fixed in Python 2.0.1 release (no Mac version, I know) ### >>> pre_regex = pre.compile(r"XXX.*XXX") >>> match_object = pre_regex.search(string.join(l)) >>> match_object >>> ### Note above success with pre module instead of sre ### >>> ### Wrong sre module source used when compiling MacPython 2.1? ### ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-07-02 01:58 Message: Logged In: YES user_id=45365 When I try this in a MacPython build from the CVS repository the sre example does not crash, but match_object ends up as None. Also not the behaviour I expect... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437472&group_id=5470 From noreply@sourceforge.net Mon Jul 2 13:22:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Jul 2001 05:22:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-437879 ] SocketServer.py related problems Message-ID: Bugs item #437879, was opened at 2001-07-02 05:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437879&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer.py related problems Initial Comment: I tried several third-party proxy servers for Python (munchy,webdebug) go get working with Python 2.1 under Linux i386. But all fail with similar problems: Under 2.1: andreas@yetix:/home/andreas/src/munchy-0.7: python2.1 munchy.py 8006 Starting proxy on port 8006 Exception in thread Thread-1: Traceback (most recent call last): File "/opt/python-2.1/lib/python2.1/threading.py", line 378, in __bootstrap self.run() File "/opt/python-2.1/lib/python2.1/threading.py", line 366, in run apply(self.__target, self.__args, self.__kwargs) File "/opt/python-2.1/lib/python2.1/SocketServer.py", line 246, in finish_request self.RequestHandlerClass(request, client_address, self) File "/opt/python-2.1/lib/python2.1/SocketServer.py", line 494, in __init__ self.setup() File "/opt/python-2.1/lib/python2.1/SocketServer.py", line 537, in setup self.rfile = self.connection.makefile('rb', self.rbufsize) error: (9, 'Bad file descriptor') I could not track down the problem :-( Andreas ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437879&group_id=5470 From noreply@sourceforge.net Mon Jul 2 17:05:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Jul 2001 09:05:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn Message-ID: Bugs item #417845, was opened at 2001-04-21 08:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: Python 2.1: SocketServer.ThreadingMixIn Initial Comment: SocketServer.ThreadingMixIn does not work properly since it tries to close the socket of a request two times. Workaround for using SocketServer.ThreadingMixIn under Python 2.1: class MyThreadingHTTPServer( SocketServer.ThreadingMixIn, MyHTTPServer ): def close_request(self, request): pass ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-07-02 09:05 Message: Logged In: YES user_id=198402 There is still a problem with your solution, Mr glchapman: you make a copy to ensure that the server won't close the copy of the socket that is used in the child thread. Right. But WHO will close this very copy then? The thread still has to close it if one wants to be "clean". So as long as the child thread must close its copy in the threading case, why not make it a thumb rule? Why should we bother about closing anything in the main thread? I still think the solution that I provide is best: make the request handler always responsible for closing the socket from which the request comes. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2001-06-29 08:49 Message: Logged In: YES user_id=86307 Since the request socket object is only a lightweight wrapper around the real socket, why not simply pass request.dup() to the new thread? Then the server's call to close_request affects only its copy of request, not the copy being used in the thread. For example, the following change to ThreadingMixIn fixed this bug for me in a (very simple) test program: def process_request(self, request, client_address): """Start a new thread to process the request.""" import threading t = threading.Thread(target = self.finish_request, args = (request.dup(), client_address)) t.start() ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-28 05:20 Message: Logged In: YES user_id=198402 I have now started a project here concerning a SOCKS proxy written in python (PySocks). It is aimed mostly at people who use a windows box to share their internet connection and uses the threading server from the SocketServer module. So it becomes VERY important to me to know of what will be done about this bug, in the next release/patch of Python library. Could Mr Guido Vanrossum tell us about it? As for now I am forced to provide my patched version of SocketServer.py with my releases, what is not quite satisfactory. SocketServer is provided in the python distribution, so I'd rather tell "there is a patch for python..." Well... In fact I forgot to put it in my first release, but I'll correct this this evening :) ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-20 12:06 Message: Logged In: YES user_id=198402 Well I was wrong. We do need a "try" block to ensure the request is always correctly closed: def finish_request(self, request, client_address): """Finish one request by instantiating RequestHandlerClass.""" try: self.RequestHandlerClass(request, client_address, self) finally: self.close_request(request) This works better. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-13 09:09 Message: Logged In: YES user_id=198402 I forgot to tell: I can not test if it does not break the forking server. I only have a windows platform available for now, and forking doesn't work in the python/win32 environment for now as far as I know. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-13 08:51 Message: Logged In: YES user_id=198402 What I propose can be applied without any compatibility issue. I have tried something that seems to work, at least under windows (but it does need to be more fully tested though). Only 2 small modifications are required: -1- In BaseServer, modification of the last line of handle_request: 
    def handle_request(self):
        """Handle one request, possibly blocking."""
        #import time
        try:
            request, client_address = self.get_request()
        except socket.error:
            return
        if self.verify_request(request, client_address):
            try:
                print 'handle 1'
                self.process_request(request, 
client_address)
                print 'handle 2'
            except:
                self.handle_error(request, client_address)
                self.close_request(request)
Note that only the indentation of the last has been modified so that the close_request is executed only if an exception occur. Still we need to close the request after it had been processed, so here comes the second modification: -2- Still in BaseServer: 
    def finish_request(self, request, client_address):
        """Finish one request by instantiating 
RequestHandlerClass."""
        self.RequestHandlerClass(request, client_address, 
self)
        self.close_request(request)
There is already a try/except block in handle_request, so I thought it was not mandatory here to ensure the request was always closed. Oh... I don't know how <PRE> tags are supported by the bugtracking system of sourceforge, so the samples I give may not appear as I want. This is quite a problem with python :/ ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-12 15:46 Message: Logged In: YES user_id=80200 hi there mr xlagraula, yes, it would be a lot simpler... _if_ it wasn't for the fact that this code is likely to already be quite extensively used. a possible 'upgrade' path could be done by providing a... RequestHandler2 class, or some-such. it would be neater to do this, or similar: for t in self.thread_list: t.join(timeout=0.1) which would join all threads, or you do if stopped(), close_request. i looked into threads a bit more: join has a timeout, and there is a stopped-detection function. easy :) ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-12 14:18 Message: Logged In: YES user_id=198402 Another solution could be to modify the behaviour of the server so that it would be the responsibility of the "child" thread/process to close the socket (except for the forking/threading error cases). Wouldn't it be simplier than child process tracking and thread tracking? ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-04 04:17 Message: Logged In: YES user_id=80200 okay. the forkingmixin code does a fork, records how many children there are, and waits for one of them to exit, before proceeding - in particular, before proceeding to close the request, etc. ... so why is not something similar done in ThreadingMixIn? this kinda- tells me that thread-tracking is really needed, in a similar way to that in forkingmixin. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2001-05-03 16:26 Message: Logged In: YES user_id=413 Just a note of another casualty of this bug: I had to add the mentioned dummy close_request method hack to our own ThreadingMixIn class in mojo nation (in the sourceforge mojonation project's evil module, see the common/MojoNationHTTPServer.py file). Without it, python 2.1 would always raise an exception in the request handler as soon as it tried to call self.connection.makefile() because self.connection had apparently already been closed! (its fd was always -1) ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-02 01:41 Message: Logged In: YES user_id=80200 hi there mr jrielh, thank you very much for the details. what i am having a little difficulty with is, what's the difference between this and python 2.0 SocketServer.py? more specifically, i'm looking at python 2.0 SocketServer.py and, whilst i'm not a Threads expert, i see a t.start() but no t.join(). i've been looking at the Queue example code in the test method of threads.py, and start() is called on every thread, followed by join() on every thread. join waits for the thread to finish, yes? so... if that's the case, then python 2.0 SocketServer.py should suffer from exactly the same behaviour, yes? unless python behaves ever-so-slightly differently (timing issues?) when you have an extra base class like this, with the consequence that close_request() is more likely to be called before ThreadingMixIn.process_request(). ? ---------------------------------------------------------------------- Comment By: Jon Riehl (jriehl) Date: 2001-05-01 14:20 Message: Logged In: YES user_id=22448 This is related to bug #419873. The problem is not specifically in the ThreadingMixin specifically, but where BaseServer calls close_request() after calling process_request(). In the threading mixin, process_request() spins the thread and returns, causing the request socket to be invalidated while the thread is still running. The fix given above will keep the socket valid while the thread is running, but may cause the socket to not close properly (my threads generally close the socket when they are done anyway.) ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-04-26 05:41 Message: Logged In: YES user_id=80200 follow-up. i took a look at the differences between SocketServer.py in 2.0 and 2.1. there is one small change by guido to the ThreadingMixIn.process_request() function that calls self.server_close() instead of explicitly calling self.socket.close(), where TCPServer.server_close() calls self.socket.close(). if mr anonymous (hi!) has over-ridden server_close() and explicitly closes the *request* socket, then of course the socket will get closed twice. the rest of the code-mods is a straightforward code-shuffle moving code from TCPServer into BaseServer: from examining the diff, i really don't see how bypassing close_request(), as shown above with the Workaround in the original bug-report, will help: that will in fact cause the request _never_ to be closed! the rest of this report is part of an email exchange with guido, quoted here: "the bug-report doesn't state whether python 2.0 worked and 2.1 didn't: it also doesn't give enough info. for all we know, he's calling close_request() himself or request.close() directly somewhere in his code, and hasn't told anybody, which is why he has to over-ride close_request() and tell it to do nothing. or he's closing the socket in the HandlerClass, in finish(), or something. we just don't know. either that, or his HandlerClass creates a socket once and only once, with the result that close_request() closes the one socket, and he's _completely_ stuffed, then :)" ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-04-26 04:11 Message: Logged In: YES user_id=80200 hi there, i'm the person who wrote the BaseServer class. guido contacted me about it: could you please send me or post here a working test example that demonstrates the problem. i assume, but you do not state, that you have tested your MyHTTPServer with python 2.0, please let us know, here, if that is a correct assumption. thanks! luke ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470 From noreply@sourceforge.net Mon Jul 2 19:10:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Jul 2001 11:10:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-437984 ] package name truncation to 50 chars. Message-ID: Bugs item #437984, was opened at 2001-07-02 11:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437984&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: chris tignor (ctignor) Assigned to: Nobody/Anonymous (nobody) Summary: package name truncation to 50 chars. Initial Comment: Truncation of package names to 50 characters once represented as strings becomes extremely confusing for development purposes, even more so when as it exists as an undocumented event. I request full package names be represented. Thank-you. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437984&group_id=5470 From noreply@sourceforge.net Mon Jul 2 21:56:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Jul 2001 13:56:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-438032 ] Documentation errors in module "profile" Message-ID: Bugs item #438032, was opened at 2001-07-02 13:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438032&group_id=5470 Category: Documentation Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Jesús Cea Avión (jcea) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Documentation errors in module "profile" Initial Comment: Python Library Referencia 2.1 (15 April 2001) Module "profiler". Page 258. In functions "print_stats()", "print_callers()" and "print_callees()", the parameter 'restriction' is optional. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438032&group_id=5470 From noreply@sourceforge.net Mon Jul 2 22:24:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Jul 2001 14:24:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-438032 ] Documentation errors in module "profile" Message-ID: Bugs item #438032, was opened at 2001-07-02 13:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438032&group_id=5470 Category: Documentation Group: Not a Bug >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jesús Cea Avión (jcea) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: Documentation errors in module "profile" Initial Comment: Python Library Referencia 2.1 (15 April 2001) Module "profiler". Page 258. In functions "print_stats()", "print_callers()" and "print_callees()", the parameter 'restriction' is optional. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-02 14:24 Message: Logged In: YES user_id=3066 Fixed in Doc/lib/libprofile.tex revisions 1.35 and 1.32.2.2. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438032&group_id=5470 From noreply@sourceforge.net Mon Jul 2 23:04:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Jul 2001 15:04:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-438050 ] configure doesn't look for poll.h in sys Message-ID: Bugs item #438050, was opened at 2001-07-02 15:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438050&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: David Dyck (dcd) Assigned to: Nobody/Anonymous (nobody) Summary: configure doesn't look for poll.h in sys Initial Comment: I was surprised to see python not build out of the box on this old libc5 system. seems to be a problem with configure finding poll.h If I manually add #include to "Modules/selectmodule.c" then make continues (Another workaround is to create a dummy /usr/include/poll.h that just #include's ) dd:dcd$ uname -a Linux dd 2.4.5-ac22 #2 Fri Jun 29 14:39:29 PDT 2001 i686 /lib/libc.so.5 -> libc.so.5.4.44* make[1]: Entering directory `/hdb2/jd/usr2/dcd/ftp2/python/Python-2.0.1/Modules' gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -I./../Include -I.. -DHAVE_CONFIG_H ./selectmodule.c: In function `update_ufd_array': ./selectmodule.c:319: sizeof applied to an incomplete type ./selectmodule.c:327: arithmetic on pointer to an incomplete type ./selectmodule.c:327: dereferencing pointer to incomplete type configure:1557: checking for poll.h configure:1567: gcc -E conftest.c >/dev/null 2>conftest.out configure:1563: poll.h: No such file or directory configure: failed program was: #line 1562 "configure" #include "confdefs.h" #include ---- ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438050&group_id=5470 From noreply@sourceforge.net Tue Jul 3 01:15:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Jul 2001 17:15:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-438083 ] uu module allows hostile paths Message-ID: Bugs item #438083, was opened at 2001-07-02 17:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438083&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: uu module allows hostile paths Initial Comment: hello, the uu module does not appear to do any checking on the file name included in the uuencoded data. as far as i can see, it allows absolute paths and will happily overwrite anything. you can pass file objects to it, but then the information about the file name is lost. i've attached a sketchy patch. -- erno@iki.fi ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438083&group_id=5470 From noreply@sourceforge.net Tue Jul 3 08:58:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 00:58:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-438164 ] Format operator % fails with unicode Message-ID: Bugs item #438164, was opened at 2001-07-03 00:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438164&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chema Cortés (chemacortes) Assigned to: Nobody/Anonymous (nobody) Summary: Format operator % fails with unicode Initial Comment: A dictionary with unicode keys raise an error when it is applied to a string throught the format operator %. Here is the ofending code: >>> "%(año)d" % { u"año":2001 } # KeyError: año This fails because u"año" and "año" cannot be compared: byte strings and Unicode strings are comparable only if the byte string is ASCII. > >>> u"%(año)4d" % { u"año":2001 } # KeyError: año This fails because the key is converted to UTF-8 before lookup. Must be add the unicode case into the format operator % ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438164&group_id=5470 From noreply@sourceforge.net Tue Jul 3 19:00:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 11:00:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-438295 ] case of __init__.py cause strange behavi Message-ID: Bugs item #438295, was opened at 2001-07-03 11:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438295&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: case of __init__.py cause strange behavi Initial Comment: I accidently created the file __INIT__.PY in my 'krw' package directory (WinNT4). Everything appeared to work as it should, except I was getting a very strange AttributeError: 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 printerTable >>> l = printerTable.buildFromServer( 'chachaptr1') >>> l = printerTable.buildFromServer( 'chachaptr1') >>> l = printerTable.buildFromServer( 'chachaptr1') Traceback (most recent call last): File "", line 1, in ? File "printerTable.py", line 57, in buildFromServer host = krw.util.Host( hostAndPort[0]) AttributeError: '?' module has no attribute 'util' At this point: dir( printerTable.krw) => [] After 2 days trying to find out what was happening in the code, I decided to check out the package. I ended up recreating the file as __init__.py and the problem went away. I can rename the file back to __INIT__.PY and it produces the behavior mentioned above. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438295&group_id=5470 From noreply@sourceforge.net Tue Jul 3 20:27:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 12:27:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-232815 ] getname() already in use by OS Message-ID: Bugs item #232815, was opened at 2001-02-17 05:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232815&group_id=5470 Category: Unicode Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Uwe Zessin (zessin_5) Assigned to: Fredrik Lundh (effbot) Summary: getname() already in use by OS Initial Comment: There is a name-clash on OpenVMS. modules/unicodedata.c defines a function named 'getname'. This collides with a function that is defined in OpenVMS's include file ''. Here is an extract from the documentation: ]getname ] ] Returns the file specification associated with a file descriptor. ] ] Format ] ] #include ] ] char getname (int file_desc , char buffer, . . . ); [...] ] Description ] ] This function places the file specification in the area ] pointed to by buffer and returns that address. The area ] pointed to by buffer should be an array large enough to ] contain a fully qualified file specification (the maximum ] length is 256 characters). Note: 'getname' is also used in include/ucnhash.h I guess that 'getname' does also exist on other operating systems, but might just be included by a different header file. Can this be changed, please? ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-03-02 00:25 Message: Logged In: YES user_id=38376 > I think the Compaq C/ DEC C compilers are quite > good - I have to blame myself :-( I did find it a bit hard to believe that the VMS versions wouldn't be as good as the true64 compilers (which are as good as they come ;-) The unsigned complaints are valid, but I'm not sure how to address them; I don't want the code to break if someone changes the Py_UCS4 declaration. I'll leave this one open for now, and ask the python-dev crowd for advice. Cheers /F ---------------------------------------------------------------------- Comment By: Uwe Zessin (zessin_5) Date: 2001-02-27 01:13 Message: Logged In: YES user_id=155755 Oops. I've raised a false alarm for UCNHASH.H + UNICODEOBJECT.C, sorry. The problem was that I patched UCNHASH.H again. I think the Compaq C/ DEC C compilers are quite good - I have to blame myself :-( However, the compiler's complains for UNICODEDATA.C and REGEXPR.C is still valid - shold we close this and open another report for them? ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-02-25 09:20 Message: Logged In: YES user_id=38376 Umm. If a global function declaration collides with a struct member, I'd say you're using a seriously broken compiler. What error message do you get? Are you sure you've switched on all ANSI compatibility you can get from your compiler? ---------------------------------------------------------------------- Comment By: Uwe Zessin (zessin_5) Date: 2001-02-25 07:36 Message: Logged In: YES user_id=155755 The fix is incomplete. For a clean compile I had to change: File UNICODEOBJECT.C 1254 if (ucnhash_CAPI->_getcode(start, s-start-1, &chr)) ****** File UNICODEOBJECT.C_OLD 1254 if (ucnhash_CAPI->getcode(start, s-start-1, &chr)) and: File UCNHASH.H 18 int (*_getname)(Py_UCS4 code, char* buffer, int buflen); ****** File UCNHASH.H_OLD 18 int (*getname)(Py_UCS4 code, char* buffer, int buflen); ************ File UCNHASH.H 22 int (*_getcode)(const char* name, int namelen, Py_UCS4* code); ****** File UCNHASH.H_OLD 22 int (*getcode)(const char* name, int namelen, Py_UCS4* code); I have run the code through a newer version of the compiler and receive the following messages: UNICODEDATA: if (code < 0 || code >= 65536) ........^ %CC-I-QUESTCOMPARE, In this statement, the unsigned expression "code" is being compared with a relational operator to a constant whose value is not greater than zero. This might not be what you intended. at line number 285 in file UNICODEDATA.C I guess Frederick is handling this anyway, so excuse me if I just save a little work on opening another bug report for this one: REGEXPR if (ch <= 0 || ch >= RE_NREGS) ............................^ %CC-I-QUESTCOMPARE, In this statement, the unsigned expression "ch" is being compared with a relational operator to a constant whose value is not greater than zero. This might not be what you intended. at line number 1386 in file REGEXPR.C ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232815&group_id=5470 From noreply@sourceforge.net Tue Jul 3 20:50:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 12:50:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-233790 ] [Irix] re package does not work. Message-ID: Bugs item #233790, was opened at 2001-02-23 10:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=233790&group_id=5470 >Category: Regular Expressions Group: Platform-specific >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fredrik Lundh (effbot) Summary: [Irix] re package does not work. Initial Comment: The re package does not seem to work at all under Irix 6.5 + gcc 2.8.1 (either before or after the sre Misc Patch is applied) Python 2.0 (#1, Feb 23 2001, 01:24:07) [GCC 2.8.1] on irix6 Type "copyright", "credits" or "license" for more information. >>> import re >>> m = re.compile("^ab$").match("ab") >>> print m None >>> import pre >>> m = pre.compile("^ab$").match("ab") >>> print m pre serves as a reasonable substitute, but since earlier versions of Python don't have it, one can't distribute a portable package easily. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2001-07-03 12:50 Message: Logged In: YES user_id=38376 Assuming raj's right, there's not much I can (or should) do about this. Case closed, for now. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-04-27 00:16 Message: Logged In: NO This is a guess - but it is most likely related to the fact that gcc 2.8.x sets sys.maxint to -1 under IRIX 6.x. This bug has manifest itself in several places before on this particular compiler and platform combination. The solution is to use a newer version of gcc. raj ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-04-26 14:55 Message: Logged In: YES user_id=38376 time to stop accepting platform-specific bugs without a known sender? unless someone buys me an Irix box, I cannot really do anything about this... ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-03-02 02:42 Message: Logged In: YES user_id=38376 ouch. what does the test suite say? (lib/tests/test_sre) have you tried compiling _sre.c with less/no optimization? do you get any warnings from the compiler when compiling the _sre module? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=233790&group_id=5470 From noreply@sourceforge.net Tue Jul 3 20:56:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 12:56:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-405676 ] Quasi hang in RE code Message-ID: Bugs item #405676, was opened at 2001-03-03 09:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405676&group_id=5470 Category: Regular Expressions Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fredrik Lundh (effbot) Summary: Quasi hang in RE code Initial Comment: When running the attached .py file with the attached input file, python will "hang" (after 10 seconds, it finally does return on my PII-400, but something is obviously broken) when returning from chop_chunks. GDB revealed this stack trace, pointing to re code. The input (gdb) bt #0 0x8074b7f in sre_match (state=0xbfffebc8, pattern=0x8252538, level=3) at Modules/_sre.c:671 #1 0x807523f in sre_match (state=0xbfffebc8, pattern=0x8252536, level=2) at Modules/_sre.c:1043 #2 0x8075074 in sre_match (state=0xbfffebc8, pattern=0x825251a, level=1) at Modules/_sre.c:947 #3 0x80754de in sre_search (state=0xbfffebc8, pattern=0x8252510) at Modules/_sre.c:1200 #4 0x8076bb2 in pattern_search (self=0x82524f0, args=0x822874c, kw=0x0) at ./Modules/_sre.c:1616 #5 0x8058a54 in call_cfunction (func=0x823a690, arg=0x822874c, kw=0x0) at Python/ceval.c:2731 #6 0x805898c in call_object (func=0x823a690, arg=0x822874c, kw=0x0) at Python/ceval.c:2703 #7 0x8059100 in do_call (func=0x823a690, pp_stack=0xbffff04c, na=1, nk=0) at Python/ceval.c:3014 This is with Python 2.1b1 (#1, Mar 3 2001, 12:47:09) [GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2 Type "copyright", "credits" or "license" for more information. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2001-07-03 12:56 Message: Logged In: YES user_id=38376 Under 2.1 final, this runs in ~0.3 seconds on my old P2. Using pre instead of sre cuts this to ~0.2 seconds. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-03 10:04 Message: Logged In: YES user_id=31435 Assigned to effbot. Anonymous submitter, you should be aware that the usual outcome for one of these is that the regexp turns out to have been written in a way that *requires* exponential time in some cases. See Friedl's "Master Regular Expressions" (O'Reilly) for details. Given that that is the usual case, people will be more motivated to look at this if you could whittle it down to a minimal example (one regexp, one string). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405676&group_id=5470 From noreply@sourceforge.net Tue Jul 3 22:01:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 14:01:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-438347 ] minidom getElementsByTagNameNS() Message-ID: Bugs item #438347, was opened at 2001-07-03 14:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438347&group_id=5470 Category: XML Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: minidom getElementsByTagNameNS() Initial Comment: from xml.dom.minidom.py the method getElementsByTagNameNS for the Document class fails to work for two reasons 1. getElementsByTagNameNS does not call _getElementsByTagNameNSHelper() properly, it should be def getElementsByTagNameNS(self, namespaceURI, localName): return _getElementsByTagNameNSHelper(self, namespaceURI, localName, []) for the Element class and def getElementsByTagNameNS(self, namespaceURI, localName): rc = [] _getElementsByTagNameNSHelper(self, namespaceURI, localName, rc) return rc for the Document class 2. The helper method incorrectly searches on node.tagName which will contain the xmlns prefix ('ns:node') to correc this it should compare on node.localName thus the helper function becomes def _getElementsByTagNameNSHelper(parent, nsURI, localName, rc): for node in parent.childNodes: if node.nodeType == Node.ELEMENT_NODE: if ((localName == "*" or node.localName == localName) and (nsURI == "*" or node.namespaceURI == nsURI)): rc.append(node) _getElementsByTagNameNSHelper(node, name, rc) note the change is on the following line, it contains the change from above. if ((localName == "*" or node.localName == localName) and enjoy, tim... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438347&group_id=5470 From noreply@sourceforge.net Wed Jul 4 06:57:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 22:57:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-436621 ] sgmllib tag/attrib regexpr too strict? Message-ID: Bugs item #436621, was opened at 2001-06-26 23:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436621&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dustin Boswell (boswell) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: sgmllib tag/attrib regexpr too strict? Initial Comment: 1) I've seen tags like blah which the SGMLParser will not find correctly. I'm guessing it has to do with the reg-expr for tagfind: tagfind = re.compile('[a-zA-Z][-.a-zA-Z0-9]*') Does the spec allow for _ ? Even if it doesn't, maybe tagfind should be changed... tagfind ?= re.compile('[a-zA-Z][-.a-zA-Z0-9_]*') 2) I've seen attributes with backquotes ` in them. where key has the value val```junk`` Currently, attrfind (the regular expression for such things) is attrfind = re.compile( ... r'\s*([a-zA-Z_][-.a-zA-Z_0-9]*) ... (\s*=\s*'r'(\'[^\']*\'|"[^"]*"| ... [-a-zA-Z0-9./:;+*%?!&$\(\)_#=~]*))?') Would it hurt to add ` to long list of characters that are already there? Netscape seems to allow them. Thoughts? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436621&group_id=5470 From noreply@sourceforge.net Wed Jul 4 06:59:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 22:59:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-425868 ] mimify.mime_encode_header problem Message-ID: Bugs item #425868, was opened at 2001-05-21 03:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425868&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Barry Warsaw (bwarsaw) Summary: mimify.mime_encode_header problem Initial Comment: Within the standard-module mimify.py, the function mime_encode_header does not work RFC2047-compliant (in fact, it does not work for me at all). Please take a look at the following interactive session: -------- Python 2.1 (#8, May 4 2001, 12:40:12) [GCC 2.95.2 19991024 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import mimify >>> print mimify.mime_encode_header("Subject: äöüß äöüß Test äöüß\n") Subject: =?ISO-8859-1?Q?=E4=F6=FC=DF?= äöüß Test =? ISO-8859-1?Q?=E4=F6=FC=DF?= -------- As you can see, the second word with 8-bit characters has not been encoded at all. Only because there are two spaces behind "Test" the last word has been encoded. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425868&group_id=5470 From noreply@sourceforge.net Wed Jul 4 07:01:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 23:01:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-432621 ] httplib: multiple Set-Cookie headers Message-ID: Bugs item #432621, was opened at 2001-06-12 19:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432621&group_id=5470 Category: Python Library >Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: httplib: multiple Set-Cookie headers Initial Comment: httplib does not support multiple headers of the same name, because the headers are stored in a dictionary. This causes a problem because an HTTP response can contain multiple "Set-Cookie". It is stated in RFC2109 - HTTP State Management Mechanism that "An origin server may include multiple Set-Cookie headers in a response. " With the current python implementation, only the last "Set-Cookie" header is included in the headers dictionary, effectively meaning that the other cookies were lost. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 23:01 Message: Logged In: YES user_id=3066 Categorized as a feature request. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432621&group_id=5470 From noreply@sourceforge.net Wed Jul 4 07:01:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 23:01:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-436732 ] install.py does not record path file Message-ID: Bugs item #436732, was opened at 2001-06-27 07:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436732&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jon Nelson (jnelson) >Assigned to: Greg Ward (gward) Summary: install.py does not record path file Initial Comment: install.py does not record in INSTALLED_FILES when it creates the .pth file which is created when extra_path is used. Included is a patch: --- install.py.orig Wed Jun 27 08:55:39 2001 +++ install.py Wed Jun 27 08:56:30 2001 @@ -489,6 +489,9 @@ # write list of installed files, if requested. if self.record: outputs = self.get_outputs() + if self.path_file and self.install_path_file: + outputs.append(os.path.join(self.install_libbase, + self.path_file + ".pth")) if self.root: # strip any package prefix root_len = len(self.root) for counter in xrange(len(outputs)): ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436732&group_id=5470 From noreply@sourceforge.net Wed Jul 4 07:06:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 23:06:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-428972 ] any plan for ConfigParser supports XML? Message-ID: Bugs item #428972, was opened at 2001-05-31 05:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428972&group_id=5470 Category: Extension Modules Group: Feature Request >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: eXom (jkuan) Assigned to: Nobody/Anonymous (nobody) Summary: any plan for ConfigParser supports XML? Initial Comment: There are more applications using XML for configuration file. Is there any plan to support this feature in ConfigParser? Thanks Joe ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 23:06 Message: Logged In: YES user_id=3066 Closed this as a rejected Feature Request. (ConfigParser's history isn't nearly as neat as Martin presents it, but we can pretend that's the whole story. It was never intended to support arbitrary file formats.) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-04 23:05 Message: Logged In: YES user_id=21627 ConfigParser is specifically designed to read .INI files, so I doubt that it will be extended to XML. If you need to read an XML configuration file, you best use xml.dom.minidom. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428972&group_id=5470 From noreply@sourceforge.net Wed Jul 4 07:08:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 23:08:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-437475 ] MacPy21: sre "recursion limit" bug Message-ID: Bugs item #437475, was opened at 2001-06-29 14:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437475&group_id=5470 Category: Regular Expressions Group: Platform-specific >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) >Summary: MacPy21: sre "recursion limit" bug Initial Comment: As of Python 2.0, the sre module had bug wherein a "RuntimeError: maximum recursion limit exceeded" would be raised whenever an expression matched something on the order of 16,000+ characters. The bug, nominally fixed in time for Python 2.1, is still present in MacPython 2.1, as evidenced by the following transcript copied from an interactive session with the interpreter. Note success with pre module, however. It makes me curious, since the bug appears to be fixed in WinPython 2.1, whether the correct source was used when compiling MacPython 2.1.... ========== Python 2.1 (#92, Apr 24 2001, 23:59:23) [CW PPC GUSI2 THREADS] on mac >>> import sre, pre, string >>> l = ["XXX", "%"*20000, "XXX"] >>> sre_regex = sre.compile(r"XXX.*?XXX") >>> match_object = sre_regex.search(string.join(l)) Traceback (most recent call last): File "", line 1, in ? RuntimeError: maximum recursion limit exceeded >>> ### Above error first reported upon release of sre with Python 2.0 ### >>> ### Bug supposedly fixed in Python 2.0.1 release (no Mac version, I know) ### >>> pre_regex = pre.compile(r"XXX.*XXX") >>> match_object = pre_regex.search(string.join(l)) >>> match_object >>> ### Note above success with pre module instead of sre ### >>> ### Wrong sre module source used when compiling MacPython 2.1? ### ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 23:08 Message: Logged In: YES user_id=3066 This is a duplicate of bug #437472. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437475&group_id=5470 From noreply@sourceforge.net Wed Jul 4 07:10:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 23:10:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-431060 ] print 'foo',;readline() softspace error Message-ID: Bugs item #431060, was opened at 2001-06-07 07:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=431060&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: print 'foo',;readline() softspace error Initial Comment: python 2.1 (and 1.5), intel linux and sparc solaris. def f(): print 'foo: ', sys.stdin.readline() print 'bar: ' f() foo: george bar: A print with trailing comma, followed by a readline and another print, puts an extra space at the beginning of the second printed line. An explicit setting of sys.stdout.softspace=0 after the first print averts this error. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=431060&group_id=5470 From noreply@sourceforge.net Wed Jul 4 07:11:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 23:11:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-432497 ] curses module doesn't build on HP-UX Message-ID: Bugs item #432497, was opened at 2001-06-12 11:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432497&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) >Assigned to: A.M. Kuchling (akuchling) Summary: curses module doesn't build on HP-UX Initial Comment: The curses module does not build on HP-UX 11.00 (don't know about other versions). The reason according to Peter Stoldt (peter_stoldt@hp.com) who provided the fix below is to look for the curses header file in a different directory. Here is his fix: In py_curses.h exchange the line with #include with #include This would have to be done in a platform specific way of course. Perhaps all it takes is adding the curses_colr/ dir to the compiler call as -I option... not sure. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432497&group_id=5470 From noreply@sourceforge.net Wed Jul 4 07:17:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 23:17:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-431191 ] termios, Python 2.1 and 1.5.2, AIX, SCO Message-ID: Bugs item #431191, was opened at 2001-06-07 11:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=431191&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mike Kent (mikent) Assigned to: Nobody/Anonymous (nobody) Summary: termios, Python 2.1 and 1.5.2, AIX, SCO Initial Comment: Getting the 'termios' module to compile or work on various platforms is like trying to pass a bowling ball. We need to input no-echoing passwords, therefore the need for termios. Building Python 2.1 on aix-4.3-2.1, with termios turned on in Modules/Setup, results in undefined symbol errors for 'VDISCARD' and 'VWERASE'. Building Python 1.5.2 on the same platform, with termios turned on, works fine, and gives us non-echoing passwords via getpass. Building Python 1.5.2 on SCO Open Server 5, with termios turned on, yields echoing passwords. Hmm. Upon further investingation (browsing the getpass.py source code), we found that the configure script believes this platform to be sco_sv3, and that the necessary file Lib/plat_sco_sv3/TERMIOS.py was missing. Running the 'regen' script in that directory created TERMIOS.py, which allowed a build of python with termios turned on. However, when testing getpass, it would now generate a termios.error exception. From investigating this (debugging termios.c), we determined that a call to tcsetattr was returning an error code and setting errno to 22 (Invalid argument). We gave up at that point. Wasn't one of the selling points of Python the ability to write code that would run on multiple platforms? ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 23:17 Message: Logged In: YES user_id=3066 The problem of VDISCARD and VWERASE causing compilation problems is fixed in the CVS repository; the fix is included in the upcoming 2.1.1 bugfix release. While Python *allows* writing portable code, it does not mask most differences in the underlying systems, especially in areas (like terminal control) where the specifics vary is tedious ways. Specific suggestions would be appreciated, but we don't have access to most of the platforms Python runs on. Closing the bug report as all issues that can be handled in the currently maintained and developed versions have been dealt with. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=431191&group_id=5470 From noreply@sourceforge.net Wed Jul 4 07:18:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 23:18:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-436525 ] Wrong macro name Message-ID: Bugs item #436525, was opened at 2001-06-26 14:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436525&group_id=5470 >Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Kochanski (gpk) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Wrong macro name Initial Comment: 8.1 Thread State and the Global Interpreter Lock ( http://www.python.org/doc/current/api/threads.html ) refers to macros Py_BEGIN_BLOCK_THREADS and Py_BEGIN_UNBLOCK_THREADS . These do not exist. The correct names are Py_BLOCK_THREADS and Py_UNBLOCK_THREADS. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 23:18 Message: Logged In: YES user_id=3066 Re-categorized as a documnetation error. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436525&group_id=5470 From noreply@sourceforge.net Wed Jul 4 07:29:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 23:29:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-438347 ] minidom getElementsByTagNameNS() Message-ID: Bugs item #438347, was opened at 2001-07-03 14:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438347&group_id=5470 Category: XML Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: minidom getElementsByTagNameNS() Initial Comment: from xml.dom.minidom.py the method getElementsByTagNameNS for the Document class fails to work for two reasons 1. getElementsByTagNameNS does not call _getElementsByTagNameNSHelper() properly, it should be def getElementsByTagNameNS(self, namespaceURI, localName): return _getElementsByTagNameNSHelper(self, namespaceURI, localName, []) for the Element class and def getElementsByTagNameNS(self, namespaceURI, localName): rc = [] _getElementsByTagNameNSHelper(self, namespaceURI, localName, rc) return rc for the Document class 2. The helper method incorrectly searches on node.tagName which will contain the xmlns prefix ('ns:node') to correc this it should compare on node.localName thus the helper function becomes def _getElementsByTagNameNSHelper(parent, nsURI, localName, rc): for node in parent.childNodes: if node.nodeType == Node.ELEMENT_NODE: if ((localName == "*" or node.localName == localName) and (nsURI == "*" or node.namespaceURI == nsURI)): rc.append(node) _getElementsByTagNameNSHelper(node, name, rc) note the change is on the following line, it contains the change from above. if ((localName == "*" or node.localName == localName) and enjoy, tim... ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 23:29 Message: Logged In: YES user_id=3066 These are already correct in the CVS repository; I've added a little cosmetic consistency in Lib/xml/dom/minidom.py revision 1.34 (1.26 in the PyXML repository). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438347&group_id=5470 From noreply@sourceforge.net Wed Jul 4 07:40:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 23:40:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-433875 ] 2.1 nocaret.py: SyntaxError Message-ID: Bugs item #433875, was opened at 2001-06-17 03:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433875&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1 nocaret.py: SyntaxError Initial Comment: when running compileall on a 2.1 distribution: File "/usr/local/lib/python2.1/test/nocaret.py", line 2 [x for x in x] = x SyntaxError: can't assign to list comprehension SyntaxError: from __future__ imports must occur at the beginning of the file (test_future3.py, line 3) SyntaxError: from __future__ imports must occur at the beginning of the file (test_future4.py, line 3) SyntaxError: from __future__ imports must occur at the beginning of the file (test_future5.py, line 4) SyntaxError: from __future__ imports must occur at the beginning of the file (test_future6.py, line 3) SyntaxError: from __future__ imports must occur at the beginning of the file (test_future7.py, line 3) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 23:40 Message: Logged In: YES user_id=3066 If running this as part of the installation process, this is already fixed in the CVS version. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433875&group_id=5470 From noreply@sourceforge.net Wed Jul 4 07:53:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 23:53:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-432369 ] ConfigParser: problem w/ mixed-case opts Message-ID: Bugs item #432369, was opened at 2001-06-12 03:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432369&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ConfigParser: problem w/ mixed-case opts Initial Comment: When using mixed-case option-names, ConfigParser raises a KeyError on multi-line options like this one: """ Symptoms: bla blubber; some symptom; some other symptom; yet another symptom """ Reason: 'optname' is not converted permanently but only when storing the first value part. The following patch solves the problem. Regards +++hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432369&group_id=5470 From noreply@sourceforge.net Wed Jul 4 07:54:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Jul 2001 23:54:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-434479 ] os.listdir loses on linux w/NTFS vols Message-ID: Bugs item #434479, was opened at 2001-06-19 07:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434479&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: jeremy bornstein (ukekuma) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: os.listdir loses on linux w/NTFS vols Initial Comment: os.listdir() on a directory which is on an NTFS volume omits one entry from the directory listing. Example: planet {188}: grep ntfs /etc/fstab /dev/hda1 /lose ntfs uid=500,gid=500,umask=555 1 2 planet {189}: ls /lose Documents and Settings/ My Music/ Program Files/ PUTTY.RND $Secure unzipped/ WINNT/ planet {190}: python2.1 Python 2.1 (#1, Jun 19 2001, 00:32:28) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import os >>> os.listdir('/lose') ['$Secure', 'Documents and Settings', 'My Music', 'Program Files', 'PUTTY.RND', 'unzipped'] >>> planet {191}: (In the example, note that the directory 'WINNT' is not returned by os.listdir.) I have verified this bug with/1.5.2, 1.6.1, and 2.1 on Linux (RH7.1) only. I have only tested it on this one NTFS volume and this one computer. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 23:54 Message: Logged In: YES user_id=3066 Assigning this to me since I have a similar setup. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-23 12:45 Message: Logged In: YES user_id=21627 This is likely a bug in the NTFS driver, not in Python. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434479&group_id=5470 From noreply@sourceforge.net Wed Jul 4 08:11:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Jul 2001 00:11:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-411881 ] Use of "except:" in modules Message-ID: Bugs item #411881, was opened at 2001-03-28 04:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 3 Submitted By: Itamar Shtull-Trauring (itamar) Assigned to: Nobody/Anonymous (nobody) >Summary: Use of "except:" in modules Initial Comment: A large amount of modules in the standard library use "except:" instead of specifying the exceptions to be caught. In some cases this may be correct, but I think in most cases this not true and this may cause problems. Here's the list of modules, which I got by doing: grep "except:" *.py | cut -f 1 -d " " | sort | uniq Bastion.py CGIHTTPServer.py Cookie.py SocketServer.py anydbm.py asyncore.py bdb.py cgi.py chunk.py cmd.py code.py compileall.py doctest.py fileinput.py formatter.py getpass.py htmllib.py imaplib.py inspect.py locale.py locale.py mailcap.py mhlib.py mimetools.py mimify.py os.py pdb.py popen2.py posixfile.py pre.py pstats.py pty.py pyclbr.py pydoc.py repr.py rexec.py rfc822.py shelve.py shutil.py tempfile.py threading.py traceback.py types.py unittest.py urllib.py zipfile.py ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-04 00:11 Message: Logged In: YES user_id=3066 Fixed modules mhlib and rfc822 (SF is having a problem generating the checkin emails, though). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-05-11 12:40 Message: Logged In: YES user_id=3066 OK, I've fixed up a few more modules: anydbm chunk formatter htmllib mailcap pre pty I made one change to asyncore as well, but other bare except clauses remain there; I'm not sufficiently familiar with that code to just go digging into those. I also fixed an infraction in pstats, but left others for now. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-04-23 01:14 Message: Logged In: YES user_id=31435 Ping's intent is that pydoc work under versions of Python as early as 1.5.2, so that sys._getframe is off-limits in pydoc and its supporting code (like inspect.py). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-23 00:32 Message: Logged In: YES user_id=21627 For inspect.py, why is it necessary to keep the old code at all? My proposal: remove currentframe altogether, and do currentframe = sys._getframe unconditionally. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-04-22 07:52 Message: Logged In: YES user_id=32065 I submitted a 4th patch. I'm starting to run out of easy cases... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-04-19 02:15 Message: Logged In: YES user_id=44345 I believe the following patch is correct for the try/except in inspect.currentframe. Note that it fixes two problems. One, it avoids a bare except. Two, it gets rid of a string argument to the raise statement (string exceptions are now deprecated, right?). *** /tmp/skip/inspect.py Thu Apr 19 04:13:36 2001 --- /tmp/skip/inspect.py.~1.16~ Thu Apr 19 04:13:36 2001 *************** *** 643,650 **** def currentframe(): """Return the frame object for the caller's stack frame.""" try: ! 1/0 ! except ZeroDivisionError: return sys.exc_traceback.tb_frame.f_back if hasattr(sys, '_getframe'): currentframe = sys._getframe --- 643,650 ---- def currentframe(): """Return the frame object for the caller's stack frame.""" try: ! raise 'catch me' ! except: return sys.exc_traceback.tb_frame.f_back if hasattr(sys, '_getframe'): currentframe = sys._getframe ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-04-17 08:27 Message: Logged In: YES user_id=32065 inspect.py uses sys_getframe if it's there, the other code is for backwards compatibility. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-11 10:24 Message: Logged In: YES user_id=6380 Actually, inspect.py should use sys._getframe()! And yes, KeyboardError is definitely one of the reasons why this is such a bad idiom... ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-04-11 10:15 Message: Logged In: YES user_id=89016 > Can you identify modules where catching everything > is incorrect If "everything" includes KeyboardInterrupt, it's definitely incorrect, even in inspect.py's simple try: raise 'catch me' except: return sys.exc_traceback.tb_frame.f_back which should probably be: try: raise 'catch me' except KeyboardInterrupt: raise except: return sys.exc_traceback.tb_frame.f_back ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-04-11 10:13 Message: Logged In: YES user_id=89016 > Can you identify modules where catching everything > is incorrect If "everything" includes KeyboardInterrupt, it's definitely incorrect, even in inspect.py's simple try: raise 'catch me' except: return sys.exc_traceback.tb_frame.f_back which should probably be: try: raise 'catch me' except KeyboardInterrupt: raise except: return sys.exc_traceback.tb_frame.f_back ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 08:45 Message: Logged In: YES user_id=6380 I've applied the three patches you supplied. I agree with Martin that to do this right we'll have to tread carefully. But please go on! (No way more of this will find its way into 2.1 though.) ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2001-03-30 02:54 Message: Logged In: YES user_id=32065 inspect.py should be removed from this list, the use is correct. In general, I just submitted this bug so that when people are editing a module they'll notice these things, since in some cases only someone who knows the code very well can know if the "expect:" is needed or not. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-29 22:59 Message: Logged In: YES user_id=21627 Can you identify modules where catching everything is incorrect, and propose changes to correct them. This should be done one-by-one, with careful analysis in each case, and may take well months or years to complete. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470 From noreply@sourceforge.net Wed Jul 4 08:11:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Jul 2001 00:11:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-438083 ] uu module allows hostile paths Message-ID: Bugs item #438083, was opened at 2001-07-02 17:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438083&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Barry Warsaw (bwarsaw) Summary: uu module allows hostile paths Initial Comment: hello, the uu module does not appear to do any checking on the file name included in the uuencoded data. as far as i can see, it allows absolute paths and will happily overwrite anything. you can pass file objects to it, but then the information about the file name is lost. i've attached a sketchy patch. -- erno@iki.fi ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438083&group_id=5470 From noreply@sourceforge.net Wed Jul 4 11:18:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Jul 2001 03:18:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-425868 ] mimify.mime_encode_header problem Message-ID: Bugs item #425868, was opened at 2001-05-21 03:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425868&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Barry Warsaw (bwarsaw) Summary: mimify.mime_encode_header problem Initial Comment: Within the standard-module mimify.py, the function mime_encode_header does not work RFC2047-compliant (in fact, it does not work for me at all). Please take a look at the following interactive session: -------- Python 2.1 (#8, May 4 2001, 12:40:12) [GCC 2.95.2 19991024 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import mimify >>> print mimify.mime_encode_header("Subject: äöüß äöüß Test äöüß\n") Subject: =?ISO-8859-1?Q?=E4=F6=FC=DF?= äöüß Test =? ISO-8859-1?Q?=E4=F6=FC=DF?= -------- As you can see, the second word with 8-bit characters has not been encoded at all. Only because there are two spaces behind "Test" the last word has been encoded. ---------------------------------------------------------------------- >Comment By: Sjoerd Mullender (sjoerd) Date: 2001-07-04 03:18 Message: Logged In: YES user_id=43607 This was indeed a bug which I fixed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425868&group_id=5470 From noreply@sourceforge.net Wed Jul 4 13:32:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Jul 2001 05:32:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-438517 ] tkSimpleDialog.askString option Message-ID: Bugs item #438517, was opened at 2001-07-04 05:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438517&group_id=5470 Category: Tkinter Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: tkSimpleDialog.askString option Initial Comment: I read the documentation of tkSimpleDialog.askString and found that there are only two options: initialvalue and parent. However, it doesn't support the option, show, from the Entry widget option that avoids echoing the string I input. I found the tkSimpleDialog.askString is a perfect fit for dialogs asking for encryption key or password. Although it is easy to write my own, I don't see the need because of an option. Many thanks Joe ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438517&group_id=5470 From noreply@sourceforge.net Thu Jul 5 03:29:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Jul 2001 19:29:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-438295 ] [Windows] __init__.py cause strange behavior Message-ID: Bugs item #438295, was opened at 2001-07-03 11:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438295&group_id=5470 Category: Python Interpreter Core >Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Tim Peters (tim_one) >Summary: [Windows] __init__.py cause strange behavior Initial Comment: I accidently created the file __INIT__.PY in my 'krw' package directory (WinNT4). Everything appeared to work as it should, except I was getting a very strange AttributeError: 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 printerTable >>> l = printerTable.buildFromServer( 'chachaptr1') >>> l = printerTable.buildFromServer( 'chachaptr1') >>> l = printerTable.buildFromServer( 'chachaptr1') Traceback (most recent call last): File "", line 1, in ? File "printerTable.py", line 57, in buildFromServer host = krw.util.Host( hostAndPort[0]) AttributeError: '?' module has no attribute 'util' At this point: dir( printerTable.krw) => [] After 2 days trying to find out what was happening in the code, I decided to check out the package. I ended up recreating the file as __init__.py and the problem went away. I can rename the file back to __INIT__.PY and it produces the behavior mentioned above. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-04 19:29 Message: Logged In: YES user_id=31435 Assigned to me, added "[Windows]" to summary, changed group to Platform-specific. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438295&group_id=5470 From noreply@sourceforge.net Thu Jul 5 04:49:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Jul 2001 20:49:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-438295 ] [Windows] __init__.py cause strange behavior Message-ID: Bugs item #438295, was opened at 2001-07-03 11:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438295&group_id=5470 Category: Python Interpreter Core Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: [Windows] __init__.py cause strange behavior Initial Comment: I accidently created the file __INIT__.PY in my 'krw' package directory (WinNT4). Everything appeared to work as it should, except I was getting a very strange AttributeError: 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 printerTable >>> l = printerTable.buildFromServer( 'chachaptr1') >>> l = printerTable.buildFromServer( 'chachaptr1') >>> l = printerTable.buildFromServer( 'chachaptr1') Traceback (most recent call last): File "", line 1, in ? File "printerTable.py", line 57, in buildFromServer host = krw.util.Host( hostAndPort[0]) AttributeError: '?' module has no attribute 'util' At this point: dir( printerTable.krw) => [] After 2 days trying to find out what was happening in the code, I decided to check out the package. I ended up recreating the file as __init__.py and the problem went away. I can rename the file back to __INIT__.PY and it produces the behavior mentioned above. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-04 20:49 Message: Logged In: YES user_id=31435 There's really not enough info here to be sure I know what your problem is; for example, it's not clear what the intended relationship is between printerTable and krw. I did fix *a* bug anyway, though: Windows wasn't checking correctly for case-sensitivity on __init__ files specifically, causing half of the package import machinery to think __INIT__ was OK, but the other half not to (and then silently suppressing the error). In the future, case-mismatching __init__ will act as if the file weren't there at all, probably leading to an ImportError. Note that Python will tell you which files it's looking at when *trying* to do an import if you run python with the -v switch (or -vv for even more detailed info). Python/import.c; new revision: 2.178 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-04 19:29 Message: Logged In: YES user_id=31435 Assigned to me, added "[Windows]" to summary, changed group to Platform-specific. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438295&group_id=5470 From noreply@sourceforge.net Thu Jul 5 12:08:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Jul 2001 04:08:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-438735 ] #ifndef WITHOUT_COMPLEX in config.c Message-ID: Bugs item #438735, was opened at 2001-07-05 04:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438735&group_id=5470 Category: Build Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: #ifndef WITHOUT_COMPLEX in config.c Initial Comment: Not really a bug. There's two #ifndef WITHOUT_COMPLEX missing in config.c : around the definition : extern void initcmath(void); (line 13 ) and around the utilisation : {"cmath", initcmath}, line 64 in order to compile without complex. To compile with the PC_build workspace, I also add a #ifndef WITHOUT_COMPLEX around the cmathmodule.c file. Version Python2.1 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438735&group_id=5470 From noreply@sourceforge.net Thu Jul 5 13:22:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Jul 2001 05:22:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-432786 ] Python 2.1 test_locale fails Message-ID: Bugs item #432786, was opened at 2001-06-13 07:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432786&group_id=5470 Category: Extension Modules Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Paul M. Dubuc (dubuc) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.1 test_locale fails Initial Comment: I'm building Python 2.1 on Solaris 2.6. When I 'make test', the test_locale module is the only one that fails: test test_locale failed -- Writing: "'%f' % 1024 == '1024.000000' != '1,024.000000'", expected: '' ... The actual stdout doesn't match the expected stdout. This much did match (between asterisk lines): ********************************************************************** test_locale ********************************************************************** Then ... We expected (repr): '' But instead we got: "'%f' % 1024 == '1024.000000' != '1,024.000000'" ---------------------------------------------------------------------- >Comment By: Paul M. Dubuc (dubuc) Date: 2001-07-05 05:22 Message: Logged In: YES user_id=242488 I have tried the build with Solaris 8 (SPARC) also with the same result. So the problem hasn't been fixed there either. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-01 09:18 Message: Logged In: YES user_id=21627 The official ISO POSIX locale definition for en_US is at ftp://std.dkuug.dk/i18n/WG15-collection/locales/en_US In this file, you can see thousands_sep "<,>" grouping 3;3 So clearly, Solaris and Irix don't comply with this definition. Unless the vendors have some good story for that deviation, I'd say it is a bug in these systems. It is not surprising they show the same bug, though - they probably use the same sources. ---------------------------------------------------------------------- Comment By: Robert Minsk (rminsk) Date: 2001-06-25 14:10 Message: Logged In: YES user_id=132786 The SGI has the same locale problem as Solaris. Is this a bug with the locale defination on linux? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-16 00:53 Message: Logged In: YES user_id=21627 That appears to be a bug in Solaris 2.6. To see the problem, please try the following program import locale locale.setlocale(locale.LC_ALL,"en_US") c=locale.localeconv() print c['grouping'],repr(c['thousands_sep']) In the en_US locale, the thousands separator *should* be a comma, but Solaris 2.6 reports that this locale has no thousands separator. For locale information, Python relies on what the operating system reports. As it is an OS bug, I'm closing the report as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432786&group_id=5470 From noreply@sourceforge.net Thu Jul 5 14:34:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Jul 2001 06:34:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-436130 ] solaris2.6 problems with readline Message-ID: Bugs item #436130, was opened at 2001-06-25 10:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436130&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Stenberg (fredriks) Assigned to: Nobody/Anonymous (nobody) Summary: solaris2.6 problems with readline Initial Comment: having problem with compiling python2.0.1 2.0 (i think i always had this problem after 1.5.2) on solaris 2.6 gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -I./../Include -I.. -DHAVE_CONFIG_H -c ./readline.c ./readline.c: In function `setup_readline': ./readline.c:414: `CPPFunction' undeclared (first use in this function) ./readline.c:414: (Each undeclared identifier is reported only once ./readline.c:414: for each function it appears in.) ./readline.c:414: parse error before `)' *** Error code 1 I have always used to exchange Modules/readline.c with the old file from the 1.5.2 release. I finally got around to checking whats wrong, (or atleast browse around the code). readline.c Line 414 in void setup_readline states, rl_attempted_completion_function = (CPPFunction *)flex_complete; should this not be; rl_attempted_completion_function = (Function *)flex_complete; I have no problems if i change CPPfunction into Function, i'm no readline expert but i think this is the problem. *sysinfo* gcc 2.95.2 solaris 2.6 readline4.1 ---------------------------------------------------------------------- >Comment By: Fredrik Stenberg (fredriks) Date: 2001-07-05 06:34 Message: Logged In: YES user_id=5299 Had no problems after using the latest version of readline.c from the CVS... So the problem is fixed (in the future)....(not in the current dist) /fredriks ---------------------------------------------------------------------- Comment By: Fredrik Stenberg (fredriks) Date: 2001-06-27 04:10 Message: Logged In: YES user_id=5299 I tried it on solaris2.8 later that night, I installed readline 4.2 also (no problems with the installetion, all testprograms worked fine) But python Module/readline.c refused to compile once again. I could (as I always have) copy the old readline.c from 1.5.2 and get it to work..... Is it only me? /fredriks gcc -I/tmp/su96-fst/include -g -O2 -Wall -Wstrict-prototypes -fPIC -I./../Include -I.. -DHAVE_CONFIG_H -c ./readline.c In file included from /tmp/su96-fst/include/readline/keymaps.h:37, from /tmp/su96-fst/include/readline/readline.h:36, from ./readline.c:28: /tmp/su96-fst/include/readline/rltypedefs.h:35: warning: function declaration isn't a prototype /tmp/su96-fst/include/readline/rltypedefs.h:36: warning: function declaration isn't a prototype /tmp/su96-fst/include/readline/rltypedefs.h:37: warning: function declaration isn't a prototype /tmp/su96-fst/include/readline/rltypedefs.h:38: warning: function declaration isn't a prototype In file included from ./readline.c:28: /tmp/su96-fst/include/readline/readline.h:350: warning: function declaration isn't a prototype ./readline.c:31: conflicting types for `rl_read_init_file' /tmp/su96-fst/include/readline/readline.h:303: previous declaration of `rl_read_init_file' ./readline.c:32: conflicting types for `rl_insert_text' /tmp/su96-fst/include/readline/readline.h:363: previous declaration of `rl_insert_text' ./readline.c: In function `set_completer_delims': ./readline.c:227: warning: passing arg 1 of `free' discards qualifiers from pointer target type ./readline.c: In function `flex_complete': ./readline.c:399: warning: implicit declaration of function `completion_matches' ./readline.c:399: warning: return makes pointer from integer without a cast *** Error code 1 make: Fatal error: Command failed for target `readline.o' Current working directory /tmp/su96-fst/Python-2.0.1/Modules *** Error code 1 make: Fatal error: Command failed for target `Modules' ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-26 15:07 Message: Logged In: YES user_id=21627 CPPFunction is defined in readline 4.2, so one solution would be to update to 4.2. The real type of this variable is rl_completion_func_t. So if this typedef is already available in 4.1, we should probably change the cast to rl_completion_func_t. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436130&group_id=5470 From noreply@sourceforge.net Thu Jul 5 14:35:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Jul 2001 06:35:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-438773 ] fpectl is not initiliazed on Windows Message-ID: Bugs item #438773, was opened at 2001-07-05 06:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438773&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Prescod (prescod) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: fpectl is not initiliazed on Windows Initial Comment: config.c initializes all of the modules that are compiled into the python22.dll, but not fpectl. So we're carrying around the functionality and documented it as being available on Windows, but it isn't. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438773&group_id=5470 From noreply@sourceforge.net Thu Jul 5 15:54:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Jul 2001 07:54:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-438786 ] CVS 2.1.1c1 broken on osf1V4 Message-ID: Bugs item #438786, was opened at 2001-07-05 07:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Nobody/Anonymous (nobody) Summary: CVS 2.1.1c1 broken on osf1V4 Initial Comment: As of right now, the CVS branch for the 2.1 bugfix release cannot import the math module on my Digital Unix platform. ImportError: Unresolved symbol in /tmp_mnt/home/gball/usr/src/python/dist/src/build/lib.osf1-V4.0-alpha-2.1/math.so: __eprintf uname is OSF1 surya V4.0 878 alpha ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 From noreply@sourceforge.net Thu Jul 5 18:46:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Jul 2001 10:46:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-438823 ] Solaris Shared library build is broken Message-ID: Bugs item #438823, was opened at 2001-07-05 10:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438823&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris Shared library build is broken Initial Comment: Current CVS as of now, both main branch and 2.1 maintenance branch. The $(OPT) and $(CCSHARED) variables from the top level Makefile are not making it to the command line for the compilation of the shared module source. This is obviously not good. On gcc at least, it means the necessary -fPIC option is not given and the object files will not link to make shared libraries. I guess this is a problem with distutils, why it would be platform specific I don't know, but there is no such problem on Linux (-fPIC and other flags show up fine.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438823&group_id=5470 From noreply@sourceforge.net Thu Jul 5 19:04:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Jul 2001 11:04:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-438823 ] Solaris Shared library build is broken Message-ID: Bugs item #438823, was opened at 2001-07-05 10:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438823&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris Shared library build is broken Initial Comment: Current CVS as of now, both main branch and 2.1 maintenance branch. The $(OPT) and $(CCSHARED) variables from the top level Makefile are not making it to the command line for the compilation of the shared module source. This is obviously not good. On gcc at least, it means the necessary -fPIC option is not given and the object files will not link to make shared libraries. I guess this is a problem with distutils, why it would be platform specific I don't know, but there is no such problem on Linux (-fPIC and other flags show up fine.) ---------------------------------------------------------------------- >Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-05 11:04 Message: Logged In: YES user_id=11365 Ack, sorry. This is bug 437487, and the analysis there is correct. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438823&group_id=5470 From noreply@sourceforge.net Thu Jul 5 19:06:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Jul 2001 11:06:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-438823 ] Solaris Shared library build is broken Message-ID: Bugs item #438823, was opened at 2001-07-05 10:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438823&group_id=5470 Category: Build Group: Platform-specific >Status: Deleted Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris Shared library build is broken Initial Comment: Current CVS as of now, both main branch and 2.1 maintenance branch. The $(OPT) and $(CCSHARED) variables from the top level Makefile are not making it to the command line for the compilation of the shared module source. This is obviously not good. On gcc at least, it means the necessary -fPIC option is not given and the object files will not link to make shared libraries. I guess this is a problem with distutils, why it would be platform specific I don't know, but there is no such problem on Linux (-fPIC and other flags show up fine.) ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-05 11:04 Message: Logged In: YES user_id=11365 Ack, sorry. This is bug 437487, and the analysis there is correct. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438823&group_id=5470 From noreply@sourceforge.net Thu Jul 5 19:25:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Jul 2001 11:25:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-436621 ] sgmllib tag/attrib regexpr too strict? Message-ID: Bugs item #436621, was opened at 2001-06-26 23:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436621&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dustin Boswell (boswell) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: sgmllib tag/attrib regexpr too strict? Initial Comment: 1) I've seen tags like blah which the SGMLParser will not find correctly. I'm guessing it has to do with the reg-expr for tagfind: tagfind = re.compile('[a-zA-Z][-.a-zA-Z0-9]*') Does the spec allow for _ ? Even if it doesn't, maybe tagfind should be changed... tagfind ?= re.compile('[a-zA-Z][-.a-zA-Z0-9_]*') 2) I've seen attributes with backquotes ` in them. where key has the value val```junk`` Currently, attrfind (the regular expression for such things) is attrfind = re.compile( ... r'\s*([a-zA-Z_][-.a-zA-Z_0-9]*) ... (\s*=\s*'r'(\'[^\']*\'|"[^"]*"| ... [-a-zA-Z0-9./:;+*%?!&$\(\)_#=~]*))?') Would it hurt to add ` to long list of characters that are already there? Netscape seems to allow them. Thoughts? ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-05 11:25 Message: Logged In: YES user_id=3066 Fixed in Lib/sgmllib.py revisions 1.32 and 1.30.2.1. On the attribute issue: These are not legal attributes as far as SGML is concerned, but Mozilla also allows the quote characters in the value of an unquoted attribute values. sgmllib now matches that behavior. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436621&group_id=5470 From noreply@sourceforge.net Thu Jul 5 19:27:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Jul 2001 11:27:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-438773 ] fpectl is not initiliazed on Windows Message-ID: Bugs item #438773, was opened at 2001-07-05 06:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438773&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Prescod (prescod) >Assigned to: Tim Peters (tim_one) Summary: fpectl is not initiliazed on Windows Initial Comment: config.c initializes all of the modules that are compiled into the python22.dll, but not fpectl. So we're carrying around the functionality and documented it as being available on Windows, but it isn't. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-05 11:27 Message: Logged In: YES user_id=3066 Assigning to Tim since he knows what to do on Windows. I think the documentation change was based on user comments. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438773&group_id=5470 From noreply@sourceforge.net Thu Jul 5 21:50:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Jul 2001 13:50:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-438773 ] fpectl is not initiliazed on Windows Message-ID: Bugs item #438773, was opened at 2001-07-05 06:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438773&group_id=5470 >Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Prescod (prescod) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: fpectl is not initiliazed on Windows Initial Comment: config.c initializes all of the modules that are compiled into the python22.dll, but not fpectl. So we're carrying around the functionality and documented it as being available on Windows, but it isn't. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-05 13:50 Message: Logged In: YES user_id=31435 Changed to Documentation and back to Fred. fpectl has never been available on Windows, so the docs shouldn't say that it is. The raw code may actually work on Windows, but I haven't checked and have no interest in trying it: it's not enough just to compile the module, you need also to #define WANT_SIGFPE_HANDLER in PC/config.h, and then the PyFPE_START_PROTECT and PyFPE_END_PROTECT macros change from nops to expensive setjmps and external calls. I don't want to release Windows Python that way; fine by me if somebody wants to compile their own Python that way, though. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-05 11:27 Message: Logged In: YES user_id=3066 Assigning to Tim since he knows what to do on Windows. I think the documentation change was based on user comments. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438773&group_id=5470 From noreply@sourceforge.net Thu Jul 5 22:07:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Jul 2001 14:07:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-438773 ] fpectl is not initiliazed on Windows Message-ID: Bugs item #438773, was opened at 2001-07-05 06:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438773&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Prescod (prescod) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: fpectl is not initiliazed on Windows Initial Comment: config.c initializes all of the modules that are compiled into the python22.dll, but not fpectl. So we're carrying around the functionality and documented it as being available on Windows, but it isn't. ---------------------------------------------------------------------- >Comment By: Paul Prescod (prescod) Date: 2001-07-05 14:07 Message: Logged In: YES user_id=31788 Okay, but is there any reason to keep it in the project file and DLL if it is just useless code? We'll just have this conversation again when someone else notices this strange situation. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-05 13:50 Message: Logged In: YES user_id=31435 Changed to Documentation and back to Fred. fpectl has never been available on Windows, so the docs shouldn't say that it is. The raw code may actually work on Windows, but I haven't checked and have no interest in trying it: it's not enough just to compile the module, you need also to #define WANT_SIGFPE_HANDLER in PC/config.h, and then the PyFPE_START_PROTECT and PyFPE_END_PROTECT macros change from nops to expensive setjmps and external calls. I don't want to release Windows Python that way; fine by me if somebody wants to compile their own Python that way, though. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-05 11:27 Message: Logged In: YES user_id=3066 Assigning to Tim since he knows what to do on Windows. I think the documentation change was based on user comments. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438773&group_id=5470 From noreply@sourceforge.net Thu Jul 5 22:20:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Jul 2001 14:20:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-438773 ] fpectl is not initiliazed on Windows Message-ID: Bugs item #438773, was opened at 2001-07-05 06:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438773&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Prescod (prescod) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: fpectl is not initiliazed on Windows Initial Comment: config.c initializes all of the modules that are compiled into the python22.dll, but not fpectl. So we're carrying around the functionality and documented it as being available on Windows, but it isn't. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-05 14:20 Message: Logged In: YES user_id=31435 Removed fpectlmodule.c and fpetestmodule.c from the Windows build, PCbuild/pythoncore.dsp, new revision: 1.16. ---------------------------------------------------------------------- Comment By: Paul Prescod (prescod) Date: 2001-07-05 14:07 Message: Logged In: YES user_id=31788 Okay, but is there any reason to keep it in the project file and DLL if it is just useless code? We'll just have this conversation again when someone else notices this strange situation. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-05 13:50 Message: Logged In: YES user_id=31435 Changed to Documentation and back to Fred. fpectl has never been available on Windows, so the docs shouldn't say that it is. The raw code may actually work on Windows, but I haven't checked and have no interest in trying it: it's not enough just to compile the module, you need also to #define WANT_SIGFPE_HANDLER in PC/config.h, and then the PyFPE_START_PROTECT and PyFPE_END_PROTECT macros change from nops to expensive setjmps and external calls. I don't want to release Windows Python that way; fine by me if somebody wants to compile their own Python that way, though. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-05 11:27 Message: Logged In: YES user_id=3066 Assigning to Tim since he knows what to do on Windows. I think the documentation change was based on user comments. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438773&group_id=5470 From noreply@sourceforge.net Thu Jul 5 22:20:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Jul 2001 14:20:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-438773 ] fpectl is not initiliazed on Windows Message-ID: Bugs item #438773, was opened at 2001-07-05 06:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438773&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Paul Prescod (prescod) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: fpectl is not initiliazed on Windows Initial Comment: config.c initializes all of the modules that are compiled into the python22.dll, but not fpectl. So we're carrying around the functionality and documented it as being available on Windows, but it isn't. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-05 14:20 Message: Logged In: YES user_id=3066 I've marked this as "Won't Fix" since the bug as reported won't be fixed. The documentation has been updated to reflect reality (Doc/lib/libfpectl.tex revisions 1.2 and 1.1.4.1). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-05 14:20 Message: Logged In: YES user_id=31435 Removed fpectlmodule.c and fpetestmodule.c from the Windows build, PCbuild/pythoncore.dsp, new revision: 1.16. ---------------------------------------------------------------------- Comment By: Paul Prescod (prescod) Date: 2001-07-05 14:07 Message: Logged In: YES user_id=31788 Okay, but is there any reason to keep it in the project file and DLL if it is just useless code? We'll just have this conversation again when someone else notices this strange situation. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-05 13:50 Message: Logged In: YES user_id=31435 Changed to Documentation and back to Fred. fpectl has never been available on Windows, so the docs shouldn't say that it is. The raw code may actually work on Windows, but I haven't checked and have no interest in trying it: it's not enough just to compile the module, you need also to #define WANT_SIGFPE_HANDLER in PC/config.h, and then the PyFPE_START_PROTECT and PyFPE_END_PROTECT macros change from nops to expensive setjmps and external calls. I don't want to release Windows Python that way; fine by me if somebody wants to compile their own Python that way, though. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-05 11:27 Message: Logged In: YES user_id=3066 Assigning to Tim since he knows what to do on Windows. I think the documentation change was based on user comments. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438773&group_id=5470 From noreply@sourceforge.net Fri Jul 6 01:12:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Jul 2001 17:12:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-438931 ] ftplib crash Message-ID: Bugs item #438931, was opened at 2001-07-05 17:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438931&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ftplib crash Initial Comment: I've found a rather horrible problem when using ftplib. I'm running python2.1 and linux kernel 2.4.4 I haven't had a chance to check this out on any other machines, I don't want to bring down a server testing this. This code makes my system hang when I try to upload a file of 4 megs or 100 megs. It works for 22 bytes (my other test file): def copyDepot(self, depot): import ftplib, stat depot.mFullPath = "/tmp/" + depot.mFile ftp = ftplib.FTP(self.mHost) ftp.login(self.mUser,self.mPass) f = open(depot.mLocalPath, 'r+') ftp.storbinary("STOR " + depot.mFullPath, f, 8192) size = ftp.size(depot.mFullPath) lsize = os.stat(depot.mLocalPath)[stat.ST_SIZE] ftp.quit() print "Remote Size: ",size print "Local Size: ",lsize if size != os.stat(depot.mLocalPath)[stat.ST_SIZE]: raise "Size does not match!" Any ideas? Has anybody heard of something like this happening? What would you suggest I do to fix it if its not python? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438931&group_id=5470 From noreply@sourceforge.net Fri Jul 6 11:36:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 03:36:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-439012 ] Need doc: initial state of allocs Message-ID: Bugs item #439012, was opened at 2001-07-06 03:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439012&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Need doc: initial state of allocs Initial Comment: The Py_Malloc and PyObject_New/PyObject_NEW are not documented as to whether the memory they return is pre-initialized to zeros or not. In fact, PyObject_New/PyObject_NEW aren't documented anywhere for extension writers. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439012&group_id=5470 From noreply@sourceforge.net Fri Jul 6 15:16:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 07:16:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-431060 ] print 'foo',;readline() softspace error Message-ID: Bugs item #431060, was opened at 2001-06-07 07:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=431060&group_id=5470 Category: Python Library >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: print 'foo',;readline() softspace error Initial Comment: python 2.1 (and 1.5), intel linux and sparc solaris. def f(): print 'foo: ', sys.stdin.readline() print 'bar: ' f() foo: george bar: A print with trailing comma, followed by a readline and another print, puts an extra space at the beginning of the second printed line. An explicit setting of sys.stdout.softspace=0 after the first print averts this error. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-06 07:16 Message: Logged In: YES user_id=3066 While this can be annoying, it is not really a bug, and could only be "fixed" if we add support for some general concept of "tieing" an input and output stream. The problem is that the print and the readline() affect two different file objects. Unless the input stream which provides the readline() method knows about the output stream used for the print, there's no way to update the softspace attribute on the output stream. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=431060&group_id=5470 From noreply@sourceforge.net Fri Jul 6 15:25:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 07:25:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-431060 ] print 'foo',;readline() softspace error Message-ID: Bugs item #431060, was opened at 2001-06-07 07:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=431060&group_id=5470 Category: Python Library Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: print 'foo',;readline() softspace error Initial Comment: python 2.1 (and 1.5), intel linux and sparc solaris. def f(): print 'foo: ', sys.stdin.readline() print 'bar: ' f() foo: george bar: A print with trailing comma, followed by a readline and another print, puts an extra space at the beginning of the second printed line. An explicit setting of sys.stdout.softspace=0 after the first print averts this error. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-06 07:25 Message: Logged In: YES user_id=3066 I should also note that the example code can be implemented differently, using raw_input(): def f(): s = raw_input("foo: ") print "bar: " This version does not exhibit the spacing problem the original code fragment exhibits. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-06 07:16 Message: Logged In: YES user_id=3066 While this can be annoying, it is not really a bug, and could only be "fixed" if we add support for some general concept of "tieing" an input and output stream. The problem is that the print and the readline() affect two different file objects. Unless the input stream which provides the readline() method knows about the output stream used for the print, there's no way to update the softspace attribute on the output stream. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=431060&group_id=5470 From noreply@sourceforge.net Fri Jul 6 17:05:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 09:05:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-437984 ] package name truncation to 50 chars. Message-ID: Bugs item #437984, was opened at 2001-07-02 11:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437984&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: chris tignor (ctignor) Assigned to: Nobody/Anonymous (nobody) Summary: package name truncation to 50 chars. Initial Comment: Truncation of package names to 50 characters once represented as strings becomes extremely confusing for development purposes, even more so when as it exists as an undocumented event. I request full package names be represented. Thank-you. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-07-06 09:05 Message: Logged In: YES user_id=31392 Can you include a more specific description of the problem you are having? An example would go a long way. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437984&group_id=5470 From noreply@sourceforge.net Fri Jul 6 17:07:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 09:07:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-438164 ] Format operator % fails with unicode Message-ID: Bugs item #438164, was opened at 2001-07-03 00:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438164&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chema Cortés (chemacortes) >Assigned to: M.-A. Lemburg (lemburg) Summary: Format operator % fails with unicode Initial Comment: A dictionary with unicode keys raise an error when it is applied to a string throught the format operator %. Here is the ofending code: >>> "%(año)d" % { u"año":2001 } # KeyError: año This fails because u"año" and "año" cannot be compared: byte strings and Unicode strings are comparable only if the byte string is ASCII. > >>> u"%(año)4d" % { u"año":2001 } # KeyError: año This fails because the key is converted to UTF-8 before lookup. Must be add the unicode case into the format operator % ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438164&group_id=5470 From noreply@sourceforge.net Fri Jul 6 17:13:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 09:13:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-437879 ] SocketServer.py related problems Message-ID: Bugs item #437879, was opened at 2001-07-02 05:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437879&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) >Assigned to: Guido van Rossum (gvanrossum) Summary: SocketServer.py related problems Initial Comment: I tried several third-party proxy servers for Python (munchy,webdebug) go get working with Python 2.1 under Linux i386. But all fail with similar problems: Under 2.1: andreas@yetix:/home/andreas/src/munchy-0.7: python2.1 munchy.py 8006 Starting proxy on port 8006 Exception in thread Thread-1: Traceback (most recent call last): File "/opt/python-2.1/lib/python2.1/threading.py", line 378, in __bootstrap self.run() File "/opt/python-2.1/lib/python2.1/threading.py", line 366, in run apply(self.__target, self.__args, self.__kwargs) File "/opt/python-2.1/lib/python2.1/SocketServer.py", line 246, in finish_request self.RequestHandlerClass(request, client_address, self) File "/opt/python-2.1/lib/python2.1/SocketServer.py", line 494, in __init__ self.setup() File "/opt/python-2.1/lib/python2.1/SocketServer.py", line 537, in setup self.rfile = self.connection.makefile('rb', self.rbufsize) error: (9, 'Bad file descriptor') I could not track down the problem :-( Andreas ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437879&group_id=5470 From noreply@sourceforge.net Fri Jul 6 17:13:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 09:13:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-438050 ] configure doesn't look for poll.h in sys Message-ID: Bugs item #438050, was opened at 2001-07-02 15:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438050&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: David Dyck (dcd) >Assigned to: A.M. Kuchling (akuchling) Summary: configure doesn't look for poll.h in sys Initial Comment: I was surprised to see python not build out of the box on this old libc5 system. seems to be a problem with configure finding poll.h If I manually add #include to "Modules/selectmodule.c" then make continues (Another workaround is to create a dummy /usr/include/poll.h that just #include's ) dd:dcd$ uname -a Linux dd 2.4.5-ac22 #2 Fri Jun 29 14:39:29 PDT 2001 i686 /lib/libc.so.5 -> libc.so.5.4.44* make[1]: Entering directory `/hdb2/jd/usr2/dcd/ftp2/python/Python-2.0.1/Modules' gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -I./../Include -I.. -DHAVE_CONFIG_H ./selectmodule.c: In function `update_ufd_array': ./selectmodule.c:319: sizeof applied to an incomplete type ./selectmodule.c:327: arithmetic on pointer to an incomplete type ./selectmodule.c:327: dereferencing pointer to incomplete type configure:1557: checking for poll.h configure:1567: gcc -E conftest.c >/dev/null 2>conftest.out configure:1563: poll.h: No such file or directory configure: failed program was: #line 1562 "configure" #include "confdefs.h" #include ---- ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438050&group_id=5470 From noreply@sourceforge.net Fri Jul 6 17:14:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 09:14:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-436259 ] exec*/spawn* problem with spaces in args Message-ID: Bugs item #436259, was opened at 2001-06-25 20:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436259&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Ben Hutchings (wom-work) >Assigned to: Tim Peters (tim_one) Summary: exec*/spawn* problem with spaces in args Initial Comment: DOS and Windows processes are not given an argument vector, as Unix processes are; instead they are given a command line and are expected to perform any necessary argument parsing themselves. Each C run-time library must convert command lines into argument vectors for the main() function, and if it includes exec* and spawn* functions then those must convert argument vectors into a command-line. Naturally, the various implementations differ in interesting ways. The Visual C++ run-time library (MSVCRT) implementation of the exec* and spawn* functions is particularly awful in that it simply concatenates the strings with spaces in-between (see source file cenvarg.c), which means that arguments with embedded spaces are likely to turn into multiple arguments in the new process. Obviously, when Python is built using Visual C++, its os.exec* and os.spawn* functions behave in this way too. MS prefers to work around this bug (see Knowledge Base article Q145937) rather than to fix it. Therefore I think Python must work around it too when built with Visual C++. I experimented with MSVCRT and Cygwin (using the attached program print_args.c) and could not find a way to convert an argument vector into a command line that they would both convert back to the same argument vector, but I got close. MSVCRT's parser requires spaces that are part of an argument to be enclosed in double-quotes. The double-quotes do not have to enclose the whole argument. Literal double-quotes must be escaped by preceding them with a backslash. If an argument contains literal backslashes before a literal or delimiting double-quote, those backslashes must be escaped by doubling them. If there is an unmatched enclosing double-quote then the parser behaves as if there was another double-quote at the end of the line. Cygwin's parser requires spaces that are part of an argument to be enclosed in double-quotes. The double-quotes do not have to enclose the whole argument. Literal double-quotes may be escaped by preceding them with a backslash, but then they count as enclosing double-quote as well, which appears to be a bug. They may also be escaped by doubling them, in which case they must be enclosed in double-quotes; since MSVCRT does not accept this, it's useless. As far as I can see, literal backslashes before a literal double-quote must not be escaped and literal backslashes before an enclosing double-quote *cannot* be escaped. It's really quite hard to understand what its rules are for backslashes and double-quotes, and I think it's broken. If there is an unmatched enclosing double-quote then the parser behaves as if there was another double-quote at the end of the line. Here's a Python version of a partial fix for use in nt.exec* and nt.spawn*. This function modifies argument strings so that the resulting command line will satisfy programs that use MSVCRT, and programs that use Cygwin if that's possible. def escape(arg): import re # If arg contains no space or double-quote then # no escaping is needed. if not re.search(r'[ "]', arg): return arg # Otherwise the argument must be quoted and all # double-quotes, preceding backslashes, and # trailing backslashes, must be escaped. def repl(match): if match.group(2): return match.group(1) * 2 + '\"' else: return match.group(1) * 2 return '"' + re.sub(r'(\*)("|$)', repl, arg) + '"' This could perhaps be used as a workaround for the problem. Unfortunately it would conflict with workarounds implemented at the Python level (which I have been using for a while). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436259&group_id=5470 From noreply@sourceforge.net Fri Jul 6 17:14:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 09:14:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-437472 ] MacPy21: sre "recursion limit" bug Message-ID: Bugs item #437472, was opened at 2001-06-29 14:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437472&group_id=5470 Category: Regular Expressions Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fredrik Lundh (effbot) >Summary: MacPy21: sre "recursion limit" bug Initial Comment: As of Python 2.0, the sre module had bug wherein a "RuntimeError: maximum recursion limit exceeded" would be raised whenever an expression matched something on the order of 16,000+ characters. The bug, nominally fixed in time for Python 2.1, is still present in MacPython 2.1, as evidenced by the following transcript copied from an interactive session with the interpreter. Note success with pre module, however. It makes me curious, since the bug appears to be fixed in WinPython 2.1, whether the correct source was used when compiling MacPython 2.1.... ========== Python 2.1 (#92, Apr 24 2001, 23:59:23) [CW PPC GUSI2 THREADS] on mac >>> import sre, pre, string >>> l = ["XXX", "%"*20000, "XXX"] >>> sre_regex = sre.compile(r"XXX.*?XXX") >>> match_object = sre_regex.search(string.join(l)) Traceback (most recent call last): File "", line 1, in ? RuntimeError: maximum recursion limit exceeded >>> ### Above error first reported upon release of sre with Python 2.0 ### >>> ### Bug supposedly fixed in Python 2.0.1 release (no Mac version, I know) ### >>> pre_regex = pre.compile(r"XXX.*XXX") >>> match_object = pre_regex.search(string.join(l)) >>> match_object >>> ### Note above success with pre module instead of sre ### >>> ### Wrong sre module source used when compiling MacPython 2.1? ### ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-07-02 01:58 Message: Logged In: YES user_id=45365 When I try this in a MacPython build from the CVS repository the sre example does not crash, but match_object ends up as None. Also not the behaviour I expect... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437472&group_id=5470 From noreply@sourceforge.net Fri Jul 6 17:14:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 09:14:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-436596 ] re.findall() bad with third argument Message-ID: Bugs item #436596, was opened at 2001-06-26 19:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436596&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fredrik Lundh (effbot) Summary: re.findall() bad with third argument Initial Comment: On Wed, 27 Jun 2001, Dan Tropp wrote: > I tried these in my python shell. Why do the last two give what they do? > > >>> print re.findall('<.*?>',' ') > ['', '', '', ''] > >>> print re.findall('<.*?>','<1> \n<3> ') > ['<1>', '', '<3>', ''] > >>> print re.findall('<.*?>','<1> \n<3> ', re.I|re.S) > [] > >>> print re.findall('<.*?>','<1> \n<3> ', re.I) > ['', '<3>', ''] Now this is curious, because according to the documentation at: http://python.org/doc/current/lib/Contents_of_Module_re .html re.findall() is only supposed to take in two arguments. In fact, in Python 1.52, Python complains that: ### # in Python 1.52: >> print re.findall('<.*?>','<1> \n<3> ', re.I) Traceback (innermost last): File "", line 1, in ? TypeError: too many arguments; expected 2, got 3 ## Let me check if the same behavior happens in 2.1: ### # in Python 2.1 >>> re.findall('<.*?>','<1> \n<3> ', re.I) ['', '<3>', ''] ### Now that is weird! This looks like it might be a bug. Let's take a look at the source code, to see why it's doing that. ### ## source code in sre.py def findall(pattern, string, maxsplit=0): """Return a list of all non-overlapping matches in the string. If one or more groups are present in the pattern, return a list of groups; this will be a list of tuples if the pattern has more than one group. Empty matches are included in the result.""" return _compile(pattern, 0).findall(string, maxsplit) ### Weird! findall() in its current incarnation does take in a third argument, contrary to the HTML documentation. But this makes no sense to me. Why should findall need a maxsplit parameter, when maxsplit is something that the split()ing operator works with? This really looks like a bug to me. Hmmm... well, the definition to findall() is adjacent to split(), so perhaps someone made a mistake and accidently added maxsplit as an argument. I believe that the corrected code in sre.py should be: ### def findall(pattern, string): """Return a list of all non-overlapping matches in the string. If one or more groups are present in the pattern, return a list of groups; this will be a list of tuples if the pattern has more than one group. Empty matches are included in the result.""" return _compile(pattern, 0).findall(string) ### instead. Ever since June 1, 2000, the findall() code in sre.py has contained this weird behavior: http://cvs.sourceforge.net/cgi- bin/viewcvs.cgi/python/python/dist/src/Lib/sre.py? rev=1.5&content-type=text/vnd.viewcvs-markup and even in the current development sources, it still has it! http://cvs.sourceforge.net/cgi- bin/viewcvs.cgi/python/python/dist/src/Lib/sre.py? rev=1.25.2.1&content-type=text/vnd.viewcvs-markup Dan, I think we should report this to the Implementors and see what they think about it. Good catch! *grin* Do you want to submit this to sourceforge? ---------------------------------------------------------------------- Comment By: Danny Yoo (dyoo) Date: 2001-06-27 08:30 Message: Logged In: YES user_id=49843 More details here: http://mail.python.org/pipermail/tutor/2001-June/006891.html ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436596&group_id=5470 From noreply@sourceforge.net Fri Jul 6 17:16:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 09:16:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-426866 ] urllib and socket fail with MS proxy Message-ID: Bugs item #426866, was opened at 2001-05-23 23:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426866&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: urllib and socket fail with MS proxy Initial Comment: Both urllib and socket fail to work with MS proxy with winsock client install. urllib's proxy detection will correctly detect the existing of the proxy server but fail to work with it. It will return an empty page when an read() is issued. socket will report 1006 winsock error. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-07-06 09:16 Message: Logged In: YES user_id=31392 Can you provide more details? What is MS proxy? What URLs have you tried and what exactly is the response -- headers would help? Under what conditions does socket raise a winsock error? Do socket and urllib work on your platform without the proxy? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426866&group_id=5470 From noreply@sourceforge.net Fri Jul 6 17:16:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 09:16:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-416901 ] 2.1 on OpenBSD 2.8: lots of bugs @ build Message-ID: Bugs item #416901, was opened at 2001-04-17 17:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416901&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brad Allen (valaulmo) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: 2.1 on OpenBSD 2.8: lots of bugs @ build Initial Comment: I am doing a survey of current distributed information systems, to see if they are close to what they should be (I figured out what they should be in 1984), and am forced to find a Python which Mojo Nation is compatible with. I will probably go back to Python 2.0, but since the latest released version (released today!) was 2.1, I just started there (since the stable one for OpenBSD 2.8 was way back at Python 1.6 and I figured anything past that was experimenting anyway). --- Python 2.1 on OpenBSD 2.8 with Pentium I: I'm getting these warnings while compiling Python 2.1 on OpenBSD 2.8: cc -o python \ Modules/python.o \ libpython2.1.a -lc_r -lutil -L/usr/local/lib -lz -lm ./Modules/posixmodule.c:2995: warning: this program uses setreuid(), which is deprecated. ./Modules/posixmodule.c:3014: warning: this program uses setregid(), which is deprecated. ./Modules/posixmodule.c:4147: warning: tempnam() possibly used unsafely; consider using mkstemp() ./Modules/posixmodule.c:4193: warning: tmpnam() possibly used unsafely; consider using mkstemp() ld: libpython2.1.a(fileobject.o): RRS text relocation at 0x31168 for "_flockfile" ld: libpython2.1.a(fileobject.o): RRS text relocation at 0x311af for "_funlockfile" PYTHONPATH= ./python ./setup.py build running build Please consider fixing those things. --- *** HUNG test_bufio.py When running tests as "MAKE=gmake gmake test", it hung under test_bufio. It required a SIGKILL to stop. I tried two things: * Running test as README says manually with "python ...". python ./Lib/test/test_bufio.py This worked OK and produced no output that I was aware of (unless it was hidden). * Tried defining DONT_USE_FGETS_IN_GETLINE in the file where it was looked at (./Objects/fileobject.c). This did not help; it still hung. Running the test manually again at this point worked also. So, I had to find a way to skip that test (hid it in a subdirectory called HIDE). *** HUNG test_complex.py The same thing happened with test_complex.py: it hung during "...make test", but ran OK manually; then I hid it to skip. For test_dl, I got slightly different results; after the usual hanging, I then manually ran it and got: *** HUNG test_dl.py* Q:/usr/local/src/python/Python-2.1:2148$ python Lib/test/test_dl.py Traceback (most recent call last): File "Lib/test/test_dl.py", line 6, in ? import dl ImportError: No module named dl Q:/usr/local/src/python/Python-2.1:2149$ In each case, lots of CPU by the "python" process was used as its "hung" state. I waited approximately three minutes of CPU. A 133Megahertz Pentium with a CPU cache on a Dell computer is extremely fast, and ought to finish any test within two minutes. Tell me if I just failed to wait long enough for an increadibly inefficiently programmed test to complete, and I'll retry it. The fact that it did not respond to signals except KILL also indicates to me that it was comotose. (This discussion reminds me of a date where the person told me that the commands in Unix are very violent sounding and the names of the principles used by programmers are very anti-social. I'm glad someone thinks that way, since English itself is far, far worse, according to http://www.islandnet.com/~edonon/decoding.htm, and I said to myself "how can anybody use this language?" in disgust. Someday we'll fix that, too (and not just for historical politeness; for pureness of utility and efficiency -- snowballed efficiency!).) --- *** MEMORY FAULT test_fork1.py While the tests were running "test_fork1", I got a Memory Fault. Rerunning it manually worked, though, and I hid it also. (I did not test rerunning it.) While waiting for all these tests to hang, I got tired of it and now I want to request that you have all the tests run in parallel. That way, it is easier to weed out all the hanging ones in one shot. This is easy, right? *** HUNG test_compile.py Next to hang was this one: $ python ./Lib/test/test_compile.py Running tests on argument handling testing complex args 1 2 1 2 3 4 1 2 3 1 2 3 2 3 4 $ As you can see, it ran OK manually, and this time I had some output to look at. While looking at it I realized that I do not know if those are the expected results, and in the house I'm in, I have to listen to too much hollaring to be able to learn Python in a few minutes like I am usually able to do in proper environments. *** HUNG test_doctest.py test_doctest.py passed manually but automatically hung, too. It had too much output to include it all, but the last line said the test passed. *** HUNG & SEGFAULT test_threadedtempfile.py For test_threadedtempfile, I got a bad error: $ python Lib/test/test_threadedtempfile.py Creating Starting Reaping Segmentation fault (core dumped) $ rm *core $ python Lib/test/test_threadedtempfile.py Creating Starting Reaping ^C^C^C^Z ^Z^X^C Killed $ $ jobs [1]- Stopped less README [2]+ Stopped MAKE=gmake gmake test $ sync $ rm Lib/test/test_threadedt So far, a few tests ran better the second time than the first. Is the compiling working better than the interpreting? --- Brad Allen * ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416901&group_id=5470 From noreply@sourceforge.net Fri Jul 6 17:17:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 09:17:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-439104 ] Tuple richcompares has code-typo Message-ID: Bugs item #439104, was opened at 2001-07-06 09:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439104&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Tuple richcompares has code-typo Initial Comment: In the tupleobject.c source, there is a switch statement to handle rich compares. In the case of Py_LE, the *wrong* variable is used in the logical test. It uses 'ws <= ws' and it should be 'vs <= ws'. if (i >= vt->ob_size || i >= wt->ob_size) { /* No more items to compare -- compare sizes */ int vs = vt->ob_size; int ws = wt->ob_size; int cmp; PyObject *res; switch (op) { case Py_LT: cmp = vs < ws; break; ------> case Py_LE: cmp = ws <= ws; break; case Py_EQ: cmp = vs == ws; break; case Py_NE: cmp = vs != ws; break; case Py_GT: cmp = vs > ws; break; case Py_GE: cmp = vs >= ws; break; default: return NULL; /* cannot happen */ } if (cmp) res = Py_True; else res = Py_False; Py_INCREF(res); return res; } (This is in Python 2.1 stable release version) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439104&group_id=5470 From noreply@sourceforge.net Fri Jul 6 17:17:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 09:17:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-428555 ] IDLE crashes Message-ID: Bugs item #428555, was opened at 2001-05-29 23:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428555&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Guido van Rossum (gvanrossum) Summary: IDLE crashes Initial Comment: On Windows 2000 (havent tested other platforms) IDLE will crash if i run the following code (ditto for PythonWin) from Tkinter import * root = Tk() img = PhotoImage(root,file="somefile.gif") # the error here is that i used root as the name ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-05-31 19:58 Message: Logged In: NO I get the same problem. Idle locks up when I close the window created by this application. I'm using Python 2.1 on Win98SE with IDLE 0.8 and Tcl 8.3 Happens every time for me. I can't get IDLE back to the >>> prompt when I close the window. HELP! ---- from Tkinter import * def testwindow(mess): root = Tk() w = Label(root, text="[ %s ]" % mess) w.pack() root.mainloop() testwindow("Hello World") ---- ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428555&group_id=5470 From noreply@sourceforge.net Fri Jul 6 17:18:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 09:18:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-425370 ] socketmodule SSL free calls in wrong order Message-ID: Bugs item #425370, was opened at 2001-05-18 21:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425370&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Barry Warsaw (bwarsaw) Summary: socketmodule SSL free calls in wrong order Initial Comment: I was examining socketmodule.c and notice the following ordering of allocation and deallocation regarding SSL. static SSLObject * newSSLObject(PySocketSockObject *Sock, char *key_file, char *cert_file) { ... self->ctx = SSL_CTX_new(SSLv23_method()); /* Set up context */ ... self->ssl = SSL_new(self->ctx); /* New ssl struct */ ... } static void SSL_dealloc(SSLObject *self) { ... SSL_CTX_free(self->ctx); SSL_free(self->ssl); ... } Perhaps it works for now, but I think that the order of free() calls in SSL_dealloc should be reversed. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-07-06 09:18 Message: Logged In: YES user_id=31392 Barry, This is a memory leak/free problem, right? So you get it. Seriously, sounds like this would be easy to fix. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425370&group_id=5470 From noreply@sourceforge.net Fri Jul 6 17:20:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 09:20:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-419873 ] ThreadingTCPServer invalidating sockets Message-ID: Bugs item #419873, was opened at 2001-04-28 16:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419873&group_id=5470 Category: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Guido van Rossum (gvanrossum) Summary: ThreadingTCPServer invalidating sockets Initial Comment: running this: import SocketServer class TestServer(SocketServer.ThreadingTCPServer): def __init__(self, server_address, RequestHandlerClass): SocketServer.ThreadingTCPServer.__init__(self, server_address, RequestHandlerClass) self.quit = 0 def process_request(self, request, client_address): print 'socket in process_request = %s' % request print 'id(socket) in process_request = %d' % id(request) SocketServer.ThreadingTCPServer.process_request(self, request, client_address) def finish_request(self, request, client_address): print 'socket in finish_request = %s' % request print 'id(socket) in finish_request = %d' % id(request) self.RequestHandlerClass(request, client_address, self) def get_request(self): conn, addr = self.socket.accept() print 'socket in get_request = %s' % conn print 'id(socket) in get_request = %d' % id(conn) return conn,addr if __name__ == '__main__': s = TestServer(('',9950), SocketServer.BaseRequestHandler) s.handle_request() s.server_close() results in the following output (when connected to remotely): socket in get_request = id(socket) in get_request = 135335216 socket in process_request = id(socket) in process_request = 135335216 socket in finish_request = id(socket) in finish_request = 135335216 between in the thread-creation in process_request, the socket's fd changes to -1. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-05-04 14:10 Message: Logged In: NO Thanks, that solves the problem. ---------------------------------------------------------------------- Comment By: Jon Riehl (jriehl) Date: 2001-05-01 14:25 Message: Logged In: YES user_id=22448 See comments for bug #417845. BaseServer.handle_request() potentially (more like consistently) calls close_request() before the thread spun in process_request() is able to complete. A work around is shown in bug #417845 (overload close_request() to do nothing instead of closing the socket.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419873&group_id=5470 From noreply@sourceforge.net Fri Jul 6 17:21:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 09:21:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-437879 ] SocketServer.py related problems Message-ID: Bugs item #437879, was opened at 2001-07-02 05:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437879&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Guido van Rossum (gvanrossum) Summary: SocketServer.py related problems Initial Comment: I tried several third-party proxy servers for Python (munchy,webdebug) go get working with Python 2.1 under Linux i386. But all fail with similar problems: Under 2.1: andreas@yetix:/home/andreas/src/munchy-0.7: python2.1 munchy.py 8006 Starting proxy on port 8006 Exception in thread Thread-1: Traceback (most recent call last): File "/opt/python-2.1/lib/python2.1/threading.py", line 378, in __bootstrap self.run() File "/opt/python-2.1/lib/python2.1/threading.py", line 366, in run apply(self.__target, self.__args, self.__kwargs) File "/opt/python-2.1/lib/python2.1/SocketServer.py", line 246, in finish_request self.RequestHandlerClass(request, client_address, self) File "/opt/python-2.1/lib/python2.1/SocketServer.py", line 494, in __init__ self.setup() File "/opt/python-2.1/lib/python2.1/SocketServer.py", line 537, in setup self.rfile = self.connection.makefile('rb', self.rbufsize) error: (9, 'Bad file descriptor') I could not track down the problem :-( Andreas ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-06 09:21 Message: Logged In: YES user_id=6380 Andreas, do these work when used with Python 2.0? Then it could be related to SF bug 417845. Try the workaround listed there and let me know the result. (Is this a DC job? Then I can raise the priority.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437879&group_id=5470 From noreply@sourceforge.net Fri Jul 6 17:23:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 09:23:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-433854 ] Wrong sys.path in weird situation Message-ID: Bugs item #433854, was opened at 2001-06-17 00:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433854&group_id=5470 >Category: Python Interpreter Core Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Nicholas Riley (nriley) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong sys.path in weird situation Initial Comment: I swear, this was my normal setup! :-) Python 2.1 on IRIX 6.5.10. % echo $PYTHONPATH /home/reed/njriley/usr/lib/python2.1/site-packages % echo $PATH /home/reed/njriley/bin/sgi:/home/reed/njriley/bin:/usr/bin/X11:/usr/local/bin:/local/bin:/usr/dcs/software/unsupported/bin:/usr/bsd:/usr/sbin:/usr/bin:/bin:/usr/etc:/etc % python Python 2.1 (#2, Jun 17 2001, 01:43:04) [C] on irix6 Type "copyright", "credits" or "license" for more information. >>> import sys; print sys.path ['', '/home/reed/njriley/usr/lib/python2.1/site-packages', '/home/reed/njriley/encap/python-2.1/lib/python2.1', '/home/reed/njriley/encap/python-2.1/lib/python2.1/plat-irix6', '/home/reed/njriley/encap/python-2.1/lib/python2.1/lib-tk', '/home/reed/njriley/encap/python-2.1/lib/python2.1/lib-dynload'] >>> ^D % ls -d /home/reed/njriley/encap gls: /home/reed/njriley/encap: No such file or directory So, how did it get there? This way: lrwx--x--x 1 njriley reed 7 Jun 17 01:55 bin -> usr/bin/ lrwxr-xr-x 1 njriley reed 30 Jun 17 01:46 bin/python -> ../encap/python-2.1/bin/python* If I replace ~/bin with ~/usr/bin in my PATH, everything is fine. Python is trying to resolve the second symlink before resolving the first one, thereby causing a problem. --Nicholas ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433854&group_id=5470 From noreply@sourceforge.net Fri Jul 6 17:25:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 09:25:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-436131 ] freeze: global symbols not exported Message-ID: Bugs item #436131, was opened at 2001-06-25 10:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436131&group_id=5470 Category: demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Charles Schwieters (chuckorama) >Assigned to: Mark Hammond (mhammond) Summary: freeze: global symbols not exported Initial Comment: python-2.1 linux-2.2, others? the freeze tool does not export global symbols. As a result the frozen executable fails with unresolved symbols in shared objects. fix: include the LINKFORSHARED flag in freeze.py: *** freeze.py~ Tue Mar 20 15:43:33 2001 --- freeze.py Fri Jun 22 14:36:23 2001 *************** *** 434,440 **** somevars[key] = makevars[key] somevars['CFLAGS'] = string.join(cflags) # override ! files = ['$(OPT)', '$(LDFLAGS)', base_config_c, base_frozen_c] + \ files + supp_sources + addfiles + libs + \ ['$(MODLIBS)', '$(LIBS)', '$(SYSLIBS)'] --- 434,440 ---- somevars[key] = makevars[key] somevars['CFLAGS'] = string.join(cflags) # override ! files = ['$(OPT)', '$(LDFLAGS)', '$(LINKFORSHARED)',base_config_c, base_frozen_c] + \ files + supp_sources + addfiles + libs + \ ['$(MODLIBS)', '$(LIBS)', '$(SYSLIBS)'] ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436131&group_id=5470 From noreply@sourceforge.net Fri Jul 6 17:26:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 09:26:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-424106 ] PyImport_ExecCodeModule not correct Message-ID: Bugs item #424106, was opened at 2001-05-14 18:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424106&group_id=5470 >Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) >Assigned to: Tim Peters (tim_one) Summary: PyImport_ExecCodeModule not correct Initial Comment: PyImport_ExecCodeModule doesn't handle package imports correctly. Using it to import a module "A.B" will result in an entry in sys.modules of "A.B" but no information for module "A" will be created. The documentation in the C API reference makes no statement about this - just that the module name may be of the form "package.module". Looking at the code in import.c, there is definitely no handling of the package. If this is the intended behaviour, please amend the documentation (and possibly give some hint as to how one _should_ go about importing a code object in a package structure ;) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424106&group_id=5470 From noreply@sourceforge.net Fri Jul 6 17:27:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 09:27:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-434944 ] setup.py - nonstandard paths Message-ID: Bugs item #434944, was opened at 2001-06-20 15:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434944&group_id=5470 Category: Build Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Robert Minsk (rminsk) >Assigned to: A.M. Kuchling (akuchling) Summary: setup.py - nonstandard paths Initial Comment: In my build environment I have to ensure that the same version of each software package is available across many different platforms. To do this I compile code into a directory structure when the root path of /usr/tools/fw. So a tools like flex would result in files /usr/tools/fw/bin/flex, /usr/tools/fw/include/FlexLexer.h, /usr/tools/fw/lib/libfl.a, ... In the Python 2.1 build environment it does not seem that you can pass extra search paths too setup.py. I must either hack setup.py to look in /usr/tools/fw or manually add each module to Modules/Setup. It would be nice for setup.py to be able to take extra search paths. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434944&group_id=5470 From noreply@sourceforge.net Fri Jul 6 17:27:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 09:27:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-429361 ] popen2.Popen3.wait() exit code Message-ID: Bugs item #429361, was opened at 2001-06-01 09:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429361&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: eXom (jkuan) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: popen2.Popen3.wait() exit code Initial Comment: I found there is no documentation for this behaviour or is there any that I have missed out. Why the value returned from wait() is multipled with 256 to the return code of child process? E.g. a = popen2.Popen3("sh -c 'exit 0'") a.wait( ) ---> 0 a = popen2.Popen3("sh -c 'exit 1'") a.wait( ) ---> 256 a = popen2.Popen3("sh -c 'exit 2'") a.wait( ) ---> 512 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429361&group_id=5470 From noreply@sourceforge.net Fri Jul 6 17:27:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 09:27:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-439104 ] Tuple richcompares has code-typo Message-ID: Bugs item #439104, was opened at 2001-07-06 09:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439104&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Neil Schemenauer (nascheme) Summary: Tuple richcompares has code-typo Initial Comment: In the tupleobject.c source, there is a switch statement to handle rich compares. In the case of Py_LE, the *wrong* variable is used in the logical test. It uses 'ws <= ws' and it should be 'vs <= ws'. if (i >= vt->ob_size || i >= wt->ob_size) { /* No more items to compare -- compare sizes */ int vs = vt->ob_size; int ws = wt->ob_size; int cmp; PyObject *res; switch (op) { case Py_LT: cmp = vs < ws; break; ------> case Py_LE: cmp = ws <= ws; break; case Py_EQ: cmp = vs == ws; break; case Py_NE: cmp = vs != ws; break; case Py_GT: cmp = vs > ws; break; case Py_GE: cmp = vs >= ws; break; default: return NULL; /* cannot happen */ } if (cmp) res = Py_True; else res = Py_False; Py_INCREF(res); return res; } (This is in Python 2.1 stable release version) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439104&group_id=5470 From noreply@sourceforge.net Fri Jul 6 17:29:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 09:29:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-424951 ] ThreadingTCPServer file handle errors. Message-ID: Bugs item #424951, was opened at 2001-05-17 12:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424951&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Largent (jlargent) >Assigned to: Guido van Rossum (gvanrossum) Summary: ThreadingTCPServer file handle errors. Initial Comment: When running a server using ThreadingTCPServer if the server sit for several minutes between requests the first request it receives will error with a bad file handle error. Python 2.1 (#1, Apr 20 2001, 15:04:11) [GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2 #!/usr/bin/python2 from SocketServer import ThreadingTCPServer, BaseRequestHandler class myHandler (BaseRequestHandler): def handle(self): while 1: data = self.request.recv(1024) if not data: break self.request.send('%s' % (data)) self.request.close if __name__ == '__main__': addr = ('localhost', 50000) s = ThreadingTCPServer(addr, myHandler) s.serve_forever() Start this server wait several min then using the echo-client.py from oreilly Programming Python to send it data. Traceback (most recent call last): File "/var/tmp/python2-2.1-root/usr/lib/python2.1/threading.py", line 378, in __bootstrap self.run() File "/var/tmp/python2-2.1-root/usr/lib/python2.1/threading.py", line 366, in run apply(self.__target, self.__args, self.__kwargs) File "/var/tmp/python2-2.1-root/usr/lib/python2.1/SocketServer.py", line 246, in finish_request self.RequestHandlerClass(request, client_address, self) File "/var/tmp/python2-2.1-root/usr/lib/python2.1/SocketServer.py", line 495, in __init__ self.handle() File "./server.py", line 10, in handle data = self.request.recv(1024) error: (9, 'Bad file descriptor') Any requests sent right after this will complete properly. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424951&group_id=5470 From noreply@sourceforge.net Fri Jul 6 17:32:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 09:32:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-437879 ] SocketServer.py related problems Message-ID: Bugs item #437879, was opened at 2001-07-02 05:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437879&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Guido van Rossum (gvanrossum) Summary: SocketServer.py related problems Initial Comment: I tried several third-party proxy servers for Python (munchy,webdebug) go get working with Python 2.1 under Linux i386. But all fail with similar problems: Under 2.1: andreas@yetix:/home/andreas/src/munchy-0.7: python2.1 munchy.py 8006 Starting proxy on port 8006 Exception in thread Thread-1: Traceback (most recent call last): File "/opt/python-2.1/lib/python2.1/threading.py", line 378, in __bootstrap self.run() File "/opt/python-2.1/lib/python2.1/threading.py", line 366, in run apply(self.__target, self.__args, self.__kwargs) File "/opt/python-2.1/lib/python2.1/SocketServer.py", line 246, in finish_request self.RequestHandlerClass(request, client_address, self) File "/opt/python-2.1/lib/python2.1/SocketServer.py", line 494, in __init__ self.setup() File "/opt/python-2.1/lib/python2.1/SocketServer.py", line 537, in setup self.rfile = self.connection.makefile('rb', self.rbufsize) error: (9, 'Bad file descriptor') I could not track down the problem :-( Andreas ---------------------------------------------------------------------- >Comment By: Andreas Jung (ajung) Date: 2001-07-06 09:32 Message: Logged In: YES user_id=11084 I could not run the webDebug program with 2.0 because it raised a regular expression related inside the application code so I did not waste more time on it. It was some kind of DC related job - I needed some tools to monitor WebDAV traffic between a client and Zope. I get around the problem by using ethereal for snooping the traffice. Andreas ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-06 09:21 Message: Logged In: YES user_id=6380 Andreas, do these work when used with Python 2.0? Then it could be related to SF bug 417845. Try the workaround listed there and let me know the result. (Is this a DC job? Then I can raise the priority.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437879&group_id=5470 From noreply@sourceforge.net Fri Jul 6 17:27:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 09:27:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-434143 ] calendar module broken for 1900 Message-ID: Bugs item #434143, was opened at 2001-06-18 04:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434143&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexandre Fayolle (afayolle) >Assigned to: Skip Montanaro (montanaro) Summary: calendar module broken for 1900 Initial Comment: Hi there, this is a 'feature' I met on both 1.5.2 and 2.1. >>> import calendar >>> calendar.prcal(1865) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/calendar.py", line 160, in prcal print calendar(year, w, l, c), File "/usr/lib/python2.1/calendar.py", line 179, in calendar cal = monthcalendar(year, amonth) File "/usr/lib/python2.1/calendar.py", line 85, in monthcalendar day1, ndays = monthrange(year, month) File "/usr/lib/python2.1/calendar.py", line 78, in monthrange day1 = weekday(year, month, 1) File "/usr/lib/python2.1/calendar.py", line 69, in weekday secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0)) ValueError: year out of range (00-99, 1900-*) (note that the documentation only refers to 1970 as a possible limit, and does not mention how dates in 00-99 range are processed) Now if I try to get the calendar for year 1900 (which is supposed to work according to the message hereabove), I get >>> calendar.prcal(1900) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/calendar.py", line 160, in prcal print calendar(year, w, l, c), File "/usr/lib/python2.1/calendar.py", line 179, in calendar cal = monthcalendar(year, amonth) File "/usr/lib/python2.1/calendar.py", line 85, in monthcalendar day1, ndays = monthrange(year, month) File "/usr/lib/python2.1/calendar.py", line 78, in monthrange day1 = weekday(year, month, 1) File "/usr/lib/python2.1/calendar.py", line 69, in weekday secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0)) OverflowError: mktime argument out of range I guess this is low priority. Cheers Alexandre Fayolle ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434143&group_id=5470 From noreply@sourceforge.net Fri Jul 6 18:19:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 10:19:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-429361 ] popen2.Popen3.wait() exit code Message-ID: Bugs item #429361, was opened at 2001-06-01 09:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429361&group_id=5470 >Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: eXom (jkuan) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: popen2.Popen3.wait() exit code Initial Comment: I found there is no documentation for this behaviour or is there any that I have missed out. Why the value returned from wait() is multipled with 256 to the return code of child process? E.g. a = popen2.Popen3("sh -c 'exit 0'") a.wait( ) ---> 0 a = popen2.Popen3("sh -c 'exit 1'") a.wait( ) ---> 256 a = popen2.Popen3("sh -c 'exit 2'") a.wait( ) ---> 512 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-06 10:19 Message: Logged In: YES user_id=3066 Fixed in Doc/lib/libpopen2.tex revisions 1.14 and 1.13.6.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429361&group_id=5470 From noreply@sourceforge.net Fri Jul 6 18:24:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 10:24:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-432369 ] ConfigParser: problem w/ mixed-case opts Message-ID: Bugs item #432369, was opened at 2001-06-12 03:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432369&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ConfigParser: problem w/ mixed-case opts Initial Comment: When using mixed-case option-names, ConfigParser raises a KeyError on multi-line options like this one: """ Symptoms: bla blubber; some symptom; some other symptom; yet another symptom """ Reason: 'optname' is not converted permanently but only when storing the first value part. The following patch solves the problem. Regards +++hartmut ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-06 10:24 Message: Logged In: YES user_id=3066 Fixed in Lib/ConfigParser.py revisions 1.33 and 1.32.4.1. Added a new test to the regression suite. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432369&group_id=5470 From noreply@sourceforge.net Fri Jul 6 18:42:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 10:42:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-439104 ] Tuple richcompares has code-typo Message-ID: Bugs item #439104, was opened at 2001-07-06 09:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439104&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Tim Peters (tim_one) Summary: Tuple richcompares has code-typo Initial Comment: In the tupleobject.c source, there is a switch statement to handle rich compares. In the case of Py_LE, the *wrong* variable is used in the logical test. It uses 'ws <= ws' and it should be 'vs <= ws'. if (i >= vt->ob_size || i >= wt->ob_size) { /* No more items to compare -- compare sizes */ int vs = vt->ob_size; int ws = wt->ob_size; int cmp; PyObject *res; switch (op) { case Py_LT: cmp = vs < ws; break; ------> case Py_LE: cmp = ws <= ws; break; case Py_EQ: cmp = vs == ws; break; case Py_NE: cmp = vs != ws; break; case Py_GT: cmp = vs > ws; break; case Py_GE: cmp = vs >= ws; break; default: return NULL; /* cannot happen */ } if (cmp) res = Py_True; else res = Py_False; Py_INCREF(res); return res; } (This is in Python 2.1 stable release version) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-06 10:42 Message: Logged In: YES user_id=31435 Assigned to me and boosted priority. This is already fixed in CVS, but there's an isomorphic error in list richcompares. Both are broken in the 2.1.1 maintenance branch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439104&group_id=5470 From noreply@sourceforge.net Fri Jul 6 18:49:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 10:49:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-439104 ] Tuple richcompares has code-typo Message-ID: Bugs item #439104, was opened at 2001-07-06 09:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439104&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: Tuple richcompares has code-typo Initial Comment: In the tupleobject.c source, there is a switch statement to handle rich compares. In the case of Py_LE, the *wrong* variable is used in the logical test. It uses 'ws <= ws' and it should be 'vs <= ws'. if (i >= vt->ob_size || i >= wt->ob_size) { /* No more items to compare -- compare sizes */ int vs = vt->ob_size; int ws = wt->ob_size; int cmp; PyObject *res; switch (op) { case Py_LT: cmp = vs < ws; break; ------> case Py_LE: cmp = ws <= ws; break; case Py_EQ: cmp = vs == ws; break; case Py_NE: cmp = vs != ws; break; case Py_GT: cmp = vs > ws; break; case Py_GE: cmp = vs >= ws; break; default: return NULL; /* cannot happen */ } if (cmp) res = Py_True; else res = Py_False; Py_INCREF(res); return res; } (This is in Python 2.1 stable release version) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-06 10:49 Message: Logged In: YES user_id=31435 In HEAD: Objects/listobject.c; new revision: 2.97 In release21-maint: Objects/listobject.c; new revision: 2.92.4.1 Objects/tupleobject.c; new revision: 2.48.4.3 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-06 10:42 Message: Logged In: YES user_id=31435 Assigned to me and boosted priority. This is already fixed in CVS, but there's an isomorphic error in list richcompares. Both are broken in the 2.1.1 maintenance branch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439104&group_id=5470 From noreply@sourceforge.net Fri Jul 6 19:40:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 11:40:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-434143 ] calendar module broken for 1900 Message-ID: Bugs item #434143, was opened at 2001-06-18 04:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434143&group_id=5470 >Category: Python Library >Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Alexandre Fayolle (afayolle) Assigned to: Skip Montanaro (montanaro) Summary: calendar module broken for 1900 Initial Comment: Hi there, this is a 'feature' I met on both 1.5.2 and 2.1. >>> import calendar >>> calendar.prcal(1865) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/calendar.py", line 160, in prcal print calendar(year, w, l, c), File "/usr/lib/python2.1/calendar.py", line 179, in calendar cal = monthcalendar(year, amonth) File "/usr/lib/python2.1/calendar.py", line 85, in monthcalendar day1, ndays = monthrange(year, month) File "/usr/lib/python2.1/calendar.py", line 78, in monthrange day1 = weekday(year, month, 1) File "/usr/lib/python2.1/calendar.py", line 69, in weekday secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0)) ValueError: year out of range (00-99, 1900-*) (note that the documentation only refers to 1970 as a possible limit, and does not mention how dates in 00-99 range are processed) Now if I try to get the calendar for year 1900 (which is supposed to work according to the message hereabove), I get >>> calendar.prcal(1900) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/calendar.py", line 160, in prcal print calendar(year, w, l, c), File "/usr/lib/python2.1/calendar.py", line 179, in calendar cal = monthcalendar(year, amonth) File "/usr/lib/python2.1/calendar.py", line 85, in monthcalendar day1, ndays = monthrange(year, month) File "/usr/lib/python2.1/calendar.py", line 78, in monthrange day1 = weekday(year, month, 1) File "/usr/lib/python2.1/calendar.py", line 69, in weekday secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0)) OverflowError: mktime argument out of range I guess this is low priority. Cheers Alexandre Fayolle ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2001-07-06 11:40 Message: Logged In: YES user_id=44345 calendar.py is a *very* old module. Version 1.1 has a date of 13-Oct-90. The message about the ranges almost certainly comes from the days when Guido and his pals at CWI were developing Python on Macs. I just tried: time.mktime((1900,1,1,0,0,0,0,0,0)) on my iMac and it works. If the year is 1899 it generates the traceback. A year of 1 is currently interpreted as 2001. I'm not sure this is worth fixing, other than to document the limitations better. If you want to display calendars perhaps you should look at Marc-Andre Lemburg's mx.DateTime module, which supports a much wider range of dates. Skip ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434143&group_id=5470 From noreply@sourceforge.net Fri Jul 6 21:54:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 13:54:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-436596 ] re.findall() bad with third argument Message-ID: Bugs item #436596, was opened at 2001-06-26 19:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436596&group_id=5470 >Category: Regular Expressions Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fredrik Lundh (effbot) Summary: re.findall() bad with third argument Initial Comment: On Wed, 27 Jun 2001, Dan Tropp wrote: > I tried these in my python shell. Why do the last two give what they do? > > >>> print re.findall('<.*?>',' ') > ['', '', '', ''] > >>> print re.findall('<.*?>','<1> \n<3> ') > ['<1>', '', '<3>', ''] > >>> print re.findall('<.*?>','<1> \n<3> ', re.I|re.S) > [] > >>> print re.findall('<.*?>','<1> \n<3> ', re.I) > ['', '<3>', ''] Now this is curious, because according to the documentation at: http://python.org/doc/current/lib/Contents_of_Module_re .html re.findall() is only supposed to take in two arguments. In fact, in Python 1.52, Python complains that: ### # in Python 1.52: >> print re.findall('<.*?>','<1> \n<3> ', re.I) Traceback (innermost last): File "", line 1, in ? TypeError: too many arguments; expected 2, got 3 ## Let me check if the same behavior happens in 2.1: ### # in Python 2.1 >>> re.findall('<.*?>','<1> \n<3> ', re.I) ['', '<3>', ''] ### Now that is weird! This looks like it might be a bug. Let's take a look at the source code, to see why it's doing that. ### ## source code in sre.py def findall(pattern, string, maxsplit=0): """Return a list of all non-overlapping matches in the string. If one or more groups are present in the pattern, return a list of groups; this will be a list of tuples if the pattern has more than one group. Empty matches are included in the result.""" return _compile(pattern, 0).findall(string, maxsplit) ### Weird! findall() in its current incarnation does take in a third argument, contrary to the HTML documentation. But this makes no sense to me. Why should findall need a maxsplit parameter, when maxsplit is something that the split()ing operator works with? This really looks like a bug to me. Hmmm... well, the definition to findall() is adjacent to split(), so perhaps someone made a mistake and accidently added maxsplit as an argument. I believe that the corrected code in sre.py should be: ### def findall(pattern, string): """Return a list of all non-overlapping matches in the string. If one or more groups are present in the pattern, return a list of groups; this will be a list of tuples if the pattern has more than one group. Empty matches are included in the result.""" return _compile(pattern, 0).findall(string) ### instead. Ever since June 1, 2000, the findall() code in sre.py has contained this weird behavior: http://cvs.sourceforge.net/cgi- bin/viewcvs.cgi/python/python/dist/src/Lib/sre.py? rev=1.5&content-type=text/vnd.viewcvs-markup and even in the current development sources, it still has it! http://cvs.sourceforge.net/cgi- bin/viewcvs.cgi/python/python/dist/src/Lib/sre.py? rev=1.25.2.1&content-type=text/vnd.viewcvs-markup Dan, I think we should report this to the Implementors and see what they think about it. Good catch! *grin* Do you want to submit this to sourceforge? ---------------------------------------------------------------------- Comment By: Danny Yoo (dyoo) Date: 2001-06-27 08:30 Message: Logged In: YES user_id=49843 More details here: http://mail.python.org/pipermail/tutor/2001-June/006891.html ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436596&group_id=5470 From noreply@sourceforge.net Fri Jul 6 22:36:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Jul 2001 14:36:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-437984 ] package name truncation to 50 chars. Message-ID: Bugs item #437984, was opened at 2001-07-02 11:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437984&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: chris tignor (ctignor) Assigned to: Nobody/Anonymous (nobody) Summary: package name truncation to 50 chars. Initial Comment: Truncation of package names to 50 characters once represented as strings becomes extremely confusing for development purposes, even more so when as it exists as an undocumented event. I request full package names be represented. Thank-you. ---------------------------------------------------------------------- >Comment By: chris tignor (ctignor) Date: 2001-07-06 14:36 Message: Logged In: YES user_id=255620 here is an exmaple: from com.ezways.data_mining.form_tools import TransitFormInputElement transitForm = TransitFormInputElement.TransitFormInputElement() print transitForm # below is what prints, no such thing (module/package/class) as TransitFormInput anywhere on the system ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-07-06 09:05 Message: Logged In: YES user_id=31392 Can you include a more specific description of the problem you are having? An example would go a long way. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437984&group_id=5470 From noreply@sourceforge.net Sun Jul 8 02:38:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Jul 2001 18:38:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-439012 ] Need doc: initial state of allocs Message-ID: Bugs item #439012, was opened at 2001-07-06 03:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439012&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Need doc: initial state of allocs Initial Comment: The Py_Malloc and PyObject_New/PyObject_NEW are not documented as to whether the memory they return is pre-initialized to zeros or not. In fact, PyObject_New/PyObject_NEW aren't documented anywhere for extension writers. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-07 18:38 Message: Logged In: YES user_id=3066 I've addressed most of this in my working copies, but am not yet ready to check it in, and not everything needed to fully resolve this has been written. For the current state of what's written, see the development version of the documentation on SourceForge: http://python.sourceforge.net/devel-docs/api/api.html ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439012&group_id=5470 From noreply@sourceforge.net Sun Jul 8 11:48:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Jul 2001 03:48:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-439436 ] time.strftime with "%z" incorrect Message-ID: Bugs item #439436, was opened at 2001-07-08 03:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439436&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: time.strftime with "%z" incorrect Initial Comment: Linux 2.2, glibc 2.1.3, Python 2.1 >>> import time >>> time.strftime("%Z", time.localtime(time.time())) 'MSD' >>> time.strftime("%z", time.localtime(time.time())) '+0000' While I believe the later should be: '+0400' At the same time: $ date +%z +0400 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439436&group_id=5470 From noreply@sourceforge.net Sun Jul 8 20:05:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Jul 2001 12:05:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-437395 ] RFC 2822 conformance Message-ID: Bugs item #437395, was opened at 2001-06-29 09:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437395&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Barry Warsaw (bwarsaw) Summary: RFC 2822 conformance Initial Comment: The rfc822 and smtplib modules need to be checked for conformance with RFC 2822, which obsoletes RFC 822. (Added this to the tracker so we don't lose track of this.) ---------------------------------------------------------------------- Comment By: Philip Hunt (philhunt) Date: 2001-07-08 12:05 Message: Logged In: YES user_id=236441 rfc822 *doesn't* conform to RFC2822. As an example, when we have a field From: From: A. N. Other then getaddr("From") returns ('', 'A.N.Other') which is incorrect. When the from line is changed to: From: From: A N Other then getaddr("From") correctly returns ('A N Other', 'another@nowhere.org.ca') The relevant parts of the syntax specified in rfc2822 are: from = "From:" mailbox-list CRLF mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list mailbox = name-addr / addr-spec name-addr = [display-name] angle-addr display-name = phrase phrase = 1*word / obs-phrase obs-phrase = word *(word / "." / CFWS) >From rfc2822, section 4.1: Note: The "period" (or "full stop") character (".") in obs-phrase is not a form that was allowed in earlier versions of this or any other standard. Period (nor any other character from specials) was not allowed in phrase because it introduced a parsing difficulty distinguishing between phrases and portions of an addr-spec (see section 4.4). It appears here because the period character is currently used in many messages in the display-name portion of addresses, especially for initials in names, and therefore must be interpreted properly. In the future, period may appear in the regular syntax of phrase. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437395&group_id=5470 From noreply@sourceforge.net Sun Jul 8 22:04:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Jul 2001 14:04:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-438735 ] #ifndef WITHOUT_COMPLEX in config.c Message-ID: Bugs item #438735, was opened at 2001-07-05 04:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438735&group_id=5470 Category: Build Group: Not a Bug >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: #ifndef WITHOUT_COMPLEX in config.c Initial Comment: Not really a bug. There's two #ifndef WITHOUT_COMPLEX missing in config.c : around the definition : extern void initcmath(void); (line 13 ) and around the utilisation : {"cmath", initcmath}, line 64 in order to compile without complex. To compile with the PC_build workspace, I also add a #ifndef WITHOUT_COMPLEX around the cmathmodule.c file. Version Python2.1 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-08 14:04 Message: Logged In: YES user_id=21627 This is not a bug. To not compile cmath, simply remove it from Modules/Setup; config.c is a generated file. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438735&group_id=5470 From noreply@sourceforge.net Sun Jul 8 22:06:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Jul 2001 14:06:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-438786 ] CVS 2.1.1c1 broken on osf1V4 Message-ID: Bugs item #438786, was opened at 2001-07-05 07:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Nobody/Anonymous (nobody) Summary: CVS 2.1.1c1 broken on osf1V4 Initial Comment: As of right now, the CVS branch for the 2.1 bugfix release cannot import the math module on my Digital Unix platform. ImportError: Unresolved symbol in /tmp_mnt/home/gball/usr/src/python/dist/src/build/lib.osf1-V4.0-alpha-2.1/math.so: __eprintf uname is OSF1 surya V4.0 878 alpha ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-08 14:06 Message: Logged In: YES user_id=21627 This sounds like a bug in your compiler installation. __eprintf is typically defined in libgcc.a; make sure you use a consistent compiler capable of building binaries for your system throughout the build process. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 From noreply@sourceforge.net Sun Jul 8 22:09:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Jul 2001 14:09:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-438931 ] ftplib crash Message-ID: Bugs item #438931, was opened at 2001-07-05 17:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438931&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ftplib crash Initial Comment: I've found a rather horrible problem when using ftplib. I'm running python2.1 and linux kernel 2.4.4 I haven't had a chance to check this out on any other machines, I don't want to bring down a server testing this. This code makes my system hang when I try to upload a file of 4 megs or 100 megs. It works for 22 bytes (my other test file): def copyDepot(self, depot): import ftplib, stat depot.mFullPath = "/tmp/" + depot.mFile ftp = ftplib.FTP(self.mHost) ftp.login(self.mUser,self.mPass) f = open(depot.mLocalPath, 'r+') ftp.storbinary("STOR " + depot.mFullPath, f, 8192) size = ftp.size(depot.mFullPath) lsize = os.stat(depot.mLocalPath)[stat.ST_SIZE] ftp.quit() print "Remote Size: ",size print "Local Size: ",lsize if size != os.stat(depot.mLocalPath)[stat.ST_SIZE]: raise "Size does not match!" Any ideas? Has anybody heard of something like this happening? What would you suggest I do to fix it if its not python? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-08 14:09 Message: Logged In: YES user_id=21627 Can you analyze in more detail as to how exactly the two files differ (e.g. finding a byte offset and a few bytes around the first difference)? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438931&group_id=5470 From noreply@sourceforge.net Sun Jul 8 22:14:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Jul 2001 14:14:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-439436 ] time.strftime with "%z" incorrect Message-ID: Bugs item #439436, was opened at 2001-07-08 03:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439436&group_id=5470 Category: Python Library Group: Platform-specific >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) >Summary: time.strftime with "%z" incorrect Initial Comment: Linux 2.2, glibc 2.1.3, Python 2.1 >>> import time >>> time.strftime("%Z", time.localtime(time.time())) 'MSD' >>> time.strftime("%z", time.localtime(time.time())) '+0000' While I believe the later should be: '+0400' At the same time: $ date +%z +0400 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-08 14:14 Message: Logged In: YES user_id=21627 I believe the bug is in your code. %z is not a valid format argument in strftime, so the implementation behaviour is undefined. In any case, whatever it does is the result of glibc doing so, so if you feel there is a bug, please report it as a glibc bug (using the glibcbug script). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439436&group_id=5470 From noreply@sourceforge.net Mon Jul 9 14:35:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Jul 2001 06:35:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-439710 ] User-defined mime.types file Message-ID: Bugs item #439710, was opened at 2001-07-09 06:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439710&group_id=5470 Category: Extension Modules Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: User-defined mime.types file Initial Comment: Zope users sometimes asks to add additional mime.types entries to Zope. Zopes mime-types handling is mostly based on mimetypes.py. In such cases users should be able to maintain their own mime.types files. mimetypes.py currently tries to look for mime.types files in 4 hardcoded locations. It would be more convinient to specify additional locations e.g. by an env. var that holds a list of additional locations or by any other mechanism that allows user-defined locations. The hardcoded locations also don't work on Windows. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439710&group_id=5470 From noreply@sourceforge.net Mon Jul 9 14:57:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Jul 2001 06:57:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-437152 ] compiling source code fails on aix 4.3.1 Message-ID: Bugs item #437152, was opened at 2001-06-28 11:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437152&group_id=5470 Category: Installation >Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: birgit kellner (birgitk) >Assigned to: Thomas Wouters (twouters) Summary: compiling source code fails on aix 4.3.1 Initial Comment: python version 2.1, to be installed on an ibm rs/6000 r40, running aix 4.31 (apache 1.3.12). configure runs fine, but make stops with the following error: "fatal error in /usr/lpp/xlC/exe/xlCcode: signal 24 received the error code from the last command is 251" ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-09 06:57 Message: Logged In: YES user_id=34209 Sorry, but we need *way* more information than this. It looks like an internal bug in the xlC AIX compiler, since it complains about a signal being raised. Does the compiler give any clue what the 'last command' is, the one that returned 'error code 251' ? Any clue what errorcode 251 is supposed to be ? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437152&group_id=5470 From noreply@sourceforge.net Mon Jul 9 14:57:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Jul 2001 06:57:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-427604 ] Lang Ref, grammar productions should be hyperlinked Message-ID: Bugs item #427604, was opened at 2001-05-26 14:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427604&group_id=5470 Category: Documentation Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Lang Ref, grammar productions should be hyperlinked Initial Comment: The grammar for integer and longinteger given in section 2.4.5 of the Language Reference is missing a definition for the "digit" term. I think, the grammar should have a production like this: digit: "0"..."9" ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-09 06:57 Message: Logged In: YES user_id=3066 I committed changes to make this happen last Friday (6 June 2001); sorry for not closing this promptly. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-05-30 14:39 Message: Logged In: YES user_id=3066 (I thought I updated this yesterday, but I guess not.) I'm re-classifying this as a feature request for hyperlinked productions in the grammar. I showed Tim a quick prototype yesterday, and will post a revised version shortly at: http://python.sourceforge.net/devel-docs/ref/ref.html It's starting to look pretty cool, but there are still glitches. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-05-26 14:30 Message: Logged In: YES user_id=31435 "digit" is already defined, but in section 2.3 (Identifiers and keywords). Fred, how much unbearable pain would it be to come with a (hyperlinked in HTML) grammar production index? There are many cases where a production referenced in one section is defined in another, and it's very hard to find the definition whenever that occurs. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427604&group_id=5470 From noreply@sourceforge.net Mon Jul 9 15:06:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Jul 2001 07:06:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-435455 ] Python 2.0.1c1 fails to build on RH7.1 Message-ID: Bugs item #435455, was opened at 2001-06-22 06:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=435455&group_id=5470 >Category: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Ole H. Nielsen (ohnielse) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.0.1c1 fails to build on RH7.1 Initial Comment: Building Python 2.0.1c1 on a RedHat 7.1 (2.4.2-2 on i586) fails at this point: cd Modules; make OPT="-g -O2 -Wall -Wstrict-prototypes -fPIC" VERSION="2.0" \ prefix="/usr/local" exec_prefix="/usr/local" \ sharedmods make[1]: Entering directory `/scratch/ohnielse/Python-2.0.1/Modules' gcc -fpic -g -O2 -Wall -Wstrict-prototypes -fPIC -I./../Include -I.. -DHAVE_CONFIG_H -c ./bsddbmodule.c ./bsddbmodule.c: In function `newdbhashobject': ./bsddbmodule.c:55: `HASHINFO' undeclared (first use in this function) ./bsddbmodule.c:55: (Each undeclared identifier is reported only once ./bsddbmodule.c:55: for each function it appears in.) ./bsddbmodule.c:55: parse error before `info' ./bsddbmodule.c:60: `info' undeclared (first use in this function) ./bsddbmodule.c:71: warning: implicit declaration of function `dbopen' ./bsddbmodule.c:71: warning: assignment makes pointer from integer without a cast ./bsddbmodule.c: In function `newdbbtobject': ./bsddbmodule.c:100: `BTREEINFO' undeclared (first use in this function) ./bsddbmodule.c:100: parse error before `info' ./bsddbmodule.c:105: `info' undeclared (first use in this function) ./bsddbmodule.c:118: warning: assignment makes pointer from integer without a cast ./bsddbmodule.c: In function `newdbrnobject': ./bsddbmodule.c:147: `RECNOINFO' undeclared (first use in this function) ./bsddbmodule.c:147: parse error before `info' ./bsddbmodule.c:152: `info' undeclared (first use in this function) ./bsddbmodule.c:164: warning: assignment makes pointer from integer without a cast ./bsddbmodule.c: In function `bsddb_dealloc': ./bsddbmodule.c:202: too few arguments to function ./bsddbmodule.c: In function `bsddb_length': ./bsddbmodule.c:232: structure has no member named `seq' ./bsddbmodule.c:233: `R_FIRST' undeclared (first use in this function) ./bsddbmodule.c:235: structure has no member named `seq' ./bsddbmodule.c:236: `R_NEXT' undeclared (first use in this function) ./bsddbmodule.c:229: warning: `status' might be used uninitialized in this function ./bsddbmodule.c: In function `bsddb_subscript': ./bsddbmodule.c:265: warning: passing arg 2 of pointer to function from incompatible pointer type ./bsddbmodule.c:265: too few arguments to function ./bsddbmodule.c: In function `bsddb_ass_sub': ./bsddbmodule.c:307: warning: passing arg 2 of pointer to function from incompatible pointer type ./bsddbmodule.c:307: too few arguments to function ./bsddbmodule.c:330: warning: passing arg 2 of pointer to function from incompatible pointer type ./bsddbmodule.c:330: too few arguments to function ./bsddbmodule.c: In function `bsddb_close': ./bsddbmodule.c:357: too few arguments to function ./bsddbmodule.c: In function `bsddb_keys': ./bsddbmodule.c:386: structure has no member named `seq' ./bsddbmodule.c:386: `R_FIRST' undeclared (first use in this function) ./bsddbmodule.c:407: structure has no member named `seq' ./bsddbmodule.c:407: `R_NEXT' undeclared (first use in this function) ./bsddbmodule.c:376: warning: `status' might be used uninitialized in this function ./bsddbmodule.c: In function `bsddb_has_key': ./bsddbmodule.c:440: warning: passing arg 2 of pointer to function from incompatible pointer type ./bsddbmodule.c:440: too few arguments to function ./bsddbmodule.c: In function `bsddb_set_location': ./bsddbmodule.c:466: structure has no member named `seq' ./bsddbmodule.c:466: `R_CURSOR' undeclared (first use in this function) ./bsddbmodule.c:453: warning: `status' might be used uninitialized in this function ./bsddbmodule.c: In function `bsddb_seq': ./bsddbmodule.c:503: structure has no member named `seq' ./bsddbmodule.c:489: warning: `status' might be used uninitialized in this function ./bsddbmodule.c: In function `bsddb_next': ./bsddbmodule.c:531: `R_NEXT' undeclared (first use in this function) ./bsddbmodule.c: In function `bsddb_previous': ./bsddbmodule.c:536: `R_PREV' undeclared (first use in this function) ./bsddbmodule.c: In function `bsddb_first': ./bsddbmodule.c:541: `R_FIRST' undeclared (first use in this function) ./bsddbmodule.c: In function `bsddb_last': ./bsddbmodule.c:546: `R_LAST' undeclared (first use in this function) make[1]: *** [bsddbmodule.o] Error 1 ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-09 07:06 Message: Logged In: YES user_id=34209 I suspect the problem here is that you don't have the appropriate -devel RPM installed. I think you need 'db3-devel', but 'db2-devel', 'db1-devel' or 'db-devel' might work too. Can you confirm that you have none of those installed ? I think what happens is that distutils can't find an include header to include, so it assumes the DB implementation is included in libc, instead. (Changing catagory to distutils on that assumption.) ---------------------------------------------------------------------- Comment By: Ole H. Nielsen (ohnielse) Date: 2001-06-26 14:52 Message: Logged In: YES user_id=27232 loewis wrote: > I have asked you to report things, not to change things. > It is not easy to repeat for me, as I don't have Redhat 7.1. Sorry about the confusion. My report is for RedHat 7.1: 1. Untar the distribution 2.0.1c1 2. ./configure 3. make The errors reported occur. I have changed nothing. I don't know what bsddb is, nor why it's getting compiled. Hopefully, someone knowing Python 2.0.1 and having access to a RedHat 7.1 box could look into the problem. At this point Python building seems broken on RH7.1 :-( ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-26 00:02 Message: Logged In: YES user_id=21627 I have asked you to report things, not to change things. It is not easy to repeat for me, as I don't have Redhat 7.1. ---------------------------------------------------------------------- Comment By: Ole H. Nielsen (ohnielse) Date: 2001-06-25 15:20 Message: Logged In: YES user_id=27232 loewis wrote: > Please report the following things: > - the line in Setup that you activated to enable > compilation of bsddb > - the exact version of the bsddb RPM package that provides > db.h > - whether or not this packages includes a file db_185.h Sorry, I didn't change ANYTHING ! I was trying a vanilla build on RedHat 7.1 ! Should be easy to repeat... Maybe the build scripts make some incorrect choices on RedHat 7.1 ? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-23 13:58 Message: Logged In: YES user_id=21627 Please report the following things: - the line in Setup that you activated to enable compilation of bsddb - the exact version of the bsddb RPM package that provides db.h - whether or not this packages includes a file db_185.h ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=435455&group_id=5470 From noreply@sourceforge.net Mon Jul 9 15:13:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Jul 2001 07:13:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-436525 ] Wrong macro name Message-ID: Bugs item #436525, was opened at 2001-06-26 14:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436525&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Kochanski (gpk) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Wrong macro name Initial Comment: 8.1 Thread State and the Global Interpreter Lock ( http://www.python.org/doc/current/api/threads.html ) refers to macros Py_BEGIN_BLOCK_THREADS and Py_BEGIN_UNBLOCK_THREADS . These do not exist. The correct names are Py_BLOCK_THREADS and Py_UNBLOCK_THREADS. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-09 07:13 Message: Logged In: YES user_id=34209 Fred, is there any reason why I can't change the names mentioned in the TeX files and close this bug ? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 23:18 Message: Logged In: YES user_id=3066 Re-categorized as a documnetation error. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436525&group_id=5470 From noreply@sourceforge.net Mon Jul 9 15:22:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Jul 2001 07:22:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-436525 ] Wrong macro name Message-ID: Bugs item #436525, was opened at 2001-06-26 14:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436525&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Kochanski (gpk) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Wrong macro name Initial Comment: 8.1 Thread State and the Global Interpreter Lock ( http://www.python.org/doc/current/api/threads.html ) refers to macros Py_BEGIN_BLOCK_THREADS and Py_BEGIN_UNBLOCK_THREADS . These do not exist. The correct names are Py_BLOCK_THREADS and Py_UNBLOCK_THREADS. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-09 07:22 Message: Logged In: YES user_id=3066 You can. It's just a little tedious for me to do it since I have a lot of other (unrelated) changes in my working file as well (some of which I'll need to make in release21-maint also), and I don't have any time to juggle files right now. Thanks! ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-09 07:13 Message: Logged In: YES user_id=34209 Fred, is there any reason why I can't change the names mentioned in the TeX files and close this bug ? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 23:18 Message: Logged In: YES user_id=3066 Re-categorized as a documnetation error. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436525&group_id=5470 From noreply@sourceforge.net Mon Jul 9 15:38:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Jul 2001 07:38:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-436525 ] Wrong macro name Message-ID: Bugs item #436525, was opened at 2001-06-26 14:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436525&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Greg Kochanski (gpk) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Wrong macro name Initial Comment: 8.1 Thread State and the Global Interpreter Lock ( http://www.python.org/doc/current/api/threads.html ) refers to macros Py_BEGIN_BLOCK_THREADS and Py_BEGIN_UNBLOCK_THREADS . These do not exist. The correct names are Py_BLOCK_THREADS and Py_UNBLOCK_THREADS. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-09 07:38 Message: Logged In: YES user_id=34209 Alright, fixed in revisions 1.127 and 1.117.2.7 of api.tex. Greg, you don't happen to have a family member called 'Kristine' or 'Krissie', do you ? :-) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-09 07:22 Message: Logged In: YES user_id=3066 You can. It's just a little tedious for me to do it since I have a lot of other (unrelated) changes in my working file as well (some of which I'll need to make in release21-maint also), and I don't have any time to juggle files right now. Thanks! ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-09 07:13 Message: Logged In: YES user_id=34209 Fred, is there any reason why I can't change the names mentioned in the TeX files and close this bug ? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 23:18 Message: Logged In: YES user_id=3066 Re-categorized as a documnetation error. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436525&group_id=5470 From noreply@sourceforge.net Mon Jul 9 15:51:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Jul 2001 07:51:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-435455 ] Python 2.0.1c1 fails to build on RH7.1 Message-ID: Bugs item #435455, was opened at 2001-06-22 06:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=435455&group_id=5470 Category: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Ole H. Nielsen (ohnielse) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.0.1c1 fails to build on RH7.1 Initial Comment: Building Python 2.0.1c1 on a RedHat 7.1 (2.4.2-2 on i586) fails at this point: cd Modules; make OPT="-g -O2 -Wall -Wstrict-prototypes -fPIC" VERSION="2.0" \ prefix="/usr/local" exec_prefix="/usr/local" \ sharedmods make[1]: Entering directory `/scratch/ohnielse/Python-2.0.1/Modules' gcc -fpic -g -O2 -Wall -Wstrict-prototypes -fPIC -I./../Include -I.. -DHAVE_CONFIG_H -c ./bsddbmodule.c ./bsddbmodule.c: In function `newdbhashobject': ./bsddbmodule.c:55: `HASHINFO' undeclared (first use in this function) ./bsddbmodule.c:55: (Each undeclared identifier is reported only once ./bsddbmodule.c:55: for each function it appears in.) ./bsddbmodule.c:55: parse error before `info' ./bsddbmodule.c:60: `info' undeclared (first use in this function) ./bsddbmodule.c:71: warning: implicit declaration of function `dbopen' ./bsddbmodule.c:71: warning: assignment makes pointer from integer without a cast ./bsddbmodule.c: In function `newdbbtobject': ./bsddbmodule.c:100: `BTREEINFO' undeclared (first use in this function) ./bsddbmodule.c:100: parse error before `info' ./bsddbmodule.c:105: `info' undeclared (first use in this function) ./bsddbmodule.c:118: warning: assignment makes pointer from integer without a cast ./bsddbmodule.c: In function `newdbrnobject': ./bsddbmodule.c:147: `RECNOINFO' undeclared (first use in this function) ./bsddbmodule.c:147: parse error before `info' ./bsddbmodule.c:152: `info' undeclared (first use in this function) ./bsddbmodule.c:164: warning: assignment makes pointer from integer without a cast ./bsddbmodule.c: In function `bsddb_dealloc': ./bsddbmodule.c:202: too few arguments to function ./bsddbmodule.c: In function `bsddb_length': ./bsddbmodule.c:232: structure has no member named `seq' ./bsddbmodule.c:233: `R_FIRST' undeclared (first use in this function) ./bsddbmodule.c:235: structure has no member named `seq' ./bsddbmodule.c:236: `R_NEXT' undeclared (first use in this function) ./bsddbmodule.c:229: warning: `status' might be used uninitialized in this function ./bsddbmodule.c: In function `bsddb_subscript': ./bsddbmodule.c:265: warning: passing arg 2 of pointer to function from incompatible pointer type ./bsddbmodule.c:265: too few arguments to function ./bsddbmodule.c: In function `bsddb_ass_sub': ./bsddbmodule.c:307: warning: passing arg 2 of pointer to function from incompatible pointer type ./bsddbmodule.c:307: too few arguments to function ./bsddbmodule.c:330: warning: passing arg 2 of pointer to function from incompatible pointer type ./bsddbmodule.c:330: too few arguments to function ./bsddbmodule.c: In function `bsddb_close': ./bsddbmodule.c:357: too few arguments to function ./bsddbmodule.c: In function `bsddb_keys': ./bsddbmodule.c:386: structure has no member named `seq' ./bsddbmodule.c:386: `R_FIRST' undeclared (first use in this function) ./bsddbmodule.c:407: structure has no member named `seq' ./bsddbmodule.c:407: `R_NEXT' undeclared (first use in this function) ./bsddbmodule.c:376: warning: `status' might be used uninitialized in this function ./bsddbmodule.c: In function `bsddb_has_key': ./bsddbmodule.c:440: warning: passing arg 2 of pointer to function from incompatible pointer type ./bsddbmodule.c:440: too few arguments to function ./bsddbmodule.c: In function `bsddb_set_location': ./bsddbmodule.c:466: structure has no member named `seq' ./bsddbmodule.c:466: `R_CURSOR' undeclared (first use in this function) ./bsddbmodule.c:453: warning: `status' might be used uninitialized in this function ./bsddbmodule.c: In function `bsddb_seq': ./bsddbmodule.c:503: structure has no member named `seq' ./bsddbmodule.c:489: warning: `status' might be used uninitialized in this function ./bsddbmodule.c: In function `bsddb_next': ./bsddbmodule.c:531: `R_NEXT' undeclared (first use in this function) ./bsddbmodule.c: In function `bsddb_previous': ./bsddbmodule.c:536: `R_PREV' undeclared (first use in this function) ./bsddbmodule.c: In function `bsddb_first': ./bsddbmodule.c:541: `R_FIRST' undeclared (first use in this function) ./bsddbmodule.c: In function `bsddb_last': ./bsddbmodule.c:546: `R_LAST' undeclared (first use in this function) make[1]: *** [bsddbmodule.o] Error 1 ---------------------------------------------------------------------- >Comment By: Ole H. Nielsen (ohnielse) Date: 2001-07-09 07:51 Message: Logged In: YES user_id=27232 twouters wrote: > I suspect the problem here is that you don't have the > appropriate -devel RPM installed. I think you need > 'db3-devel', but 'db2-devel', 'db1-devel' or 'db-devel' > might work too. Sorry, no. These RPMs seem to be installed by default on RedHat 7.1: # rpm -qa | grep devel | grep db db1-devel-1.85-5 db2-devel-2.4.14-5 gdbm-devel-1.8.0-5 db3-devel-3.1.17-7 It would be nice if a Python developer could gain access to a RedHat 7.1 machine to sort this problem out :-) ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-09 07:06 Message: Logged In: YES user_id=34209 I suspect the problem here is that you don't have the appropriate -devel RPM installed. I think you need 'db3-devel', but 'db2-devel', 'db1-devel' or 'db-devel' might work too. Can you confirm that you have none of those installed ? I think what happens is that distutils can't find an include header to include, so it assumes the DB implementation is included in libc, instead. (Changing catagory to distutils on that assumption.) ---------------------------------------------------------------------- Comment By: Ole H. Nielsen (ohnielse) Date: 2001-06-26 14:52 Message: Logged In: YES user_id=27232 loewis wrote: > I have asked you to report things, not to change things. > It is not easy to repeat for me, as I don't have Redhat 7.1. Sorry about the confusion. My report is for RedHat 7.1: 1. Untar the distribution 2.0.1c1 2. ./configure 3. make The errors reported occur. I have changed nothing. I don't know what bsddb is, nor why it's getting compiled. Hopefully, someone knowing Python 2.0.1 and having access to a RedHat 7.1 box could look into the problem. At this point Python building seems broken on RH7.1 :-( ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-26 00:02 Message: Logged In: YES user_id=21627 I have asked you to report things, not to change things. It is not easy to repeat for me, as I don't have Redhat 7.1. ---------------------------------------------------------------------- Comment By: Ole H. Nielsen (ohnielse) Date: 2001-06-25 15:20 Message: Logged In: YES user_id=27232 loewis wrote: > Please report the following things: > - the line in Setup that you activated to enable > compilation of bsddb > - the exact version of the bsddb RPM package that provides > db.h > - whether or not this packages includes a file db_185.h Sorry, I didn't change ANYTHING ! I was trying a vanilla build on RedHat 7.1 ! Should be easy to repeat... Maybe the build scripts make some incorrect choices on RedHat 7.1 ? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-23 13:58 Message: Logged In: YES user_id=21627 Please report the following things: - the line in Setup that you activated to enable compilation of bsddb - the exact version of the bsddb RPM package that provides db.h - whether or not this packages includes a file db_185.h ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=435455&group_id=5470 From noreply@sourceforge.net Mon Jul 9 15:55:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Jul 2001 07:55:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-426960 ] fork problem with Python-2.1 Message-ID: Bugs item #426960, was opened at 2001-05-24 09:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426960&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None >Priority: 2 Submitted By: Armin Steinhoff (arminsteinhoff) Assigned to: Nobody/Anonymous (nobody) Summary: fork problem with Python-2.1 Initial Comment: I have a strange problem with Python2.1 running QNX6. The test script test_fork1.py returns with following result: # python -t test_fork1.py /* sys.path include in script ... */ ['', '/usr/local/lib/python2.1', '/usr/local/lib/python2.1/Lib/lib-tk', '/usr/local/lib/python2.1/lib/python2.1', '/usr/local/ lib/python2.1/lib/python2.1/plat-qnx6', '/usr/local/lib/python2.1/lib/python2.1/lib-tk', '/usr/local/lib/python2.1/lib/python2 .1/lib-dynload'] Traceback (most recent call last): File "test_fork1.py", line 76, in ? main() File "test_fork1.py", line 55, in main cpid = os.fork() OSError: [Errno 89] Function not implemented ---------------------------------------------------------------------- That's very strange ... because it works in the interactive mode =:-( ---------------------------------------------------------------------- # python Python 2.1 (#16, May 11 2001, 18:37:57) [GCC 2.95.2 19991024 (release)] on qnx6 Type "copyright", "credits" or "license" for more information. >>> import sys, os >>>sys.path ['', '/usr/local/lib/python2.1', '/usr/local/lib/python2.1/Lib/lib-tk', '/usr/local/lib/python2.1/lib/python2.1', '/usr/local/lib/python2.1/lib/python2.1/plat-qnx6', '/usr/local/lib/python2.1/lib/python2.1/lib-tk', '/usr/local/lib/python2.1/lib/python2 .1/lib-dynload'] >>> >>> os.fork >>> os.fork() 6512990 Any ideas where to look? Armin ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-09 07:55 Message: Logged In: YES user_id=34209 I suspect Jeremy is right, and this bug is because of the mixing of threads and fork(). You could test that by doing what test_fork1 also does: starting a few threads, and then calling fork(). I'm fairly certain you'll end up getting the same error, and that it'll be documented somewhere in your system documentation. ---------------------------------------------------------------------- Comment By: Armin Steinhoff (arminsteinhoff) Date: 2001-05-30 01:06 Message: Logged In: YES user_id=64602 Hello Jeremy, here are the reponses to os.name and import test.test_fork1: # python Python 2.1 (#16, May 11 2001, 18:37:57) [GCC 2.95.2 19991024 (release)] on qnx6 Type "copyright", "credits" or "license" for more information. >>> import os >>> os.name 'posix' >>> import test.test_fork1 ['', '/root/Python-2.1/Lib', '/root/Python-2.1/Lib/Lib/lib-tk', '/root/Python-2.1/Lib/lib/python2.1', '/root/Python-2.1/Lib/lib/python2.1/plat-qnx6', '/root/Python-2.1/Lib/lib/python2.1/lib-tk', '/root/Python-2.1/Lib/lib/python2.1/lib-dynload'] Traceback (most recent call last): File "", line 1, in ? File "/root/Python-2.1/Lib/test/test_fork1.py", line 76, in ? main() File "/root/Python-2.1/Lib/test/test_fork1.py", line 55, in main cpid = os.fork() OSError: [Errno 89] Function not implemented >>> But 'fork' is of course implemented ... Armin ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-05-29 14:55 Message: Logged In: YES user_id=31392 test_fork1 tests the behavior of threads across a fork (why this is important is not entirely clear to me). Perhaps the problem you see is that fork() behaves differently in the presence of threads. Did you try this? >>> import test.test_fork1 Is os.name == "posix" on your system? Or does fork() come from somewhere other than the posix module? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426960&group_id=5470 From noreply@sourceforge.net Mon Jul 9 16:27:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Jul 2001 08:27:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-420343 ] SystemError from tuple() builtin Message-ID: Bugs item #420343, was opened at 2001-04-30 19:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420343&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed Resolution: None Priority: 6 Submitted By: Greg Chapman (glchapman) Assigned to: Moshe Zadka (moshez) Summary: SystemError from tuple() builtin Initial Comment: The following produces a SystemError under Python 2.1: >>> class Test: ... def __init__(self): ... self.list = [1] ... def __len__(self): ... return 0 ... def __getitem__(self, index): ... return self.list[index] ... >>> t = Test() >>> tuple(t) Traceback (most recent call last): File "", line 1, in ? SystemError: C:\USERS\greg\PROG\CPP\PYTHON\Python-2.1 \Objects\tupleobject.c:506: bad argument to internal function The problem is the call made by PySequence_Tuple to _PyTuple_Resize. The above code results in an attempt to resize the empty tuple, the ref count of which is greater than 1. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-09 08:27 Message: Logged In: YES user_id=34209 I guess this didn't make it to 2.0.1 :) Closing. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-05-28 06:20 Message: Logged In: YES user_id=34209 (Eh... I should have said: revisions 2.50 and 2.48.4.1 of Objects/tupleobject.c) ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-05-28 06:18 Message: Logged In: YES user_id=34209 There, fixed for 2.1.1 and 2.2. (revisions 2.50 and 2.48.4.1) Moshe'll have to decide whether he wants the fix for 2.0.1 (there is no big reason not to, but I don't know where he is with 2.0.1, so I don't want to check it in without his okay.) Bug reassigned to Moshe for that purpose. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-05-28 04:34 Message: Logged In: YES user_id=34209 Hey, howlong has this bug been sitting here ?? Must be something wrong with SF's bug mail stuff, because even though this bug is assigned to me, I haven't seen it before :P Anyway, fixing this, both for 2.2 and 2.1.1. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-05-07 22:01 Message: Logged In: YES user_id=31435 Greg, list(f.xreadlines()) happens to work already under current CVS Python. But note for the future that attaching a feature request to an unrelated bug report is a low- probability way to get anyone to notice ... ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2001-04-30 19:41 Message: Logged In: YES user_id=86307 Apropos this report and the recent python-dev thread "Iterators, map, xreadlines and docs": >>> f = open(r"c:\autoexec.bat") >>> l = list(f.xreadlines()) Traceback (most recent call last): File "", line 1, in ? TypeError: len() of unsized object Admittedly, using xreadlines like this is silly, but it probably ought to work. Both PySequence_Tuple and PySequence_List require len() (PySequence_Size) to succeed, even though they then pretty much ignore the returned length. Perhaps they should be changed to be consistent with the changes in map. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420343&group_id=5470 From noreply@sourceforge.net Mon Jul 9 16:48:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Jul 2001 08:48:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-438786 ] CVS 2.1.1c1 broken on osf1V4 Message-ID: Bugs item #438786, was opened at 2001-07-05 07:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Nobody/Anonymous (nobody) Summary: CVS 2.1.1c1 broken on osf1V4 Initial Comment: As of right now, the CVS branch for the 2.1 bugfix release cannot import the math module on my Digital Unix platform. ImportError: Unresolved symbol in /tmp_mnt/home/gball/usr/src/python/dist/src/build/lib.osf1-V4.0-alpha-2.1/math.so: __eprintf uname is OSF1 surya V4.0 878 alpha ---------------------------------------------------------------------- >Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-09 08:48 Message: Logged In: YES user_id=11365 The problem goes away if I clear $CC instead of having it set to gcc. There's a similar problem on Solaris reported recently. I think the configure script should try to spot this sort of thing, but I suppose that's an Autoconf feature request, not a python bug... Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-08 14:06 Message: Logged In: YES user_id=21627 This sounds like a bug in your compiler installation. __eprintf is typically defined in libgcc.a; make sure you use a consistent compiler capable of building binaries for your system throughout the build process. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 From noreply@sourceforge.net Mon Jul 9 20:02:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Jul 2001 12:02:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-439798 ] Nested scopes core dump Message-ID: Bugs item #439798, was opened at 2001-07-09 12:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439798&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Evan Simpson (evansimpson) Assigned to: Nobody/Anonymous (nobody) Summary: Nested scopes core dump Initial Comment: For an interesting error, followed by a core dump: from __future__ import nested_scopes def f(x): class C: def m(self): return x x The bug occurs when the same variable name appears in both the class scope and the method scope. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439798&group_id=5470 From noreply@sourceforge.net Mon Jul 9 21:19:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Jul 2001 13:19:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-439823 ] poll docs should mention timeout unit Message-ID: Bugs item #439823, was opened at 2001-07-09 13:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439823&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: poll docs should mention timeout unit Initial Comment: the documentation about polling objects does not seem to mention what unit the timeout is specified in. it is especially important because it is in milliseconds whereas select.select and time.time use seconds. maybe it should be in bold. -- erno@iki.fi ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439823&group_id=5470 From noreply@sourceforge.net Tue Jul 10 09:30:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 01:30:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-435455 ] Python 2.0.1c1 fails to build on RH7.1 Message-ID: Bugs item #435455, was opened at 2001-06-22 06:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=435455&group_id=5470 Category: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Ole H. Nielsen (ohnielse) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.0.1c1 fails to build on RH7.1 Initial Comment: Building Python 2.0.1c1 on a RedHat 7.1 (2.4.2-2 on i586) fails at this point: cd Modules; make OPT="-g -O2 -Wall -Wstrict-prototypes -fPIC" VERSION="2.0" \ prefix="/usr/local" exec_prefix="/usr/local" \ sharedmods make[1]: Entering directory `/scratch/ohnielse/Python-2.0.1/Modules' gcc -fpic -g -O2 -Wall -Wstrict-prototypes -fPIC -I./../Include -I.. -DHAVE_CONFIG_H -c ./bsddbmodule.c ./bsddbmodule.c: In function `newdbhashobject': ./bsddbmodule.c:55: `HASHINFO' undeclared (first use in this function) ./bsddbmodule.c:55: (Each undeclared identifier is reported only once ./bsddbmodule.c:55: for each function it appears in.) ./bsddbmodule.c:55: parse error before `info' ./bsddbmodule.c:60: `info' undeclared (first use in this function) ./bsddbmodule.c:71: warning: implicit declaration of function `dbopen' ./bsddbmodule.c:71: warning: assignment makes pointer from integer without a cast ./bsddbmodule.c: In function `newdbbtobject': ./bsddbmodule.c:100: `BTREEINFO' undeclared (first use in this function) ./bsddbmodule.c:100: parse error before `info' ./bsddbmodule.c:105: `info' undeclared (first use in this function) ./bsddbmodule.c:118: warning: assignment makes pointer from integer without a cast ./bsddbmodule.c: In function `newdbrnobject': ./bsddbmodule.c:147: `RECNOINFO' undeclared (first use in this function) ./bsddbmodule.c:147: parse error before `info' ./bsddbmodule.c:152: `info' undeclared (first use in this function) ./bsddbmodule.c:164: warning: assignment makes pointer from integer without a cast ./bsddbmodule.c: In function `bsddb_dealloc': ./bsddbmodule.c:202: too few arguments to function ./bsddbmodule.c: In function `bsddb_length': ./bsddbmodule.c:232: structure has no member named `seq' ./bsddbmodule.c:233: `R_FIRST' undeclared (first use in this function) ./bsddbmodule.c:235: structure has no member named `seq' ./bsddbmodule.c:236: `R_NEXT' undeclared (first use in this function) ./bsddbmodule.c:229: warning: `status' might be used uninitialized in this function ./bsddbmodule.c: In function `bsddb_subscript': ./bsddbmodule.c:265: warning: passing arg 2 of pointer to function from incompatible pointer type ./bsddbmodule.c:265: too few arguments to function ./bsddbmodule.c: In function `bsddb_ass_sub': ./bsddbmodule.c:307: warning: passing arg 2 of pointer to function from incompatible pointer type ./bsddbmodule.c:307: too few arguments to function ./bsddbmodule.c:330: warning: passing arg 2 of pointer to function from incompatible pointer type ./bsddbmodule.c:330: too few arguments to function ./bsddbmodule.c: In function `bsddb_close': ./bsddbmodule.c:357: too few arguments to function ./bsddbmodule.c: In function `bsddb_keys': ./bsddbmodule.c:386: structure has no member named `seq' ./bsddbmodule.c:386: `R_FIRST' undeclared (first use in this function) ./bsddbmodule.c:407: structure has no member named `seq' ./bsddbmodule.c:407: `R_NEXT' undeclared (first use in this function) ./bsddbmodule.c:376: warning: `status' might be used uninitialized in this function ./bsddbmodule.c: In function `bsddb_has_key': ./bsddbmodule.c:440: warning: passing arg 2 of pointer to function from incompatible pointer type ./bsddbmodule.c:440: too few arguments to function ./bsddbmodule.c: In function `bsddb_set_location': ./bsddbmodule.c:466: structure has no member named `seq' ./bsddbmodule.c:466: `R_CURSOR' undeclared (first use in this function) ./bsddbmodule.c:453: warning: `status' might be used uninitialized in this function ./bsddbmodule.c: In function `bsddb_seq': ./bsddbmodule.c:503: structure has no member named `seq' ./bsddbmodule.c:489: warning: `status' might be used uninitialized in this function ./bsddbmodule.c: In function `bsddb_next': ./bsddbmodule.c:531: `R_NEXT' undeclared (first use in this function) ./bsddbmodule.c: In function `bsddb_previous': ./bsddbmodule.c:536: `R_PREV' undeclared (first use in this function) ./bsddbmodule.c: In function `bsddb_first': ./bsddbmodule.c:541: `R_FIRST' undeclared (first use in this function) ./bsddbmodule.c: In function `bsddb_last': ./bsddbmodule.c:546: `R_LAST' undeclared (first use in this function) make[1]: *** [bsddbmodule.o] Error 1 ---------------------------------------------------------------------- >Comment By: Sjoerd Mullender (sjoerd) Date: 2001-07-10 01:30 Message: Logged In: YES user_id=43607 I have no trouble building the current CVS version on RedHat 7.1. However, when I try the gcc command given in the error message, I get much the same errors. The deciding difference was: setup.py (part of the standard current build process) adds -DHAVE_DB_185_H=1 to the compiler command line. ---------------------------------------------------------------------- Comment By: Ole H. Nielsen (ohnielse) Date: 2001-07-09 07:51 Message: Logged In: YES user_id=27232 twouters wrote: > I suspect the problem here is that you don't have the > appropriate -devel RPM installed. I think you need > 'db3-devel', but 'db2-devel', 'db1-devel' or 'db-devel' > might work too. Sorry, no. These RPMs seem to be installed by default on RedHat 7.1: # rpm -qa | grep devel | grep db db1-devel-1.85-5 db2-devel-2.4.14-5 gdbm-devel-1.8.0-5 db3-devel-3.1.17-7 It would be nice if a Python developer could gain access to a RedHat 7.1 machine to sort this problem out :-) ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-09 07:06 Message: Logged In: YES user_id=34209 I suspect the problem here is that you don't have the appropriate -devel RPM installed. I think you need 'db3-devel', but 'db2-devel', 'db1-devel' or 'db-devel' might work too. Can you confirm that you have none of those installed ? I think what happens is that distutils can't find an include header to include, so it assumes the DB implementation is included in libc, instead. (Changing catagory to distutils on that assumption.) ---------------------------------------------------------------------- Comment By: Ole H. Nielsen (ohnielse) Date: 2001-06-26 14:52 Message: Logged In: YES user_id=27232 loewis wrote: > I have asked you to report things, not to change things. > It is not easy to repeat for me, as I don't have Redhat 7.1. Sorry about the confusion. My report is for RedHat 7.1: 1. Untar the distribution 2.0.1c1 2. ./configure 3. make The errors reported occur. I have changed nothing. I don't know what bsddb is, nor why it's getting compiled. Hopefully, someone knowing Python 2.0.1 and having access to a RedHat 7.1 box could look into the problem. At this point Python building seems broken on RH7.1 :-( ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-26 00:02 Message: Logged In: YES user_id=21627 I have asked you to report things, not to change things. It is not easy to repeat for me, as I don't have Redhat 7.1. ---------------------------------------------------------------------- Comment By: Ole H. Nielsen (ohnielse) Date: 2001-06-25 15:20 Message: Logged In: YES user_id=27232 loewis wrote: > Please report the following things: > - the line in Setup that you activated to enable > compilation of bsddb > - the exact version of the bsddb RPM package that provides > db.h > - whether or not this packages includes a file db_185.h Sorry, I didn't change ANYTHING ! I was trying a vanilla build on RedHat 7.1 ! Should be easy to repeat... Maybe the build scripts make some incorrect choices on RedHat 7.1 ? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-23 13:58 Message: Logged In: YES user_id=21627 Please report the following things: - the line in Setup that you activated to enable compilation of bsddb - the exact version of the bsddb RPM package that provides db.h - whether or not this packages includes a file db_185.h ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=435455&group_id=5470 From noreply@sourceforge.net Tue Jul 10 10:21:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 02:21:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-439990 ] os.nice() return 0 under Linux Message-ID: Bugs item #439990, was opened at 2001-07-10 02:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439990&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: os.nice() return 0 under Linux Initial Comment: os.nice() return 0 under Linux while docs say it should return ''niceness'' value ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439990&group_id=5470 From noreply@sourceforge.net Tue Jul 10 10:24:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 02:24:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-439992 ] [win32] KeyboardInterrupt Not Caught Message-ID: Bugs item #439992, was opened at 2001-07-10 02:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439992&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: [win32] KeyboardInterrupt Not Caught Initial Comment: The following program, run under unix (FreeBSD 4.3) and Windows 2000 SP2 with the command line: python test.py In both cases, running python 2.1. The program works as expected under unix and IDLE on Windows 2000, but it does *not* catch the interrupt in the command line version of Win32 python... i.e., The traceback message appears rather than my "Leaving Dodge..." message. while 1: try: x = raw_input().upper() print x except KeyboardInterrupt: print "Leaving Dodge...\n" break ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439992&group_id=5470 From noreply@sourceforge.net Tue Jul 10 10:26:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 02:26:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-439798 ] Nested scopes core dump Message-ID: Bugs item #439798, was opened at 2001-07-09 12:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439798&group_id=5470 Category: Parser/Compiler Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Evan Simpson (evansimpson) Assigned to: Nobody/Anonymous (nobody) Summary: Nested scopes core dump Initial Comment: For an interesting error, followed by a core dump: from __future__ import nested_scopes def f(x): class C: def m(self): return x x The bug occurs when the same variable name appears in both the class scope and the method scope. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-10 02:26 Message: Logged In: YES user_id=34209 This has already been fixed by Jeremy shortly after 2.1's release, so 2.2 and 2.1.1 will not contain this bug. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439798&group_id=5470 From noreply@sourceforge.net Tue Jul 10 10:33:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 02:33:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-439993 ] infinite loop in re.match Message-ID: Bugs item #439993, was opened at 2001-07-10 02:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439993&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: infinite loop in re.match Initial Comment: Python 2.0.1 "re.match" enters infinite loop for a regular expression that was carefully designed not to lead to loops (an easy expression). See attached file. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439993&group_id=5470 From noreply@sourceforge.net Tue Jul 10 10:36:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 02:36:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-439990 ] os.nice() return 0 under Linux Message-ID: Bugs item #439990, was opened at 2001-07-10 02:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439990&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Thomas Wouters (twouters) Summary: os.nice() return 0 under Linux Initial Comment: os.nice() return 0 under Linux while docs say it should return ''niceness'' value ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-10 02:36 Message: Logged In: YES user_id=34209 Submitted a fix, SF patch #439995. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439990&group_id=5470 From noreply@sourceforge.net Tue Jul 10 10:44:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 02:44:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-439997 ] infinite loop in re.match Message-ID: Bugs item #439997, was opened at 2001-07-10 02:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439997&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dieter Maurer (dmaurer) Assigned to: Nobody/Anonymous (nobody) Summary: infinite loop in re.match Initial Comment: Python 2.0.1 "re.match" enters infinite loop for a regular expression that was carefully designed not to lead to loops (an easy expression). See attached file. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439997&group_id=5470 From noreply@sourceforge.net Tue Jul 10 12:53:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 04:53:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-440017 ] SystemError when importing packages Message-ID: Bugs item #440017, was opened at 2001-07-10 04:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440017&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Nobody/Anonymous (nobody) Summary: SystemError when importing packages Initial Comment: Python 2.1 (haven't checked older versions) on Windows has a problem with importing packages with a case mismatch in the name, e.g. trying to import the package "encodings" using the name "Encodings" gives you the following error: >>> import Encodings Traceback (most recent call last): File "", line 1, in ? import Encodings SystemError: NULL result without error in call_object >>> It should ideally output: ImportError: No module named Encodings (case-mismatch) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440017&group_id=5470 From noreply@sourceforge.net Tue Jul 10 12:56:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 04:56:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-437879 ] SocketServer.py related problems Message-ID: Bugs item #437879, was opened at 2001-07-02 05:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437879&group_id=5470 Category: Python Library >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Guido van Rossum (gvanrossum) Summary: SocketServer.py related problems Initial Comment: I tried several third-party proxy servers for Python (munchy,webdebug) go get working with Python 2.1 under Linux i386. But all fail with similar problems: Under 2.1: andreas@yetix:/home/andreas/src/munchy-0.7: python2.1 munchy.py 8006 Starting proxy on port 8006 Exception in thread Thread-1: Traceback (most recent call last): File "/opt/python-2.1/lib/python2.1/threading.py", line 378, in __bootstrap self.run() File "/opt/python-2.1/lib/python2.1/threading.py", line 366, in run apply(self.__target, self.__args, self.__kwargs) File "/opt/python-2.1/lib/python2.1/SocketServer.py", line 246, in finish_request self.RequestHandlerClass(request, client_address, self) File "/opt/python-2.1/lib/python2.1/SocketServer.py", line 494, in __init__ self.setup() File "/opt/python-2.1/lib/python2.1/SocketServer.py", line 537, in setup self.rfile = self.connection.makefile('rb', self.rbufsize) error: (9, 'Bad file descriptor') I could not track down the problem :-( Andreas ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 04:56 Message: Logged In: YES user_id=6380 Try the version of SocketServer I just checked into the CVS tree. I'm quite sure I fixed this now. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2001-07-06 09:32 Message: Logged In: YES user_id=11084 I could not run the webDebug program with 2.0 because it raised a regular expression related inside the application code so I did not waste more time on it. It was some kind of DC related job - I needed some tools to monitor WebDAV traffic between a client and Zope. I get around the problem by using ethereal for snooping the traffice. Andreas ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-06 09:21 Message: Logged In: YES user_id=6380 Andreas, do these work when used with Python 2.0? Then it could be related to SF bug 417845. Try the workaround listed there and let me know the result. (Is this a DC job? Then I can raise the priority.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437879&group_id=5470 From noreply@sourceforge.net Tue Jul 10 12:57:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 04:57:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-424951 ] ThreadingTCPServer file handle errors. Message-ID: Bugs item #424951, was opened at 2001-05-17 12:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424951&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Largent (jlargent) Assigned to: Guido van Rossum (gvanrossum) Summary: ThreadingTCPServer file handle errors. Initial Comment: When running a server using ThreadingTCPServer if the server sit for several minutes between requests the first request it receives will error with a bad file handle error. Python 2.1 (#1, Apr 20 2001, 15:04:11) [GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2 #!/usr/bin/python2 from SocketServer import ThreadingTCPServer, BaseRequestHandler class myHandler (BaseRequestHandler): def handle(self): while 1: data = self.request.recv(1024) if not data: break self.request.send('%s' % (data)) self.request.close if __name__ == '__main__': addr = ('localhost', 50000) s = ThreadingTCPServer(addr, myHandler) s.serve_forever() Start this server wait several min then using the echo-client.py from oreilly Programming Python to send it data. Traceback (most recent call last): File "/var/tmp/python2-2.1-root/usr/lib/python2.1/threading.py", line 378, in __bootstrap self.run() File "/var/tmp/python2-2.1-root/usr/lib/python2.1/threading.py", line 366, in run apply(self.__target, self.__args, self.__kwargs) File "/var/tmp/python2-2.1-root/usr/lib/python2.1/SocketServer.py", line 246, in finish_request self.RequestHandlerClass(request, client_address, self) File "/var/tmp/python2-2.1-root/usr/lib/python2.1/SocketServer.py", line 495, in __init__ self.handle() File "./server.py", line 10, in handle data = self.request.recv(1024) error: (9, 'Bad file descriptor') Any requests sent right after this will complete properly. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 04:57 Message: Logged In: YES user_id=6380 I've eproduced this and have now produced a fix. Check out the latest SocketServer.py from the CVS! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424951&group_id=5470 From noreply@sourceforge.net Tue Jul 10 12:58:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 04:58:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-419873 ] ThreadingTCPServer invalidating sockets Message-ID: Bugs item #419873, was opened at 2001-04-28 16:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419873&group_id=5470 Category: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: ThreadingTCPServer invalidating sockets Initial Comment: running this: import SocketServer class TestServer(SocketServer.ThreadingTCPServer): def __init__(self, server_address, RequestHandlerClass): SocketServer.ThreadingTCPServer.__init__(self, server_address, RequestHandlerClass) self.quit = 0 def process_request(self, request, client_address): print 'socket in process_request = %s' % request print 'id(socket) in process_request = %d' % id(request) SocketServer.ThreadingTCPServer.process_request(self, request, client_address) def finish_request(self, request, client_address): print 'socket in finish_request = %s' % request print 'id(socket) in finish_request = %d' % id(request) self.RequestHandlerClass(request, client_address, self) def get_request(self): conn, addr = self.socket.accept() print 'socket in get_request = %s' % conn print 'id(socket) in get_request = %d' % id(conn) return conn,addr if __name__ == '__main__': s = TestServer(('',9950), SocketServer.BaseRequestHandler) s.handle_request() s.server_close() results in the following output (when connected to remotely): socket in get_request = id(socket) in get_request = 135335216 socket in process_request = id(socket) in process_request = 135335216 socket in finish_request = id(socket) in finish_request = 135335216 between in the thread-creation in process_request, the socket's fd changes to -1. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 04:58 Message: Logged In: YES user_id=6380 I've produced a proper fix for this. Check out SocketServer.py from the CVS. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-05-04 14:10 Message: Logged In: NO Thanks, that solves the problem. ---------------------------------------------------------------------- Comment By: Jon Riehl (jriehl) Date: 2001-05-01 14:25 Message: Logged In: YES user_id=22448 See comments for bug #417845. BaseServer.handle_request() potentially (more like consistently) calls close_request() before the thread spun in process_request() is able to complete. A work around is shown in bug #417845 (overload close_request() to do nothing instead of closing the socket.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419873&group_id=5470 From noreply@sourceforge.net Tue Jul 10 12:59:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 04:59:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn Message-ID: Bugs item #417845, was opened at 2001-04-21 08:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: Python 2.1: SocketServer.ThreadingMixIn Initial Comment: SocketServer.ThreadingMixIn does not work properly since it tries to close the socket of a request two times. Workaround for using SocketServer.ThreadingMixIn under Python 2.1: class MyThreadingHTTPServer( SocketServer.ThreadingMixIn, MyHTTPServer ): def close_request(self, request): pass ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 04:59 Message: Logged In: YES user_id=6380 I've developed a proper fix for this, I hope. Check out the latest SocketServer.py from the CVS tree. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-07-02 09:05 Message: Logged In: YES user_id=198402 There is still a problem with your solution, Mr glchapman: you make a copy to ensure that the server won't close the copy of the socket that is used in the child thread. Right. But WHO will close this very copy then? The thread still has to close it if one wants to be "clean". So as long as the child thread must close its copy in the threading case, why not make it a thumb rule? Why should we bother about closing anything in the main thread? I still think the solution that I provide is best: make the request handler always responsible for closing the socket from which the request comes. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2001-06-29 08:49 Message: Logged In: YES user_id=86307 Since the request socket object is only a lightweight wrapper around the real socket, why not simply pass request.dup() to the new thread? Then the server's call to close_request affects only its copy of request, not the copy being used in the thread. For example, the following change to ThreadingMixIn fixed this bug for me in a (very simple) test program: def process_request(self, request, client_address): """Start a new thread to process the request.""" import threading t = threading.Thread(target = self.finish_request, args = (request.dup(), client_address)) t.start() ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-28 05:20 Message: Logged In: YES user_id=198402 I have now started a project here concerning a SOCKS proxy written in python (PySocks). It is aimed mostly at people who use a windows box to share their internet connection and uses the threading server from the SocketServer module. So it becomes VERY important to me to know of what will be done about this bug, in the next release/patch of Python library. Could Mr Guido Vanrossum tell us about it? As for now I am forced to provide my patched version of SocketServer.py with my releases, what is not quite satisfactory. SocketServer is provided in the python distribution, so I'd rather tell "there is a patch for python..." Well... In fact I forgot to put it in my first release, but I'll correct this this evening :) ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-20 12:06 Message: Logged In: YES user_id=198402 Well I was wrong. We do need a "try" block to ensure the request is always correctly closed: def finish_request(self, request, client_address): """Finish one request by instantiating RequestHandlerClass.""" try: self.RequestHandlerClass(request, client_address, self) finally: self.close_request(request) This works better. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-13 09:09 Message: Logged In: YES user_id=198402 I forgot to tell: I can not test if it does not break the forking server. I only have a windows platform available for now, and forking doesn't work in the python/win32 environment for now as far as I know. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-13 08:51 Message: Logged In: YES user_id=198402 What I propose can be applied without any compatibility issue. I have tried something that seems to work, at least under windows (but it does need to be more fully tested though). Only 2 small modifications are required: -1- In BaseServer, modification of the last line of handle_request: 
    def handle_request(self):
        """Handle one request, possibly blocking."""
        #import time
        try:
            request, client_address = self.get_request()
        except socket.error:
            return
        if self.verify_request(request, client_address):
            try:
                print 'handle 1'
                self.process_request(request, 
client_address)
                print 'handle 2'
            except:
                self.handle_error(request, client_address)
                self.close_request(request)
Note that only the indentation of the last has been modified so that the close_request is executed only if an exception occur. Still we need to close the request after it had been processed, so here comes the second modification: -2- Still in BaseServer: 
    def finish_request(self, request, client_address):
        """Finish one request by instantiating 
RequestHandlerClass."""
        self.RequestHandlerClass(request, client_address, 
self)
        self.close_request(request)
There is already a try/except block in handle_request, so I thought it was not mandatory here to ensure the request was always closed. Oh... I don't know how <PRE> tags are supported by the bugtracking system of sourceforge, so the samples I give may not appear as I want. This is quite a problem with python :/ ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-12 15:46 Message: Logged In: YES user_id=80200 hi there mr xlagraula, yes, it would be a lot simpler... _if_ it wasn't for the fact that this code is likely to already be quite extensively used. a possible 'upgrade' path could be done by providing a... RequestHandler2 class, or some-such. it would be neater to do this, or similar: for t in self.thread_list: t.join(timeout=0.1) which would join all threads, or you do if stopped(), close_request. i looked into threads a bit more: join has a timeout, and there is a stopped-detection function. easy :) ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-12 14:18 Message: Logged In: YES user_id=198402 Another solution could be to modify the behaviour of the server so that it would be the responsibility of the "child" thread/process to close the socket (except for the forking/threading error cases). Wouldn't it be simplier than child process tracking and thread tracking? ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-04 04:17 Message: Logged In: YES user_id=80200 okay. the forkingmixin code does a fork, records how many children there are, and waits for one of them to exit, before proceeding - in particular, before proceeding to close the request, etc. ... so why is not something similar done in ThreadingMixIn? this kinda- tells me that thread-tracking is really needed, in a similar way to that in forkingmixin. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2001-05-03 16:26 Message: Logged In: YES user_id=413 Just a note of another casualty of this bug: I had to add the mentioned dummy close_request method hack to our own ThreadingMixIn class in mojo nation (in the sourceforge mojonation project's evil module, see the common/MojoNationHTTPServer.py file). Without it, python 2.1 would always raise an exception in the request handler as soon as it tried to call self.connection.makefile() because self.connection had apparently already been closed! (its fd was always -1) ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-02 01:41 Message: Logged In: YES user_id=80200 hi there mr jrielh, thank you very much for the details. what i am having a little difficulty with is, what's the difference between this and python 2.0 SocketServer.py? more specifically, i'm looking at python 2.0 SocketServer.py and, whilst i'm not a Threads expert, i see a t.start() but no t.join(). i've been looking at the Queue example code in the test method of threads.py, and start() is called on every thread, followed by join() on every thread. join waits for the thread to finish, yes? so... if that's the case, then python 2.0 SocketServer.py should suffer from exactly the same behaviour, yes? unless python behaves ever-so-slightly differently (timing issues?) when you have an extra base class like this, with the consequence that close_request() is more likely to be called before ThreadingMixIn.process_request(). ? ---------------------------------------------------------------------- Comment By: Jon Riehl (jriehl) Date: 2001-05-01 14:20 Message: Logged In: YES user_id=22448 This is related to bug #419873. The problem is not specifically in the ThreadingMixin specifically, but where BaseServer calls close_request() after calling process_request(). In the threading mixin, process_request() spins the thread and returns, causing the request socket to be invalidated while the thread is still running. The fix given above will keep the socket valid while the thread is running, but may cause the socket to not close properly (my threads generally close the socket when they are done anyway.) ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-04-26 05:41 Message: Logged In: YES user_id=80200 follow-up. i took a look at the differences between SocketServer.py in 2.0 and 2.1. there is one small change by guido to the ThreadingMixIn.process_request() function that calls self.server_close() instead of explicitly calling self.socket.close(), where TCPServer.server_close() calls self.socket.close(). if mr anonymous (hi!) has over-ridden server_close() and explicitly closes the *request* socket, then of course the socket will get closed twice. the rest of the code-mods is a straightforward code-shuffle moving code from TCPServer into BaseServer: from examining the diff, i really don't see how bypassing close_request(), as shown above with the Workaround in the original bug-report, will help: that will in fact cause the request _never_ to be closed! the rest of this report is part of an email exchange with guido, quoted here: "the bug-report doesn't state whether python 2.0 worked and 2.1 didn't: it also doesn't give enough info. for all we know, he's calling close_request() himself or request.close() directly somewhere in his code, and hasn't told anybody, which is why he has to over-ride close_request() and tell it to do nothing. or he's closing the socket in the HandlerClass, in finish(), or something. we just don't know. either that, or his HandlerClass creates a socket once and only once, with the result that close_request() closes the one socket, and he's _completely_ stuffed, then :)" ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-04-26 04:11 Message: Logged In: YES user_id=80200 hi there, i'm the person who wrote the BaseServer class. guido contacted me about it: could you please send me or post here a working test example that demonstrates the problem. i assume, but you do not state, that you have tested your MyHTTPServer with python 2.0, please let us know, here, if that is a correct assumption. thanks! luke ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470 From noreply@sourceforge.net Tue Jul 10 13:02:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 05:02:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn Message-ID: Bugs item #417845, was opened at 2001-04-21 08:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: Python 2.1: SocketServer.ThreadingMixIn Initial Comment: SocketServer.ThreadingMixIn does not work properly since it tries to close the socket of a request two times. Workaround for using SocketServer.ThreadingMixIn under Python 2.1: class MyThreadingHTTPServer( SocketServer.ThreadingMixIn, MyHTTPServer ): def close_request(self, request): pass ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 04:59 Message: Logged In: YES user_id=6380 I've developed a proper fix for this, I hope. Check out the latest SocketServer.py from the CVS tree. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-07-02 09:05 Message: Logged In: YES user_id=198402 There is still a problem with your solution, Mr glchapman: you make a copy to ensure that the server won't close the copy of the socket that is used in the child thread. Right. But WHO will close this very copy then? The thread still has to close it if one wants to be "clean". So as long as the child thread must close its copy in the threading case, why not make it a thumb rule? Why should we bother about closing anything in the main thread? I still think the solution that I provide is best: make the request handler always responsible for closing the socket from which the request comes. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2001-06-29 08:49 Message: Logged In: YES user_id=86307 Since the request socket object is only a lightweight wrapper around the real socket, why not simply pass request.dup() to the new thread? Then the server's call to close_request affects only its copy of request, not the copy being used in the thread. For example, the following change to ThreadingMixIn fixed this bug for me in a (very simple) test program: def process_request(self, request, client_address): """Start a new thread to process the request.""" import threading t = threading.Thread(target = self.finish_request, args = (request.dup(), client_address)) t.start() ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-28 05:20 Message: Logged In: YES user_id=198402 I have now started a project here concerning a SOCKS proxy written in python (PySocks). It is aimed mostly at people who use a windows box to share their internet connection and uses the threading server from the SocketServer module. So it becomes VERY important to me to know of what will be done about this bug, in the next release/patch of Python library. Could Mr Guido Vanrossum tell us about it? As for now I am forced to provide my patched version of SocketServer.py with my releases, what is not quite satisfactory. SocketServer is provided in the python distribution, so I'd rather tell "there is a patch for python..." Well... In fact I forgot to put it in my first release, but I'll correct this this evening :) ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-20 12:06 Message: Logged In: YES user_id=198402 Well I was wrong. We do need a "try" block to ensure the request is always correctly closed: def finish_request(self, request, client_address): """Finish one request by instantiating RequestHandlerClass.""" try: self.RequestHandlerClass(request, client_address, self) finally: self.close_request(request) This works better. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-13 09:09 Message: Logged In: YES user_id=198402 I forgot to tell: I can not test if it does not break the forking server. I only have a windows platform available for now, and forking doesn't work in the python/win32 environment for now as far as I know. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-13 08:51 Message: Logged In: YES user_id=198402 What I propose can be applied without any compatibility issue. I have tried something that seems to work, at least under windows (but it does need to be more fully tested though). Only 2 small modifications are required: -1- In BaseServer, modification of the last line of handle_request: 
    def handle_request(self):
        """Handle one request, possibly blocking."""
        #import time
        try:
            request, client_address = self.get_request()
        except socket.error:
            return
        if self.verify_request(request, client_address):
            try:
                print 'handle 1'
                self.process_request(request, 
client_address)
                print 'handle 2'
            except:
                self.handle_error(request, client_address)
                self.close_request(request)
Note that only the indentation of the last has been modified so that the close_request is executed only if an exception occur. Still we need to close the request after it had been processed, so here comes the second modification: -2- Still in BaseServer: 
    def finish_request(self, request, client_address):
        """Finish one request by instantiating 
RequestHandlerClass."""
        self.RequestHandlerClass(request, client_address, 
self)
        self.close_request(request)
There is already a try/except block in handle_request, so I thought it was not mandatory here to ensure the request was always closed. Oh... I don't know how <PRE> tags are supported by the bugtracking system of sourceforge, so the samples I give may not appear as I want. This is quite a problem with python :/ ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-12 15:46 Message: Logged In: YES user_id=80200 hi there mr xlagraula, yes, it would be a lot simpler... _if_ it wasn't for the fact that this code is likely to already be quite extensively used. a possible 'upgrade' path could be done by providing a... RequestHandler2 class, or some-such. it would be neater to do this, or similar: for t in self.thread_list: t.join(timeout=0.1) which would join all threads, or you do if stopped(), close_request. i looked into threads a bit more: join has a timeout, and there is a stopped-detection function. easy :) ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-12 14:18 Message: Logged In: YES user_id=198402 Another solution could be to modify the behaviour of the server so that it would be the responsibility of the "child" thread/process to close the socket (except for the forking/threading error cases). Wouldn't it be simplier than child process tracking and thread tracking? ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-04 04:17 Message: Logged In: YES user_id=80200 okay. the forkingmixin code does a fork, records how many children there are, and waits for one of them to exit, before proceeding - in particular, before proceeding to close the request, etc. ... so why is not something similar done in ThreadingMixIn? this kinda- tells me that thread-tracking is really needed, in a similar way to that in forkingmixin. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2001-05-03 16:26 Message: Logged In: YES user_id=413 Just a note of another casualty of this bug: I had to add the mentioned dummy close_request method hack to our own ThreadingMixIn class in mojo nation (in the sourceforge mojonation project's evil module, see the common/MojoNationHTTPServer.py file). Without it, python 2.1 would always raise an exception in the request handler as soon as it tried to call self.connection.makefile() because self.connection had apparently already been closed! (its fd was always -1) ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-02 01:41 Message: Logged In: YES user_id=80200 hi there mr jrielh, thank you very much for the details. what i am having a little difficulty with is, what's the difference between this and python 2.0 SocketServer.py? more specifically, i'm looking at python 2.0 SocketServer.py and, whilst i'm not a Threads expert, i see a t.start() but no t.join(). i've been looking at the Queue example code in the test method of threads.py, and start() is called on every thread, followed by join() on every thread. join waits for the thread to finish, yes? so... if that's the case, then python 2.0 SocketServer.py should suffer from exactly the same behaviour, yes? unless python behaves ever-so-slightly differently (timing issues?) when you have an extra base class like this, with the consequence that close_request() is more likely to be called before ThreadingMixIn.process_request(). ? ---------------------------------------------------------------------- Comment By: Jon Riehl (jriehl) Date: 2001-05-01 14:20 Message: Logged In: YES user_id=22448 This is related to bug #419873. The problem is not specifically in the ThreadingMixin specifically, but where BaseServer calls close_request() after calling process_request(). In the threading mixin, process_request() spins the thread and returns, causing the request socket to be invalidated while the thread is still running. The fix given above will keep the socket valid while the thread is running, but may cause the socket to not close properly (my threads generally close the socket when they are done anyway.) ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-04-26 05:41 Message: Logged In: YES user_id=80200 follow-up. i took a look at the differences between SocketServer.py in 2.0 and 2.1. there is one small change by guido to the ThreadingMixIn.process_request() function that calls self.server_close() instead of explicitly calling self.socket.close(), where TCPServer.server_close() calls self.socket.close(). if mr anonymous (hi!) has over-ridden server_close() and explicitly closes the *request* socket, then of course the socket will get closed twice. the rest of the code-mods is a straightforward code-shuffle moving code from TCPServer into BaseServer: from examining the diff, i really don't see how bypassing close_request(), as shown above with the Workaround in the original bug-report, will help: that will in fact cause the request _never_ to be closed! the rest of this report is part of an email exchange with guido, quoted here: "the bug-report doesn't state whether python 2.0 worked and 2.1 didn't: it also doesn't give enough info. for all we know, he's calling close_request() himself or request.close() directly somewhere in his code, and hasn't told anybody, which is why he has to over-ride close_request() and tell it to do nothing. or he's closing the socket in the HandlerClass, in finish(), or something. we just don't know. either that, or his HandlerClass creates a socket once and only once, with the result that close_request() closes the one socket, and he's _completely_ stuffed, then :)" ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-04-26 04:11 Message: Logged In: YES user_id=80200 hi there, i'm the person who wrote the BaseServer class. guido contacted me about it: could you please send me or post here a working test example that demonstrates the problem. i assume, but you do not state, that you have tested your MyHTTPServer with python 2.0, please let us know, here, if that is a correct assumption. thanks! luke ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470 From noreply@sourceforge.net Tue Jul 10 13:02:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 05:02:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-437879 ] SocketServer.py related problems Message-ID: Bugs item #437879, was opened at 2001-07-02 05:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437879&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Guido van Rossum (gvanrossum) Summary: SocketServer.py related problems Initial Comment: I tried several third-party proxy servers for Python (munchy,webdebug) go get working with Python 2.1 under Linux i386. But all fail with similar problems: Under 2.1: andreas@yetix:/home/andreas/src/munchy-0.7: python2.1 munchy.py 8006 Starting proxy on port 8006 Exception in thread Thread-1: Traceback (most recent call last): File "/opt/python-2.1/lib/python2.1/threading.py", line 378, in __bootstrap self.run() File "/opt/python-2.1/lib/python2.1/threading.py", line 366, in run apply(self.__target, self.__args, self.__kwargs) File "/opt/python-2.1/lib/python2.1/SocketServer.py", line 246, in finish_request self.RequestHandlerClass(request, client_address, self) File "/opt/python-2.1/lib/python2.1/SocketServer.py", line 494, in __init__ self.setup() File "/opt/python-2.1/lib/python2.1/SocketServer.py", line 537, in setup self.rfile = self.connection.makefile('rb', self.rbufsize) error: (9, 'Bad file descriptor') I could not track down the problem :-( Andreas ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 04:56 Message: Logged In: YES user_id=6380 Try the version of SocketServer I just checked into the CVS tree. I'm quite sure I fixed this now. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2001-07-06 09:32 Message: Logged In: YES user_id=11084 I could not run the webDebug program with 2.0 because it raised a regular expression related inside the application code so I did not waste more time on it. It was some kind of DC related job - I needed some tools to monitor WebDAV traffic between a client and Zope. I get around the problem by using ethereal for snooping the traffice. Andreas ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-06 09:21 Message: Logged In: YES user_id=6380 Andreas, do these work when used with Python 2.0? Then it could be related to SF bug 417845. Try the workaround listed there and let me know the result. (Is this a DC job? Then I can raise the priority.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437879&group_id=5470 From noreply@sourceforge.net Tue Jul 10 13:02:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 05:02:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-424951 ] ThreadingTCPServer file handle errors. Message-ID: Bugs item #424951, was opened at 2001-05-17 12:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424951&group_id=5470 Category: Extension Modules Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeff Largent (jlargent) Assigned to: Guido van Rossum (gvanrossum) Summary: ThreadingTCPServer file handle errors. Initial Comment: When running a server using ThreadingTCPServer if the server sit for several minutes between requests the first request it receives will error with a bad file handle error. Python 2.1 (#1, Apr 20 2001, 15:04:11) [GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2 #!/usr/bin/python2 from SocketServer import ThreadingTCPServer, BaseRequestHandler class myHandler (BaseRequestHandler): def handle(self): while 1: data = self.request.recv(1024) if not data: break self.request.send('%s' % (data)) self.request.close if __name__ == '__main__': addr = ('localhost', 50000) s = ThreadingTCPServer(addr, myHandler) s.serve_forever() Start this server wait several min then using the echo-client.py from oreilly Programming Python to send it data. Traceback (most recent call last): File "/var/tmp/python2-2.1-root/usr/lib/python2.1/threading.py", line 378, in __bootstrap self.run() File "/var/tmp/python2-2.1-root/usr/lib/python2.1/threading.py", line 366, in run apply(self.__target, self.__args, self.__kwargs) File "/var/tmp/python2-2.1-root/usr/lib/python2.1/SocketServer.py", line 246, in finish_request self.RequestHandlerClass(request, client_address, self) File "/var/tmp/python2-2.1-root/usr/lib/python2.1/SocketServer.py", line 495, in __init__ self.handle() File "./server.py", line 10, in handle data = self.request.recv(1024) error: (9, 'Bad file descriptor') Any requests sent right after this will complete properly. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 04:57 Message: Logged In: YES user_id=6380 I've eproduced this and have now produced a fix. Check out the latest SocketServer.py from the CVS! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424951&group_id=5470 From noreply@sourceforge.net Tue Jul 10 13:03:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 05:03:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-424951 ] ThreadingTCPServer file handle errors. Message-ID: Bugs item #424951, was opened at 2001-05-17 12:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424951&group_id=5470 >Category: Python Library Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Jeff Largent (jlargent) Assigned to: Guido van Rossum (gvanrossum) Summary: ThreadingTCPServer file handle errors. Initial Comment: When running a server using ThreadingTCPServer if the server sit for several minutes between requests the first request it receives will error with a bad file handle error. Python 2.1 (#1, Apr 20 2001, 15:04:11) [GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2 #!/usr/bin/python2 from SocketServer import ThreadingTCPServer, BaseRequestHandler class myHandler (BaseRequestHandler): def handle(self): while 1: data = self.request.recv(1024) if not data: break self.request.send('%s' % (data)) self.request.close if __name__ == '__main__': addr = ('localhost', 50000) s = ThreadingTCPServer(addr, myHandler) s.serve_forever() Start this server wait several min then using the echo-client.py from oreilly Programming Python to send it data. Traceback (most recent call last): File "/var/tmp/python2-2.1-root/usr/lib/python2.1/threading.py", line 378, in __bootstrap self.run() File "/var/tmp/python2-2.1-root/usr/lib/python2.1/threading.py", line 366, in run apply(self.__target, self.__args, self.__kwargs) File "/var/tmp/python2-2.1-root/usr/lib/python2.1/SocketServer.py", line 246, in finish_request self.RequestHandlerClass(request, client_address, self) File "/var/tmp/python2-2.1-root/usr/lib/python2.1/SocketServer.py", line 495, in __init__ self.handle() File "./server.py", line 10, in handle data = self.request.recv(1024) error: (9, 'Bad file descriptor') Any requests sent right after this will complete properly. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 04:57 Message: Logged In: YES user_id=6380 I've eproduced this and have now produced a fix. Check out the latest SocketServer.py from the CVS! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424951&group_id=5470 From noreply@sourceforge.net Tue Jul 10 13:03:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 05:03:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-419873 ] ThreadingTCPServer invalidating sockets Message-ID: Bugs item #419873, was opened at 2001-04-28 16:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419873&group_id=5470 >Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: ThreadingTCPServer invalidating sockets Initial Comment: running this: import SocketServer class TestServer(SocketServer.ThreadingTCPServer): def __init__(self, server_address, RequestHandlerClass): SocketServer.ThreadingTCPServer.__init__(self, server_address, RequestHandlerClass) self.quit = 0 def process_request(self, request, client_address): print 'socket in process_request = %s' % request print 'id(socket) in process_request = %d' % id(request) SocketServer.ThreadingTCPServer.process_request(self, request, client_address) def finish_request(self, request, client_address): print 'socket in finish_request = %s' % request print 'id(socket) in finish_request = %d' % id(request) self.RequestHandlerClass(request, client_address, self) def get_request(self): conn, addr = self.socket.accept() print 'socket in get_request = %s' % conn print 'id(socket) in get_request = %d' % id(conn) return conn,addr if __name__ == '__main__': s = TestServer(('',9950), SocketServer.BaseRequestHandler) s.handle_request() s.server_close() results in the following output (when connected to remotely): socket in get_request = id(socket) in get_request = 135335216 socket in process_request = id(socket) in process_request = 135335216 socket in finish_request = id(socket) in finish_request = 135335216 between in the thread-creation in process_request, the socket's fd changes to -1. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 04:58 Message: Logged In: YES user_id=6380 I've produced a proper fix for this. Check out SocketServer.py from the CVS. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-05-04 14:10 Message: Logged In: NO Thanks, that solves the problem. ---------------------------------------------------------------------- Comment By: Jon Riehl (jriehl) Date: 2001-05-01 14:25 Message: Logged In: YES user_id=22448 See comments for bug #417845. BaseServer.handle_request() potentially (more like consistently) calls close_request() before the thread spun in process_request() is able to complete. A work around is shown in bug #417845 (overload close_request() to do nothing instead of closing the socket.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419873&group_id=5470 From noreply@sourceforge.net Tue Jul 10 13:04:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 05:04:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-407915 ] largefile support under Linux Message-ID: Bugs item #407915, was opened at 2001-03-12 06:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407915&group_id=5470 Category: Build Group: Platform-specific >Status: Closed >Resolution: Works For Me Priority: 3 Submitted By: Hans-Joachim Widmaier (hjwidmai) Assigned to: Guido van Rossum (gvanrossum) Summary: largefile support under Linux Initial Comment: While trying to build 2.1b1 with support for large files under Linux (2.4, glibc 2.2), Objects/fileobject.c didn't compile: gcc -D_FILE_OFFSET_BITS=64 -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -o Objects/fileobject.o Objects/fileobject.c Objects/fileobject.c: In function `_portable_ftell': Objects/fileobject.c:267: incompatible types in return Objects/fileobject.c:275: warning: control reaches end of non-void function This is because fpos_t is a structure holding 2 long longs. After changing return pos to return pos.__pos I got it to compile and it seems to work ok. This is, of course, not a portable solution. Alas, I don't really understand why there are 3 Methods of getting largefile support (/usr/include/feature.h) in glibc, even less why I'm bothered with defining CFLAGS to get it; but configure seems unable to figure out that itself. But this is not Python's fault. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 05:04 Message: Logged In: YES user_id=6380 Closing this since there's no response; I believe the updated recipe works. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-20 10:45 Message: Logged In: YES user_id=6380 Sigh. You can't win with this stuff! Try this for now: http://python.sourceforge.net/devel-docs/lib/posix-large-files.html It suggests to add -D_LARGEFILE64_SOURCE which makes fpos a long long. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407915&group_id=5470 From noreply@sourceforge.net Tue Jul 10 13:21:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 05:21:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-437879 ] SocketServer.py related problems Message-ID: Bugs item #437879, was opened at 2001-07-02 05:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437879&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Guido van Rossum (gvanrossum) Summary: SocketServer.py related problems Initial Comment: I tried several third-party proxy servers for Python (munchy,webdebug) go get working with Python 2.1 under Linux i386. But all fail with similar problems: Under 2.1: andreas@yetix:/home/andreas/src/munchy-0.7: python2.1 munchy.py 8006 Starting proxy on port 8006 Exception in thread Thread-1: Traceback (most recent call last): File "/opt/python-2.1/lib/python2.1/threading.py", line 378, in __bootstrap self.run() File "/opt/python-2.1/lib/python2.1/threading.py", line 366, in run apply(self.__target, self.__args, self.__kwargs) File "/opt/python-2.1/lib/python2.1/SocketServer.py", line 246, in finish_request self.RequestHandlerClass(request, client_address, self) File "/opt/python-2.1/lib/python2.1/SocketServer.py", line 494, in __init__ self.setup() File "/opt/python-2.1/lib/python2.1/SocketServer.py", line 537, in setup self.rfile = self.connection.makefile('rb', self.rbufsize) error: (9, 'Bad file descriptor') I could not track down the problem :-( Andreas ---------------------------------------------------------------------- >Comment By: Andreas Jung (ajung) Date: 2001-07-10 05:21 Message: Logged In: YES user_id=11084 Works fine now with 2.1. Thanks a lot, Andreas ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 04:56 Message: Logged In: YES user_id=6380 Try the version of SocketServer I just checked into the CVS tree. I'm quite sure I fixed this now. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2001-07-06 09:32 Message: Logged In: YES user_id=11084 I could not run the webDebug program with 2.0 because it raised a regular expression related inside the application code so I did not waste more time on it. It was some kind of DC related job - I needed some tools to monitor WebDAV traffic between a client and Zope. I get around the problem by using ethereal for snooping the traffice. Andreas ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-06 09:21 Message: Logged In: YES user_id=6380 Andreas, do these work when used with Python 2.0? Then it could be related to SF bug 417845. Try the workaround listed there and let me know the result. (Is this a DC job? Then I can raise the priority.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437879&group_id=5470 From noreply@sourceforge.net Tue Jul 10 13:22:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 05:22:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-437879 ] SocketServer.py related problems Message-ID: Bugs item #437879, was opened at 2001-07-02 05:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437879&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Guido van Rossum (gvanrossum) Summary: SocketServer.py related problems Initial Comment: I tried several third-party proxy servers for Python (munchy,webdebug) go get working with Python 2.1 under Linux i386. But all fail with similar problems: Under 2.1: andreas@yetix:/home/andreas/src/munchy-0.7: python2.1 munchy.py 8006 Starting proxy on port 8006 Exception in thread Thread-1: Traceback (most recent call last): File "/opt/python-2.1/lib/python2.1/threading.py", line 378, in __bootstrap self.run() File "/opt/python-2.1/lib/python2.1/threading.py", line 366, in run apply(self.__target, self.__args, self.__kwargs) File "/opt/python-2.1/lib/python2.1/SocketServer.py", line 246, in finish_request self.RequestHandlerClass(request, client_address, self) File "/opt/python-2.1/lib/python2.1/SocketServer.py", line 494, in __init__ self.setup() File "/opt/python-2.1/lib/python2.1/SocketServer.py", line 537, in setup self.rfile = self.connection.makefile('rb', self.rbufsize) error: (9, 'Bad file descriptor') I could not track down the problem :-( Andreas ---------------------------------------------------------------------- >Comment By: Andreas Jung (ajung) Date: 2001-07-10 05:22 Message: Logged In: YES user_id=11084 It works fine now under 2.1. Thanks, Andreas ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2001-07-10 05:21 Message: Logged In: YES user_id=11084 Works fine now with 2.1. Thanks a lot, Andreas ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 04:56 Message: Logged In: YES user_id=6380 Try the version of SocketServer I just checked into the CVS tree. I'm quite sure I fixed this now. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2001-07-06 09:32 Message: Logged In: YES user_id=11084 I could not run the webDebug program with 2.0 because it raised a regular expression related inside the application code so I did not waste more time on it. It was some kind of DC related job - I needed some tools to monitor WebDAV traffic between a client and Zope. I get around the problem by using ethereal for snooping the traffice. Andreas ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-06 09:21 Message: Logged In: YES user_id=6380 Andreas, do these work when used with Python 2.0? Then it could be related to SF bug 417845. Try the workaround listed there and let me know the result. (Is this a DC job? Then I can raise the priority.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437879&group_id=5470 From noreply@sourceforge.net Tue Jul 10 13:47:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 05:47:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn Message-ID: Bugs item #417845, was opened at 2001-04-21 08:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: Python 2.1: SocketServer.ThreadingMixIn Initial Comment: SocketServer.ThreadingMixIn does not work properly since it tries to close the socket of a request two times. Workaround for using SocketServer.ThreadingMixIn under Python 2.1: class MyThreadingHTTPServer( SocketServer.ThreadingMixIn, MyHTTPServer ): def close_request(self, request): pass ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-10 05:47 Message: Logged In: NO I tried the fix and it seems to work. I'm wondering if the thread is responsible for calling self.close_request() in self.finish_request? Note: Can we discuss it in news:comp.lang.python? I hate that web interface with Cookies! That's the reason why I was too lazy to login when submitting this bug report. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 04:59 Message: Logged In: YES user_id=6380 I've developed a proper fix for this, I hope. Check out the latest SocketServer.py from the CVS tree. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-07-02 09:05 Message: Logged In: YES user_id=198402 There is still a problem with your solution, Mr glchapman: you make a copy to ensure that the server won't close the copy of the socket that is used in the child thread. Right. But WHO will close this very copy then? The thread still has to close it if one wants to be "clean". So as long as the child thread must close its copy in the threading case, why not make it a thumb rule? Why should we bother about closing anything in the main thread? I still think the solution that I provide is best: make the request handler always responsible for closing the socket from which the request comes. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2001-06-29 08:49 Message: Logged In: YES user_id=86307 Since the request socket object is only a lightweight wrapper around the real socket, why not simply pass request.dup() to the new thread? Then the server's call to close_request affects only its copy of request, not the copy being used in the thread. For example, the following change to ThreadingMixIn fixed this bug for me in a (very simple) test program: def process_request(self, request, client_address): """Start a new thread to process the request.""" import threading t = threading.Thread(target = self.finish_request, args = (request.dup(), client_address)) t.start() ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-28 05:20 Message: Logged In: YES user_id=198402 I have now started a project here concerning a SOCKS proxy written in python (PySocks). It is aimed mostly at people who use a windows box to share their internet connection and uses the threading server from the SocketServer module. So it becomes VERY important to me to know of what will be done about this bug, in the next release/patch of Python library. Could Mr Guido Vanrossum tell us about it? As for now I am forced to provide my patched version of SocketServer.py with my releases, what is not quite satisfactory. SocketServer is provided in the python distribution, so I'd rather tell "there is a patch for python..." Well... In fact I forgot to put it in my first release, but I'll correct this this evening :) ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-20 12:06 Message: Logged In: YES user_id=198402 Well I was wrong. We do need a "try" block to ensure the request is always correctly closed: def finish_request(self, request, client_address): """Finish one request by instantiating RequestHandlerClass.""" try: self.RequestHandlerClass(request, client_address, self) finally: self.close_request(request) This works better. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-13 09:09 Message: Logged In: YES user_id=198402 I forgot to tell: I can not test if it does not break the forking server. I only have a windows platform available for now, and forking doesn't work in the python/win32 environment for now as far as I know. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-13 08:51 Message: Logged In: YES user_id=198402 What I propose can be applied without any compatibility issue. I have tried something that seems to work, at least under windows (but it does need to be more fully tested though). Only 2 small modifications are required: -1- In BaseServer, modification of the last line of handle_request: 
    def handle_request(self):
        """Handle one request, possibly blocking."""
        #import time
        try:
            request, client_address = self.get_request()
        except socket.error:
            return
        if self.verify_request(request, client_address):
            try:
                print 'handle 1'
                self.process_request(request, 
client_address)
                print 'handle 2'
            except:
                self.handle_error(request, client_address)
                self.close_request(request)
Note that only the indentation of the last has been modified so that the close_request is executed only if an exception occur. Still we need to close the request after it had been processed, so here comes the second modification: -2- Still in BaseServer: 
    def finish_request(self, request, client_address):
        """Finish one request by instantiating 
RequestHandlerClass."""
        self.RequestHandlerClass(request, client_address, 
self)
        self.close_request(request)
There is already a try/except block in handle_request, so I thought it was not mandatory here to ensure the request was always closed. Oh... I don't know how <PRE> tags are supported by the bugtracking system of sourceforge, so the samples I give may not appear as I want. This is quite a problem with python :/ ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-12 15:46 Message: Logged In: YES user_id=80200 hi there mr xlagraula, yes, it would be a lot simpler... _if_ it wasn't for the fact that this code is likely to already be quite extensively used. a possible 'upgrade' path could be done by providing a... RequestHandler2 class, or some-such. it would be neater to do this, or similar: for t in self.thread_list: t.join(timeout=0.1) which would join all threads, or you do if stopped(), close_request. i looked into threads a bit more: join has a timeout, and there is a stopped-detection function. easy :) ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-12 14:18 Message: Logged In: YES user_id=198402 Another solution could be to modify the behaviour of the server so that it would be the responsibility of the "child" thread/process to close the socket (except for the forking/threading error cases). Wouldn't it be simplier than child process tracking and thread tracking? ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-04 04:17 Message: Logged In: YES user_id=80200 okay. the forkingmixin code does a fork, records how many children there are, and waits for one of them to exit, before proceeding - in particular, before proceeding to close the request, etc. ... so why is not something similar done in ThreadingMixIn? this kinda- tells me that thread-tracking is really needed, in a similar way to that in forkingmixin. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2001-05-03 16:26 Message: Logged In: YES user_id=413 Just a note of another casualty of this bug: I had to add the mentioned dummy close_request method hack to our own ThreadingMixIn class in mojo nation (in the sourceforge mojonation project's evil module, see the common/MojoNationHTTPServer.py file). Without it, python 2.1 would always raise an exception in the request handler as soon as it tried to call self.connection.makefile() because self.connection had apparently already been closed! (its fd was always -1) ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-02 01:41 Message: Logged In: YES user_id=80200 hi there mr jrielh, thank you very much for the details. what i am having a little difficulty with is, what's the difference between this and python 2.0 SocketServer.py? more specifically, i'm looking at python 2.0 SocketServer.py and, whilst i'm not a Threads expert, i see a t.start() but no t.join(). i've been looking at the Queue example code in the test method of threads.py, and start() is called on every thread, followed by join() on every thread. join waits for the thread to finish, yes? so... if that's the case, then python 2.0 SocketServer.py should suffer from exactly the same behaviour, yes? unless python behaves ever-so-slightly differently (timing issues?) when you have an extra base class like this, with the consequence that close_request() is more likely to be called before ThreadingMixIn.process_request(). ? ---------------------------------------------------------------------- Comment By: Jon Riehl (jriehl) Date: 2001-05-01 14:20 Message: Logged In: YES user_id=22448 This is related to bug #419873. The problem is not specifically in the ThreadingMixin specifically, but where BaseServer calls close_request() after calling process_request(). In the threading mixin, process_request() spins the thread and returns, causing the request socket to be invalidated while the thread is still running. The fix given above will keep the socket valid while the thread is running, but may cause the socket to not close properly (my threads generally close the socket when they are done anyway.) ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-04-26 05:41 Message: Logged In: YES user_id=80200 follow-up. i took a look at the differences between SocketServer.py in 2.0 and 2.1. there is one small change by guido to the ThreadingMixIn.process_request() function that calls self.server_close() instead of explicitly calling self.socket.close(), where TCPServer.server_close() calls self.socket.close(). if mr anonymous (hi!) has over-ridden server_close() and explicitly closes the *request* socket, then of course the socket will get closed twice. the rest of the code-mods is a straightforward code-shuffle moving code from TCPServer into BaseServer: from examining the diff, i really don't see how bypassing close_request(), as shown above with the Workaround in the original bug-report, will help: that will in fact cause the request _never_ to be closed! the rest of this report is part of an email exchange with guido, quoted here: "the bug-report doesn't state whether python 2.0 worked and 2.1 didn't: it also doesn't give enough info. for all we know, he's calling close_request() himself or request.close() directly somewhere in his code, and hasn't told anybody, which is why he has to over-ride close_request() and tell it to do nothing. or he's closing the socket in the HandlerClass, in finish(), or something. we just don't know. either that, or his HandlerClass creates a socket once and only once, with the result that close_request() closes the one socket, and he's _completely_ stuffed, then :)" ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-04-26 04:11 Message: Logged In: YES user_id=80200 hi there, i'm the person who wrote the BaseServer class. guido contacted me about it: could you please send me or post here a working test example that demonstrates the problem. i assume, but you do not state, that you have tested your MyHTTPServer with python 2.0, please let us know, here, if that is a correct assumption. thanks! luke ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470 From noreply@sourceforge.net Tue Jul 10 14:26:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 06:26:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-440037 ] C API descriptions not complete/consiste Message-ID: Bugs item #440037, was opened at 2001-07-10 06:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440037&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: C API descriptions not complete/consiste Initial Comment: Hello, I have been writing a code generator to call functions in a Python script from C. The code seems to be working fine. In the process, I found some things in the C API manual that can be improved: - I would expect 7.4 (numeric objects) before 7.2 (sequence objects) - PyList_SetItem() does not specify return value (probably the same as PyTuple_SetItem() "It returns 0 on success.") - PyList_SET_ITEM() returns a borrowed reference without specifying to what it refers. - PyDict_SetItem() doesnot use 'p' in the description (same for PyDict_SetItemString()) - Return value of both functions is also not specified. - In PyLong_AsLong(), a stray 'OverflowError' is at the end of the description. - Also at PyLong_AsUnsignedLong() (next entry) What I found lacking in the embedding and extending manual is the importing of modules, and finding a function with a specific name from C. Is this something that should be included in the EE manual ? (I'd be willing to give it some thought) Also, I found 2 'problems' in the interface at code level. I will add this seperately to the bug report data base. Albert (a.t.hofkamp@tue.nl) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440037&group_id=5470 From noreply@sourceforge.net Tue Jul 10 14:31:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 06:31:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-440041 ] Inconsistencies in C API calls Message-ID: Bugs item #440041, was opened at 2001-07-10 06:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440041&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistencies in C API calls Initial Comment: Hello, While writing a code generator for calling Python functions from C, I encountered some inconsistencies in a few calls in C API interface: - PyLong_AS_LONG() does not exist, while PyInt_AS_LONG() does - The return type of PyList_SET_ITEM() is different from 'void PyTuple_SET_ITEM() I also found a number of documentation bugs, but those are reported in report #440037 Albert ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440041&group_id=5470 From noreply@sourceforge.net Tue Jul 10 14:59:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 06:59:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn Message-ID: Bugs item #417845, was opened at 2001-04-21 08:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: Python 2.1: SocketServer.ThreadingMixIn Initial Comment: SocketServer.ThreadingMixIn does not work properly since it tries to close the socket of a request two times. Workaround for using SocketServer.ThreadingMixIn under Python 2.1: class MyThreadingHTTPServer( SocketServer.ThreadingMixIn, MyHTTPServer ): def close_request(self, request): pass ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 06:59 Message: Logged In: YES user_id=6380 Yes, the thread is responsible for calling self.close_request() in self.finish_request(). (Although if you just rely on reference counting, it should go away all by itself too.) I don't read the newsgroup frequently, but you can try email if you have more problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-10 05:47 Message: Logged In: NO I tried the fix and it seems to work. I'm wondering if the thread is responsible for calling self.close_request() in self.finish_request? Note: Can we discuss it in news:comp.lang.python? I hate that web interface with Cookies! That's the reason why I was too lazy to login when submitting this bug report. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 04:59 Message: Logged In: YES user_id=6380 I've developed a proper fix for this, I hope. Check out the latest SocketServer.py from the CVS tree. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-07-02 09:05 Message: Logged In: YES user_id=198402 There is still a problem with your solution, Mr glchapman: you make a copy to ensure that the server won't close the copy of the socket that is used in the child thread. Right. But WHO will close this very copy then? The thread still has to close it if one wants to be "clean". So as long as the child thread must close its copy in the threading case, why not make it a thumb rule? Why should we bother about closing anything in the main thread? I still think the solution that I provide is best: make the request handler always responsible for closing the socket from which the request comes. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2001-06-29 08:49 Message: Logged In: YES user_id=86307 Since the request socket object is only a lightweight wrapper around the real socket, why not simply pass request.dup() to the new thread? Then the server's call to close_request affects only its copy of request, not the copy being used in the thread. For example, the following change to ThreadingMixIn fixed this bug for me in a (very simple) test program: def process_request(self, request, client_address): """Start a new thread to process the request.""" import threading t = threading.Thread(target = self.finish_request, args = (request.dup(), client_address)) t.start() ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-28 05:20 Message: Logged In: YES user_id=198402 I have now started a project here concerning a SOCKS proxy written in python (PySocks). It is aimed mostly at people who use a windows box to share their internet connection and uses the threading server from the SocketServer module. So it becomes VERY important to me to know of what will be done about this bug, in the next release/patch of Python library. Could Mr Guido Vanrossum tell us about it? As for now I am forced to provide my patched version of SocketServer.py with my releases, what is not quite satisfactory. SocketServer is provided in the python distribution, so I'd rather tell "there is a patch for python..." Well... In fact I forgot to put it in my first release, but I'll correct this this evening :) ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-20 12:06 Message: Logged In: YES user_id=198402 Well I was wrong. We do need a "try" block to ensure the request is always correctly closed: def finish_request(self, request, client_address): """Finish one request by instantiating RequestHandlerClass.""" try: self.RequestHandlerClass(request, client_address, self) finally: self.close_request(request) This works better. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-13 09:09 Message: Logged In: YES user_id=198402 I forgot to tell: I can not test if it does not break the forking server. I only have a windows platform available for now, and forking doesn't work in the python/win32 environment for now as far as I know. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-13 08:51 Message: Logged In: YES user_id=198402 What I propose can be applied without any compatibility issue. I have tried something that seems to work, at least under windows (but it does need to be more fully tested though). Only 2 small modifications are required: -1- In BaseServer, modification of the last line of handle_request: 
    def handle_request(self):
        """Handle one request, possibly blocking."""
        #import time
        try:
            request, client_address = self.get_request()
        except socket.error:
            return
        if self.verify_request(request, client_address):
            try:
                print 'handle 1'
                self.process_request(request, 
client_address)
                print 'handle 2'
            except:
                self.handle_error(request, client_address)
                self.close_request(request)
Note that only the indentation of the last has been modified so that the close_request is executed only if an exception occur. Still we need to close the request after it had been processed, so here comes the second modification: -2- Still in BaseServer: 
    def finish_request(self, request, client_address):
        """Finish one request by instantiating 
RequestHandlerClass."""
        self.RequestHandlerClass(request, client_address, 
self)
        self.close_request(request)
There is already a try/except block in handle_request, so I thought it was not mandatory here to ensure the request was always closed. Oh... I don't know how <PRE> tags are supported by the bugtracking system of sourceforge, so the samples I give may not appear as I want. This is quite a problem with python :/ ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-12 15:46 Message: Logged In: YES user_id=80200 hi there mr xlagraula, yes, it would be a lot simpler... _if_ it wasn't for the fact that this code is likely to already be quite extensively used. a possible 'upgrade' path could be done by providing a... RequestHandler2 class, or some-such. it would be neater to do this, or similar: for t in self.thread_list: t.join(timeout=0.1) which would join all threads, or you do if stopped(), close_request. i looked into threads a bit more: join has a timeout, and there is a stopped-detection function. easy :) ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-12 14:18 Message: Logged In: YES user_id=198402 Another solution could be to modify the behaviour of the server so that it would be the responsibility of the "child" thread/process to close the socket (except for the forking/threading error cases). Wouldn't it be simplier than child process tracking and thread tracking? ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-04 04:17 Message: Logged In: YES user_id=80200 okay. the forkingmixin code does a fork, records how many children there are, and waits for one of them to exit, before proceeding - in particular, before proceeding to close the request, etc. ... so why is not something similar done in ThreadingMixIn? this kinda- tells me that thread-tracking is really needed, in a similar way to that in forkingmixin. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2001-05-03 16:26 Message: Logged In: YES user_id=413 Just a note of another casualty of this bug: I had to add the mentioned dummy close_request method hack to our own ThreadingMixIn class in mojo nation (in the sourceforge mojonation project's evil module, see the common/MojoNationHTTPServer.py file). Without it, python 2.1 would always raise an exception in the request handler as soon as it tried to call self.connection.makefile() because self.connection had apparently already been closed! (its fd was always -1) ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-02 01:41 Message: Logged In: YES user_id=80200 hi there mr jrielh, thank you very much for the details. what i am having a little difficulty with is, what's the difference between this and python 2.0 SocketServer.py? more specifically, i'm looking at python 2.0 SocketServer.py and, whilst i'm not a Threads expert, i see a t.start() but no t.join(). i've been looking at the Queue example code in the test method of threads.py, and start() is called on every thread, followed by join() on every thread. join waits for the thread to finish, yes? so... if that's the case, then python 2.0 SocketServer.py should suffer from exactly the same behaviour, yes? unless python behaves ever-so-slightly differently (timing issues?) when you have an extra base class like this, with the consequence that close_request() is more likely to be called before ThreadingMixIn.process_request(). ? ---------------------------------------------------------------------- Comment By: Jon Riehl (jriehl) Date: 2001-05-01 14:20 Message: Logged In: YES user_id=22448 This is related to bug #419873. The problem is not specifically in the ThreadingMixin specifically, but where BaseServer calls close_request() after calling process_request(). In the threading mixin, process_request() spins the thread and returns, causing the request socket to be invalidated while the thread is still running. The fix given above will keep the socket valid while the thread is running, but may cause the socket to not close properly (my threads generally close the socket when they are done anyway.) ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-04-26 05:41 Message: Logged In: YES user_id=80200 follow-up. i took a look at the differences between SocketServer.py in 2.0 and 2.1. there is one small change by guido to the ThreadingMixIn.process_request() function that calls self.server_close() instead of explicitly calling self.socket.close(), where TCPServer.server_close() calls self.socket.close(). if mr anonymous (hi!) has over-ridden server_close() and explicitly closes the *request* socket, then of course the socket will get closed twice. the rest of the code-mods is a straightforward code-shuffle moving code from TCPServer into BaseServer: from examining the diff, i really don't see how bypassing close_request(), as shown above with the Workaround in the original bug-report, will help: that will in fact cause the request _never_ to be closed! the rest of this report is part of an email exchange with guido, quoted here: "the bug-report doesn't state whether python 2.0 worked and 2.1 didn't: it also doesn't give enough info. for all we know, he's calling close_request() himself or request.close() directly somewhere in his code, and hasn't told anybody, which is why he has to over-ride close_request() and tell it to do nothing. or he's closing the socket in the HandlerClass, in finish(), or something. we just don't know. either that, or his HandlerClass creates a socket once and only once, with the result that close_request() closes the one socket, and he's _completely_ stuffed, then :)" ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-04-26 04:11 Message: Logged In: YES user_id=80200 hi there, i'm the person who wrote the BaseServer class. guido contacted me about it: could you please send me or post here a working test example that demonstrates the problem. i assume, but you do not state, that you have tested your MyHTTPServer with python 2.0, please let us know, here, if that is a correct assumption. thanks! luke ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470 From noreply@sourceforge.net Tue Jul 10 16:23:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 08:23:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-440037 ] C API descriptions not complete/consistent Message-ID: Bugs item #440037, was opened at 2001-07-10 06:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440037&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: C API descriptions not complete/consistent Initial Comment: Hello, I have been writing a code generator to call functions in a Python script from C. The code seems to be working fine. In the process, I found some things in the C API manual that can be improved: - I would expect 7.4 (numeric objects) before 7.2 (sequence objects) - PyList_SetItem() does not specify return value (probably the same as PyTuple_SetItem() "It returns 0 on success.") - PyList_SET_ITEM() returns a borrowed reference without specifying to what it refers. - PyDict_SetItem() doesnot use 'p' in the description (same for PyDict_SetItemString()) - Return value of both functions is also not specified. - In PyLong_AsLong(), a stray 'OverflowError' is at the end of the description. - Also at PyLong_AsUnsignedLong() (next entry) What I found lacking in the embedding and extending manual is the importing of modules, and finding a function with a specific name from C. Is this something that should be included in the EE manual ? (I'd be willing to give it some thought) Also, I found 2 'problems' in the interface at code level. I will add this seperately to the bug report data base. Albert (a.t.hofkamp@tue.nl) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-10 08:23 Message: Logged In: YES user_id=3066 I don't understand the comment on the ordering of the Numeric and Sequence object sections; what is the motivation for changing the ordering? Regarding the issue of import & function lookup: Yes, the EE manual should cover this. Suggested text would be greatly appreciated (without markup is fine), or I can work on it when time permits. I've fixed the other issues in my working copy; these should be checked in before too long. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440037&group_id=5470 From noreply@sourceforge.net Tue Jul 10 17:06:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 09:06:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-440037 ] C API descriptions not complete/consistent Message-ID: Bugs item #440037, was opened at 2001-07-10 06:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440037&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: C API descriptions not complete/consistent Initial Comment: Hello, I have been writing a code generator to call functions in a Python script from C. The code seems to be working fine. In the process, I found some things in the C API manual that can be improved: - I would expect 7.4 (numeric objects) before 7.2 (sequence objects) - PyList_SetItem() does not specify return value (probably the same as PyTuple_SetItem() "It returns 0 on success.") - PyList_SET_ITEM() returns a borrowed reference without specifying to what it refers. - PyDict_SetItem() doesnot use 'p' in the description (same for PyDict_SetItemString()) - Return value of both functions is also not specified. - In PyLong_AsLong(), a stray 'OverflowError' is at the end of the description. - Also at PyLong_AsUnsignedLong() (next entry) What I found lacking in the embedding and extending manual is the importing of modules, and finding a function with a specific name from C. Is this something that should be included in the EE manual ? (I'd be willing to give it some thought) Also, I found 2 'problems' in the interface at code level. I will add this seperately to the bug report data base. Albert (a.t.hofkamp@tue.nl) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-10 09:06 Message: Logged In: NO Regarding the order of numeric and sequence objects: My idea is that numeric objects are easier to understand than sequence objects. So when browsing through the documentation (I know the docs are not supposed to be browsed, but before being able to work with it, one has to read the EE manual, and probably browse the API manual to get a feel for the API calls available), the interface for the numeric objects are relatively easy to understand. With that knowledge, the next sections become easier, because the api's for the other objects have a similar structure. Albert ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-10 08:23 Message: Logged In: YES user_id=3066 I don't understand the comment on the ordering of the Numeric and Sequence object sections; what is the motivation for changing the ordering? Regarding the issue of import & function lookup: Yes, the EE manual should cover this. Suggested text would be greatly appreciated (without markup is fine), or I can work on it when time permits. I've fixed the other issues in my working copy; these should be checked in before too long. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440037&group_id=5470 From noreply@sourceforge.net Tue Jul 10 17:12:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 09:12:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-439012 ] Need doc: initial state of allocs Message-ID: Bugs item #439012, was opened at 2001-07-06 03:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439012&group_id=5470 Category: Documentation Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Need doc: initial state of allocs Initial Comment: The Py_Malloc and PyObject_New/PyObject_NEW are not documented as to whether the memory they return is pre-initialized to zeros or not. In fact, PyObject_New/PyObject_NEW aren't documented anywhere for extension writers. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-10 09:12 Message: Logged In: YES user_id=3066 Fixed in Doc/api/api.tex revisions 1.129 and 1.117.2.8. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-07 18:38 Message: Logged In: YES user_id=3066 I've addressed most of this in my working copies, but am not yet ready to check it in, and not everything needed to fully resolve this has been written. For the current state of what's written, see the development version of the documentation on SourceForge: http://python.sourceforge.net/devel-docs/api/api.html ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439012&group_id=5470 From noreply@sourceforge.net Tue Jul 10 17:14:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 09:14:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-440037 ] C API descriptions not complete/consistent Message-ID: Bugs item #440037, was opened at 2001-07-10 06:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440037&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: C API descriptions not complete/consistent Initial Comment: Hello, I have been writing a code generator to call functions in a Python script from C. The code seems to be working fine. In the process, I found some things in the C API manual that can be improved: - I would expect 7.4 (numeric objects) before 7.2 (sequence objects) - PyList_SetItem() does not specify return value (probably the same as PyTuple_SetItem() "It returns 0 on success.") - PyList_SET_ITEM() returns a borrowed reference without specifying to what it refers. - PyDict_SetItem() doesnot use 'p' in the description (same for PyDict_SetItemString()) - Return value of both functions is also not specified. - In PyLong_AsLong(), a stray 'OverflowError' is at the end of the description. - Also at PyLong_AsUnsignedLong() (next entry) What I found lacking in the embedding and extending manual is the importing of modules, and finding a function with a specific name from C. Is this something that should be included in the EE manual ? (I'd be willing to give it some thought) Also, I found 2 'problems' in the interface at code level. I will add this seperately to the bug report data base. Albert (a.t.hofkamp@tue.nl) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-10 09:14 Message: Logged In: YES user_id=3066 The corrections and additions to the API manual have been committed as Doc/api/api.tex revisions 1.129 and 1.117.2.8. Re-ordering of sections will be considered separately. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-10 09:06 Message: Logged In: NO Regarding the order of numeric and sequence objects: My idea is that numeric objects are easier to understand than sequence objects. So when browsing through the documentation (I know the docs are not supposed to be browsed, but before being able to work with it, one has to read the EE manual, and probably browse the API manual to get a feel for the API calls available), the interface for the numeric objects are relatively easy to understand. With that knowledge, the next sections become easier, because the api's for the other objects have a similar structure. Albert ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-10 08:23 Message: Logged In: YES user_id=3066 I don't understand the comment on the ordering of the Numeric and Sequence object sections; what is the motivation for changing the ordering? Regarding the issue of import & function lookup: Yes, the EE manual should cover this. Suggested text would be greatly appreciated (without markup is fine), or I can work on it when time permits. I've fixed the other issues in my working copy; these should be checked in before too long. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440037&group_id=5470 From noreply@sourceforge.net Tue Jul 10 18:01:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 10:01:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-439997 ] infinite loop in re.match Message-ID: Bugs item #439997, was opened at 2001-07-10 02:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439997&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dieter Maurer (dmaurer) >Assigned to: Fredrik Lundh (effbot) Summary: infinite loop in re.match Initial Comment: Python 2.0.1 "re.match" enters infinite loop for a regular expression that was carefully designed not to lead to loops (an easy expression). See attached file. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-10 10:01 Message: Logged In: YES user_id=31435 Assigned to /F, but I don't see a bug here. While your regexp should be speedy *when* applied to a string that actually matches (the regexp does not match the long string in your test case), you create an exponential number of backtracking possibilities by repeating \s* at both ends of the first repeated group (in effect, you're specifying an unbounded number of instances of the highly ambiguous \s*\s*). So when the regexp doesn't match, it can be unboundedly slow. This minor rewrite doesn't have that problem (it simply moves the first \s* "out of the loop"): r=']*>\s*(<[?][^>]*>\s*)+<[^/?][^>]*>' BTW, your test string doesn't match because it ends with It *would* match if it ended with It's unclear whether you expected it to match. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439997&group_id=5470 From noreply@sourceforge.net Tue Jul 10 18:08:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 10:08:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-439993 ] infinite loop in re.match Message-ID: Bugs item #439993, was opened at 2001-07-10 02:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439993&group_id=5470 Category: Regular Expressions Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: infinite loop in re.match Initial Comment: Python 2.0.1 "re.match" enters infinite loop for a regular expression that was carefully designed not to lead to loops (an easy expression). See attached file. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-10 10:08 Message: Logged In: YES user_id=31435 Closed; it's a duplicate of 439997. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439993&group_id=5470 From noreply@sourceforge.net Tue Jul 10 18:26:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 10:26:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-423851 ] Python 2.1 Falling Over On Win2K Message-ID: Bugs item #423851, was opened at 2001-05-13 23:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423851&group_id=5470 Category: Windows Group: Platform-specific >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Paul Prescod (prescod) Summary: Python 2.1 Falling Over On Win2K Initial Comment: Platform: Windows 2000 Python Version: 2.1 Box: AMD Thunderbird 750 with 128meg Hi, I don't know if anyone else has experienced this so I will put it out there regardless. I have been using the distribution of Python 2.1 which comes with ActiveState ActivePython. If I walk a directory using the os.path.walk module and return the results to a list and then try to display this list, Python falls flat on it's face and shuts down. However this does not occur when using Python 2.0. The piece of code I have been using is as follows: import os def walker(arg, dirname, filenames): # Create A List Of Files In A Directory for files in filenames: arg.append(os.path.join(dirname, files)) DirLst = [] os.path.walk('c:\test\', walker, DirLst) DirLst # At this point the command should display the list to the screen, instead the program shuts itself down ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-10 10:26 Message: Logged In: YES user_id=31435 Closed, due to 2 months without a followup to the questions. ---------------------------------------------------------------------- Comment By: Paul Prescod (prescod) Date: 2001-05-14 15:14 Message: Logged In: YES user_id=31788 I am trying, somewhat, to read the poster's mind. But I'm guessing that the problem has nothing to do with Python or ActivePython. Instead of trying to print the list to the screen, write it to a file like this: open("foo", "w").write(repr(DirLst)) Writing it to the screen may trigger a bug in Scintilla which is used in PythonWin relating to long lines. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-05-13 23:43 Message: Logged In: YES user_id=31435 Assigned to Paul. Worked fine for me on a directory w/ over 10,000 files under it, but I'm not using the ActiveState distribution. If this is specific to ActiveState Python, you should report the bug to them. "Falls on its face and shuts down" doesn't mean anything to me. Were you running from a DOS box Python, or perhaps from within PythonWin, or Komodo, or ...? Not enough info here. I tried it from a DOS box Python. If it works for you under a DOS box Python, then problems specific to PythonWin or Komodo definitely don't belong here. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423851&group_id=5470 From noreply@sourceforge.net Tue Jul 10 18:34:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 10:34:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-440017 ] SystemError when importing packages Message-ID: Bugs item #440017, was opened at 2001-07-10 04:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440017&group_id=5470 Category: Python Interpreter Core Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: M.-A. Lemburg (lemburg) >Assigned to: Tim Peters (tim_one) Summary: SystemError when importing packages Initial Comment: Python 2.1 (haven't checked older versions) on Windows has a problem with importing packages with a case mismatch in the name, e.g. trying to import the package "encodings" using the name "Encodings" gives you the following error: >>> import Encodings Traceback (most recent call last): File "", line 1, in ? import Encodings SystemError: NULL result without error in call_object >>> It should ideally output: ImportError: No module named Encodings (case-mismatch) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-10 10:34 Message: Logged In: YES user_id=31435 Works for me under current CVS. Likely fixed along with one of these other bugs: 438295: [Windows] __init__.py cause strange behavior 417093: Case sensitive import: dir and .py file w/ same name You should check 2.1.1 when it comes out (this Friday?) to make sure it's fixed there too ... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440017&group_id=5470 From noreply@sourceforge.net Tue Jul 10 20:22:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 12:22:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-440017 ] SystemError when importing packages Message-ID: Bugs item #440017, was opened at 2001-07-10 04:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440017&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Closed Resolution: Fixed Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Tim Peters (tim_one) Summary: SystemError when importing packages Initial Comment: Python 2.1 (haven't checked older versions) on Windows has a problem with importing packages with a case mismatch in the name, e.g. trying to import the package "encodings" using the name "Encodings" gives you the following error: >>> import Encodings Traceback (most recent call last): File "", line 1, in ? import Encodings SystemError: NULL result without error in call_object >>> It should ideally output: ImportError: No module named Encodings (case-mismatch) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-10 12:22 Message: Logged In: YES user_id=31435 I confirmed this is fixed in 2.1.1: C:\Code\2.1.1\dist\src\PCbuild>python Python 2.1.1c1 (#19, Jul 10 2001, 14:55:28) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import Encodings Traceback (most recent call last): File "", line 1, in ? ImportError: No module named Encodings >>> It doesn't have a "(case-mismatch)" thingie in the exception detail, not any more than "import Math" or "import SYS" do. These msgs-- like the import rules -- are platform-independent now. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-10 10:34 Message: Logged In: YES user_id=31435 Works for me under current CVS. Likely fixed along with one of these other bugs: 438295: [Windows] __init__.py cause strange behavior 417093: Case sensitive import: dir and .py file w/ same name You should check 2.1.1 when it comes out (this Friday?) to make sure it's fixed there too ... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440017&group_id=5470 From noreply@sourceforge.net Tue Jul 10 20:50:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 12:50:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-440178 ] Build not finding libtk on Solaris 2.6 Message-ID: Bugs item #440178, was opened at 2001-07-10 12:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440178&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Build not finding libtk on Solaris 2.6 Initial Comment: Using gcc 2.95.3 for Solaris 2.6 I was able to build a version of Python 2.1 without additional modules apparently without problem albeit with a fair number of compiler warnings . But when I tried to rebuild it with Tk after doing a make clobber, the library build could not find libtk. I downloaded version 8.3 of tcl and Tk from the sunfreeware site; the pkgadd loaded them into /usr/local/lib. libtk8.3.s0 libtcl8.3.so _tkinter and tkappinit apparently compiled OK but the library build failed (also with a copy of libtk in the local directory (/opt2/GNU/Python2.1) where I had unpacked Python2.1 . The edited portion of Setup was as follows : # *** Always uncomment this (leave the leading underscore in!): _tkinter _tkinter.c tkappinit.c -DWITH_APPINIT \ # *** Uncomment and edit to reflect where your Tcl/Tk libraries are: -L/usr/local/lib \ # *** Uncomment and edit to reflect where your Tcl/Tk headers are: -I/usr/local/include \ # *** Uncomment and edit to reflect where your X11 header files are: # -I/usr/X11R6/include \ # *** Or uncomment this for Solaris: -I/usr/openwin/include \ # *** Uncomment and edit for Tix extension only: # -DWITH_TIX -ltix8.1.8.2 \ # *** Uncomment and edit for BLT extension only: # -DWITH_BLT -I/usr/local/blt/blt8.0-unoff/include -lBLT8.0 \ # *** Uncomment and edit for PIL (TkImaging) extension only: # (See http://www.pythonware.com/products/pil/ for more info) # -DWITH_PIL -I../Extensions/Imaging/libImaging tkImaging.c \ # *** Uncomment and edit for TOGL extension only: # -DWITH_TOGL togl.c \ # *** Uncomment and edit to reflect your Tcl/Tk versions: -ltk8.3 -ltcl8.3 \ # *** Uncomment and edit to reflect where your X11 libraries are: # -L/usr/X11R6/lib \ # *** Or uncomment this for Solaris: -L/usr/openwin/lib \ # *** Uncomment these for TOGL extension only: # -lGL -lGLU -lXext -lXmu \ # *** Uncomment for AIX: # -lld \ # *** Always uncomment this; X11 libraries to link with: -lX11 An edited portion of the make output follows : gcc -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -DWITH_APPINIT -I/usr/local/include -I/usr/openwin/include -c ./Modules/_tkinter.c -o Modules/_tkinter.o In file included from /usr/local/include/tk.h:83, from ./Modules/_tkinter.c:45: /usr/openwin/include/X11/Xlib.h:149: warning: function declaration isn't a prototype (several more such) /usr/openwin/include/X11/Xlib.h:2063: warning: type defaults to `int' in declaration of `XSetTransientForHint' (Many more such) /usr/openwin/include/X11/Xlib.h:4162: warning: type defaults to `int' in declaration of `XWindowEvent' gcc -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -DWITH_APPINIT -I/usr/local/include -I/usr/openwin/include -c ./Modules/tkappinit.c -o Modules/tkappinit.o In file included from /usr/local/include/tk.h:83, from ./Modules/tkappinit.c:16: /usr/openwin/include/X11/Xlib.h:149: warning: function declaration isn't a prototype (ditto) /usr/openwin/include/X11/Xlib.h:2063: warning: type defaults to `int' in declaration of `XSetTransientForHint' (ditto) /usr/openwin/include/X11/Xlib.h:4162: warning: type defaults to `int' in declaration of `XWindowEvent' if test -f buildno; then \ expr `cat buildno` + 1 >buildno1; \ mv -f buildno1 buildno; \ else echo 1 >buildno; fi gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H -DBUILD=`cat buildno` -o Modules/getbuildinfo.o ./Modules/getbuildinfo.c rm -f libpython2.1.a ar cr libpython2.1.a Modules/getbuildinfo.o ar cr libpython2.1.a Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/parsetok.o Parser/tokenizer.o Parser/bitset.o Parser/metagrammar.o Parser/myreadline.o ar cr libpython2.1.a Objects/abstract.o Objects/bufferobject.o Objects/cellobject.o Objects/classobject.o Objects/cobject.o Objects/complexobject.o Objects/fileobject.o Objects/floatobject.o Objects/frameobject.o Objects/funcobject.o Objects/intobject.o Objects/listobject.o Objects/longobject.o Objects/dictobject.o Objects/methodobject.o Objects/moduleobject.o Objects/object.o Objects/rangeobject.o Objects/sliceobject.o Objects/stringobject.o Objects/tupleobject.o Objects/typeobject.o Objects/unicodeobject.o Objects/unicodectype.o ar cr libpython2.1.a Python/bltinmodule.o Python/exceptions.o Python/ceval.o Python/compile.o Python/codecs.o Python/errors.o Python/frozen.o Python/frozenmain.o Python/future.o Python/getargs.o Python/getcompiler.o Python/getcopyright.o Python/getmtime.o Python/getplatform.o Python/getversion.o Python/graminit.o Python/import.o Python/importdl.o Python/marshal.o Python/modsupport.o Python/mystrtoul.o Python/pyfpe.o Python/pystate.o Python/pythonrun.o Python/structmember.o Python/symtable.o Python/sysmodule.o Python/traceback.o Python/getopt.o Python/dynload_shlib.o Python/thread.o Python/thread.o ar cr libpython2.1.a Modules/config.o Modules/getpath.o Modules/main.o ar cr libpython2.1.a Modules/gcmodule.o Modules/threadmodule.o Modules/signalmodule.o Modules/posixmodule.o Modules/_sre.o Modules/_tkinter.o Modules/tkappinit.o : libpython2.1.a gcc -o python \ Modules/python.o \ libpython2.1.a -lpthread -lsocket -lnsl -ldl -lthread -L/usr/local/lib -ltk8.3 -ltcl8.3 -L/usr/openwin/lib -lX11 -lm PYTHONPATH= ./python ./setup.py build ld.so.1: ./python: fatal: libtk8.3.so: open failed: No such file or directory *** Error code 137 make: Fatal error: Command failed for target `sharedmods' ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440178&group_id=5470 From noreply@sourceforge.net Tue Jul 10 20:58:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Jul 2001 12:58:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-439997 ] infinite loop in re.match Message-ID: Bugs item #439997, was opened at 2001-07-10 02:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439997&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dieter Maurer (dmaurer) Assigned to: Fredrik Lundh (effbot) Summary: infinite loop in re.match Initial Comment: Python 2.0.1 "re.match" enters infinite loop for a regular expression that was carefully designed not to lead to loops (an easy expression). See attached file. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 12:58 Message: Logged In: YES user_id=6380 A general comment for folks who report problems with regular expressions: Komodo has a tool that debugs a regular expression, by stepping through its execution step by step. Very educational, and would probably help understanding what's going on in cases like the case here reported. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-10 10:01 Message: Logged In: YES user_id=31435 Assigned to /F, but I don't see a bug here. While your regexp should be speedy *when* applied to a string that actually matches (the regexp does not match the long string in your test case), you create an exponential number of backtracking possibilities by repeating \s* at both ends of the first repeated group (in effect, you're specifying an unbounded number of instances of the highly ambiguous \s*\s*). So when the regexp doesn't match, it can be unboundedly slow. This minor rewrite doesn't have that problem (it simply moves the first \s* "out of the loop"): r=']*>\s*(<[?][^>]*>\s*)+<[^/?][^>]*>' BTW, your test string doesn't match because it ends with It *would* match if it ended with It's unclear whether you expected it to match. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439997&group_id=5470 From noreply@sourceforge.net Wed Jul 11 11:32:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 03:32:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-440351 ] saxutils.escape needs to escape "quotes" Message-ID: Bugs item #440351, was opened at 2001-07-11 03:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440351&group_id=5470 Category: XML Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Nobody/Anonymous (nobody) Summary: saxutils.escape needs to escape "quotes" Initial Comment: XML attributes containing a value with a double quote are not properly escaped. Consider from xml.sax import saxutils gen = saxutils.XMLGenerator() gen.startDocument() gen.startElement('spam', {'width': '12"'}) This produces That second line should more likely be or perhaps use the hex escape, which I think is ''. But I'm not an XML guru so don't trust me on either one! Andrew Dalke dalke@acm.org ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440351&group_id=5470 From noreply@sourceforge.net Wed Jul 11 11:39:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 03:39:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-439997 ] infinite loop in re.match Message-ID: Bugs item #439997, was opened at 2001-07-10 02:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439997&group_id=5470 Category: Regular Expressions Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Dieter Maurer (dmaurer) Assigned to: Fredrik Lundh (effbot) Summary: infinite loop in re.match Initial Comment: Python 2.0.1 "re.match" enters infinite loop for a regular expression that was carefully designed not to lead to loops (an easy expression). See attached file. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2001-07-11 03:39 Message: Logged In: YES user_id=38376 See Tim's analysis for the correct solution. (time to add a "canned response"?) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 12:58 Message: Logged In: YES user_id=6380 A general comment for folks who report problems with regular expressions: Komodo has a tool that debugs a regular expression, by stepping through its execution step by step. Very educational, and would probably help understanding what's going on in cases like the case here reported. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-10 10:01 Message: Logged In: YES user_id=31435 Assigned to /F, but I don't see a bug here. While your regexp should be speedy *when* applied to a string that actually matches (the regexp does not match the long string in your test case), you create an exponential number of backtracking possibilities by repeating \s* at both ends of the first repeated group (in effect, you're specifying an unbounded number of instances of the highly ambiguous \s*\s*). So when the regexp doesn't match, it can be unboundedly slow. This minor rewrite doesn't have that problem (it simply moves the first \s* "out of the loop"): r=']*>\s*(<[?][^>]*>\s*)+<[^/?][^>]*>' BTW, your test string doesn't match because it ends with It *would* match if it ended with It's unclear whether you expected it to match. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439997&group_id=5470 From noreply@sourceforge.net Wed Jul 11 11:56:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 03:56:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-439997 ] infinite loop in re.match Message-ID: Bugs item #439997, was opened at 2001-07-10 02:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439997&group_id=5470 Category: Regular Expressions Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Dieter Maurer (dmaurer) Assigned to: Fredrik Lundh (effbot) Summary: infinite loop in re.match Initial Comment: Python 2.0.1 "re.match" enters infinite loop for a regular expression that was carefully designed not to lead to loops (an easy expression). See attached file. ---------------------------------------------------------------------- >Comment By: Dieter Maurer (dmaurer) Date: 2001-07-11 03:56 Message: Logged In: YES user_id=265829 Thank you all! I learned something... ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2001-07-11 03:39 Message: Logged In: YES user_id=38376 See Tim's analysis for the correct solution. (time to add a "canned response"?) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 12:58 Message: Logged In: YES user_id=6380 A general comment for folks who report problems with regular expressions: Komodo has a tool that debugs a regular expression, by stepping through its execution step by step. Very educational, and would probably help understanding what's going on in cases like the case here reported. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-10 10:01 Message: Logged In: YES user_id=31435 Assigned to /F, but I don't see a bug here. While your regexp should be speedy *when* applied to a string that actually matches (the regexp does not match the long string in your test case), you create an exponential number of backtracking possibilities by repeating \s* at both ends of the first repeated group (in effect, you're specifying an unbounded number of instances of the highly ambiguous \s*\s*). So when the regexp doesn't match, it can be unboundedly slow. This minor rewrite doesn't have that problem (it simply moves the first \s* "out of the loop"): r=']*>\s*(<[?][^>]*>\s*)+<[^/?][^>]*>' BTW, your test string doesn't match because it ends with It *would* match if it ended with It's unclear whether you expected it to match. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439997&group_id=5470 From noreply@sourceforge.net Wed Jul 11 15:32:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 07:32:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-437487 ] 2.1 build on Solaris fails if CC is set Message-ID: Bugs item #437487, was opened at 2001-06-29 15:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437487&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: A.M. Kuchling (akuchling) Summary: 2.1 build on Solaris fails if CC is set Initial Comment: If you have CC set to "gcc", then the "setup.py" script compiles the extensions incorrectly (in particular, the "-fPIC" on the compile is not used): ... PYTHONPATH= ./python ./setup.py build running build running build_ext building 'struct' extension creating build creating build/temp.solaris-2.7-sun4u-2.1 gcc -I. -I/extra/Python-2.1/./Include -I/usr/local/include -IInclude/ -c /extra/Python-2.1/Modules/structmodule.c -o build/temp.solaris-2.7-sun4u-2.1/structmodule.o creating build/lib.solaris-2.7-sun4u-2.1 gcc -shared build/temp.solaris-2.7-sun4u-2.1/structmodule.o -L/usr/local/lib -o build/lib.solaris-2.7-sun4u-2.1/struct.so Text relocation remains referenced against symbol offset in file 0x2094 build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x200c build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x3398 build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x2098 build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x2070 build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x206c .... If you want to compile code configured via "configure" with the "gcc" compiler and you have both the "gcc" and the Sun C compiler installed on your system, then you need to have the environment variable "CC" set to "gcc": CC=gcc So people (like myself) have "CC=gcc" in their .profile or equivalent in .login, and have had that for years without thinking about it. If you don't have "CC=gcc" set in your environment, then things work fine: ... PYTHONPATH= ./python ./setup.py build running build running build_ext building 'struct' extension creating build creating build/temp.solaris-2.7-sun4u-2.1 gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -I. -I/home/tflagg/projects/python/2.1sunos/Python-2.1/./Include -I/usr/local/include -IInclude/ -c /home/tflagg/projects/python/2.1sunos/Python-2.1/Modules/structmodule.c -o build/temp.solaris-2.7-sun4u-2.1/structmodule.o (In particular, the "-fPIC" flag needs to be there as shown above.) The problem lines in "setup.py" are: 112 # When you run "make CC=altcc" or something similar, you really want 113 # those environment variables passed into the setup.py phase. Here's 114 # a small set of useful ones. 115 compiler = os.environ.get('CC') <---------- 116 linker_so = os.environ.get('LDSHARED') 117 args = {} 118 # unfortunately, distutils doesn't let us provide separate C and C++ 119 # compilers 120 if compiler is not None: <--------------- 121 args['compiler_so'] = compiler <--------- It's true the user may want to set site-specific/user-specific compiler options. However, if "CC" is only "gcc" then the user is trying to communicate: - Use "gcc" rather than Sun's C compiler They are NOT trying to communicate: - Do not use any of the compiler flags for compiling shared objects. The reason this bug Solaris-specific is because Solaris installations are the most likely to have a non-gcc compiler installed, requiring the "CC=gcc" environment variable set. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437487&group_id=5470 From noreply@sourceforge.net Wed Jul 11 15:34:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 07:34:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-422265 ] Python 2.1 curses build failure on HPUX Message-ID: Bugs item #422265, was opened at 2001-05-08 05:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422265&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) >Assigned to: A.M. Kuchling (akuchling) Summary: Python 2.1 curses build failure on HPUX Initial Comment: Builing the curses module from Python 2.1 on HPUX 11.0 fails with the following errors: building '_curses' extension cc -Ae -O +z -I. -I/home/richardt/python/Python- 2.1/./Include -I/usr/local/include -IInclude/ - c /home/richardt/python/Python- 2.1/Modules/_cursesmodule.c -o build/temp.hp-ux- B.11.00-9000/770-2.1/_cursesmodule.o cc: line 309: warning 5004: Uninitialized variable "arg1" in function "PyCursesWindow_getbegyx" (5004) cc: line 309: warning 5004: Uninitialized variable "arg2" in function "PyCursesWindow_getbegyx" (5004) cc: line 310: warning 5004: Uninitialized variable "arg1" in function "PyCursesWindow_getmaxyx" (5004) cc: line 310: warning 5004: Uninitialized variable "arg2" in function "PyCursesWindow_getmaxyx" (5004) cc: line 311: warning 5004: Uninitialized variable "arg1" in function "PyCursesWindow_getparyx" (5004) cc: line 311: warning 5004: Uninitialized variable "arg2" in function "PyCursesWindow_getparyx" (5004) For full error listing see attached file curses.txt ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422265&group_id=5470 From noreply@sourceforge.net Wed Jul 11 16:07:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 08:07:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-439990 ] os.nice() return 0 under Linux Message-ID: Bugs item #439990, was opened at 2001-07-10 02:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439990&group_id=5470 Category: Python Library Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Thomas Wouters (twouters) Summary: os.nice() return 0 under Linux Initial Comment: os.nice() return 0 under Linux while docs say it should return ''niceness'' value ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-11 08:07 Message: Logged In: YES user_id=34209 Fixed in 2.2 and 2.1.1. configure.in revisions 1.226 1.215.2.3, configure 1.218 and 1.207.2.3, config.h.in 2.99 and 2.91.2.3, posixmodule.c 2.191 and 2.187.2.2. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-10 02:36 Message: Logged In: YES user_id=34209 Submitted a fix, SF patch #439995. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439990&group_id=5470 From noreply@sourceforge.net Wed Jul 11 19:13:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 11:13:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-440464 ] Threading Program Crashes Python 2.1 Message-ID: Bugs item #440464, was opened at 2001-07-11 11:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440464&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Threading Program Crashes Python 2.1 Initial Comment: import threading from time import time, ctime, sleep class MyClass(threading.Thread): def __init__(self, args): threading.Thread.__init__(self) self.args = args def run(self): while 1: print self.args def printText(self, foo): self.foo = foo print self.foo Biff = MyClass(4) Biff.start() Biff.printText("This is a string!") The above code crashes IDLE when run under NT4. The error message I get is this: 4Traceback (most recent call last): File "C:\Python21\Tools\idle\idle.pyw", line 2, in ? import idle File "C:\Python21\Tools\idle\idle.py", line 12, in ? PyShell.main() File "C:\Python21\Tools\idle\PyShell.py", line 777, in main root.mainloop() File "c:\python21\lib\lib-tk\Tkinter.py", line 930, in mainloop self.tk.mainloop(n) File "c:\python21\lib\lib-tk\Tkinter.py", line 1289, in __call__ self.widget._report_exception() File "c:\python21\lib\lib-tk\Tkinter.py", line 1061, in _report_exception root.report_callback_exception(exc, val, tb) File "c:\python21\lib\lib-tk\Tkinter.py", line 1541, in report_callback_exception sys.stderr.write("Exception in Tkinter callback\n") File "C:\Python21\Tools\idle\PyShell.py", line 676, in write self.shell.write(s, self.tags) File "C:\Python21\Tools\idle\PyShell.py", line 663, in write OutputWindow.write(self, s, tags, "iomark") File "C:\Python21\Tools\idle\OutputWindow.py", line 37, in write self.text.insert(mark, str(s), tags) File "C:\Python21\Tools\idle\Percolator.py", line 25, in insert self.top.insert(index, chars, tags) File "C:\Python21\Tools\idle\PyShell.py", line 143, in insert UndoDelegator.insert(self, index, chars, tags) File "C:\Python21\Tools\idle\UndoDelegator.py", line 81, in insert self.addcmd(InsertCommand(index, chars, tags)) File "C:\Python21\Tools\idle\UndoDelegator.py", line 116, in addcmd cmd.do(self.delegate) File "C:\Python21\Tools\idle\UndoDelegator.py", line 216, in do if text.compare(self.index1, ">", "end-1c"): File "c:\python21\lib\lib-tk\Tkinter.py", line 2626, in compare return self.tk.getboolean(self.tk.call( TclError: expected boolean value but got "" Hit return to exit... Sometimes IDLE just dies all together w/o displaying anything. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440464&group_id=5470 From noreply@sourceforge.net Wed Jul 11 19:16:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 11:16:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-440464 ] Threading Program Crashes Python 2.1 Message-ID: Bugs item #440464, was opened at 2001-07-11 11:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440464&group_id=5470 Category: IDLE Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Threading Program Crashes Python 2.1 Initial Comment: import threading from time import time, ctime, sleep class MyClass(threading.Thread): def __init__(self, args): threading.Thread.__init__(self) self.args = args def run(self): while 1: print self.args def printText(self, foo): self.foo = foo print self.foo Biff = MyClass(4) Biff.start() Biff.printText("This is a string!") The above code crashes IDLE when run under NT4. The error message I get is this: 4Traceback (most recent call last): File "C:\Python21\Tools\idle\idle.pyw", line 2, in ? import idle File "C:\Python21\Tools\idle\idle.py", line 12, in ? PyShell.main() File "C:\Python21\Tools\idle\PyShell.py", line 777, in main root.mainloop() File "c:\python21\lib\lib-tk\Tkinter.py", line 930, in mainloop self.tk.mainloop(n) File "c:\python21\lib\lib-tk\Tkinter.py", line 1289, in __call__ self.widget._report_exception() File "c:\python21\lib\lib-tk\Tkinter.py", line 1061, in _report_exception root.report_callback_exception(exc, val, tb) File "c:\python21\lib\lib-tk\Tkinter.py", line 1541, in report_callback_exception sys.stderr.write("Exception in Tkinter callback\n") File "C:\Python21\Tools\idle\PyShell.py", line 676, in write self.shell.write(s, self.tags) File "C:\Python21\Tools\idle\PyShell.py", line 663, in write OutputWindow.write(self, s, tags, "iomark") File "C:\Python21\Tools\idle\OutputWindow.py", line 37, in write self.text.insert(mark, str(s), tags) File "C:\Python21\Tools\idle\Percolator.py", line 25, in insert self.top.insert(index, chars, tags) File "C:\Python21\Tools\idle\PyShell.py", line 143, in insert UndoDelegator.insert(self, index, chars, tags) File "C:\Python21\Tools\idle\UndoDelegator.py", line 81, in insert self.addcmd(InsertCommand(index, chars, tags)) File "C:\Python21\Tools\idle\UndoDelegator.py", line 116, in addcmd cmd.do(self.delegate) File "C:\Python21\Tools\idle\UndoDelegator.py", line 216, in do if text.compare(self.index1, ">", "end-1c"): File "c:\python21\lib\lib-tk\Tkinter.py", line 2626, in compare return self.tk.getboolean(self.tk.call( TclError: expected boolean value but got "" Hit return to exit... Sometimes IDLE just dies all together w/o displaying anything. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 11:16 Message: Logged In: YES user_id=6380 Alas, using threads and Tkinter together does not work, and since IDLE is Tkinter-based, you can't do much with threads in IDLE. Your example should work fine in the command-line interpreter. I'm closing this bug report since there's really nothing we can do about this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440464&group_id=5470 From noreply@sourceforge.net Wed Jul 11 19:22:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 11:22:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-440464 ] Threading Program Crashes Python 2.1 Message-ID: Bugs item #440464, was opened at 2001-07-11 11:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440464&group_id=5470 Category: IDLE Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Threading Program Crashes Python 2.1 Initial Comment: import threading from time import time, ctime, sleep class MyClass(threading.Thread): def __init__(self, args): threading.Thread.__init__(self) self.args = args def run(self): while 1: print self.args def printText(self, foo): self.foo = foo print self.foo Biff = MyClass(4) Biff.start() Biff.printText("This is a string!") The above code crashes IDLE when run under NT4. The error message I get is this: 4Traceback (most recent call last): File "C:\Python21\Tools\idle\idle.pyw", line 2, in ? import idle File "C:\Python21\Tools\idle\idle.py", line 12, in ? PyShell.main() File "C:\Python21\Tools\idle\PyShell.py", line 777, in main root.mainloop() File "c:\python21\lib\lib-tk\Tkinter.py", line 930, in mainloop self.tk.mainloop(n) File "c:\python21\lib\lib-tk\Tkinter.py", line 1289, in __call__ self.widget._report_exception() File "c:\python21\lib\lib-tk\Tkinter.py", line 1061, in _report_exception root.report_callback_exception(exc, val, tb) File "c:\python21\lib\lib-tk\Tkinter.py", line 1541, in report_callback_exception sys.stderr.write("Exception in Tkinter callback\n") File "C:\Python21\Tools\idle\PyShell.py", line 676, in write self.shell.write(s, self.tags) File "C:\Python21\Tools\idle\PyShell.py", line 663, in write OutputWindow.write(self, s, tags, "iomark") File "C:\Python21\Tools\idle\OutputWindow.py", line 37, in write self.text.insert(mark, str(s), tags) File "C:\Python21\Tools\idle\Percolator.py", line 25, in insert self.top.insert(index, chars, tags) File "C:\Python21\Tools\idle\PyShell.py", line 143, in insert UndoDelegator.insert(self, index, chars, tags) File "C:\Python21\Tools\idle\UndoDelegator.py", line 81, in insert self.addcmd(InsertCommand(index, chars, tags)) File "C:\Python21\Tools\idle\UndoDelegator.py", line 116, in addcmd cmd.do(self.delegate) File "C:\Python21\Tools\idle\UndoDelegator.py", line 216, in do if text.compare(self.index1, ">", "end-1c"): File "c:\python21\lib\lib-tk\Tkinter.py", line 2626, in compare return self.tk.getboolean(self.tk.call( TclError: expected boolean value but got "" Hit return to exit... Sometimes IDLE just dies all together w/o displaying anything. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-11 11:22 Message: Logged In: YES user_id=31435 Just adding that you *can* use threads w/ Tkinter apps, provided that you ensure "the main thread" is the only one that ever calls into Tk or gets called back from it. So do your GUI (incl. console output: no "print"-to-window in threads!) stuff in the main thread exclusively. I gave an example of this on c.l.py within the last month, using a Queue to communicate window-output requests from worker threads to the main thread. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 11:16 Message: Logged In: YES user_id=6380 Alas, using threads and Tkinter together does not work, and since IDLE is Tkinter-based, you can't do much with threads in IDLE. Your example should work fine in the command-line interpreter. I'm closing this bug report since there's really nothing we can do about this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440464&group_id=5470 From noreply@sourceforge.net Wed Jul 11 19:26:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 11:26:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-439823 ] poll docs should mention timeout unit Message-ID: Bugs item #439823, was opened at 2001-07-09 13:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439823&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: A.M. Kuchling (akuchling) Summary: poll docs should mention timeout unit Initial Comment: the documentation about polling objects does not seem to mention what unit the timeout is specified in. it is especially important because it is in milliseconds whereas select.select and time.time use seconds. maybe it should be in bold. -- erno@iki.fi ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-11 11:26 Message: Logged In: YES user_id=3066 Assigned to Andrew since he's familiar with poll() and the Python interface to it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439823&group_id=5470 From noreply@sourceforge.net Wed Jul 11 19:29:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 11:29:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-439823 ] poll docs should mention timeout unit Message-ID: Bugs item #439823, was opened at 2001-07-09 13:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439823&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: poll docs should mention timeout unit Initial Comment: the documentation about polling objects does not seem to mention what unit the timeout is specified in. it is especially important because it is in milliseconds whereas select.select and time.time use seconds. maybe it should be in bold. -- erno@iki.fi ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 11:29 Message: Logged In: YES user_id=6380 Fred, it *is* in milliseconds, and you can update the docs yourself. ;-) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-11 11:26 Message: Logged In: YES user_id=3066 Assigned to Andrew since he's familiar with poll() and the Python interface to it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439823&group_id=5470 From noreply@sourceforge.net Wed Jul 11 19:29:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 11:29:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-416901 ] 2.1 on OpenBSD 2.8: lots of bugs @ build Message-ID: Bugs item #416901, was opened at 2001-04-17 17:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416901&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brad Allen (valaulmo) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: 2.1 on OpenBSD 2.8: lots of bugs @ build Initial Comment: I am doing a survey of current distributed information systems, to see if they are close to what they should be (I figured out what they should be in 1984), and am forced to find a Python which Mojo Nation is compatible with. I will probably go back to Python 2.0, but since the latest released version (released today!) was 2.1, I just started there (since the stable one for OpenBSD 2.8 was way back at Python 1.6 and I figured anything past that was experimenting anyway). --- Python 2.1 on OpenBSD 2.8 with Pentium I: I'm getting these warnings while compiling Python 2.1 on OpenBSD 2.8: cc -o python \ Modules/python.o \ libpython2.1.a -lc_r -lutil -L/usr/local/lib -lz -lm ./Modules/posixmodule.c:2995: warning: this program uses setreuid(), which is deprecated. ./Modules/posixmodule.c:3014: warning: this program uses setregid(), which is deprecated. ./Modules/posixmodule.c:4147: warning: tempnam() possibly used unsafely; consider using mkstemp() ./Modules/posixmodule.c:4193: warning: tmpnam() possibly used unsafely; consider using mkstemp() ld: libpython2.1.a(fileobject.o): RRS text relocation at 0x31168 for "_flockfile" ld: libpython2.1.a(fileobject.o): RRS text relocation at 0x311af for "_funlockfile" PYTHONPATH= ./python ./setup.py build running build Please consider fixing those things. --- *** HUNG test_bufio.py When running tests as "MAKE=gmake gmake test", it hung under test_bufio. It required a SIGKILL to stop. I tried two things: * Running test as README says manually with "python ...". python ./Lib/test/test_bufio.py This worked OK and produced no output that I was aware of (unless it was hidden). * Tried defining DONT_USE_FGETS_IN_GETLINE in the file where it was looked at (./Objects/fileobject.c). This did not help; it still hung. Running the test manually again at this point worked also. So, I had to find a way to skip that test (hid it in a subdirectory called HIDE). *** HUNG test_complex.py The same thing happened with test_complex.py: it hung during "...make test", but ran OK manually; then I hid it to skip. For test_dl, I got slightly different results; after the usual hanging, I then manually ran it and got: *** HUNG test_dl.py* Q:/usr/local/src/python/Python-2.1:2148$ python Lib/test/test_dl.py Traceback (most recent call last): File "Lib/test/test_dl.py", line 6, in ? import dl ImportError: No module named dl Q:/usr/local/src/python/Python-2.1:2149$ In each case, lots of CPU by the "python" process was used as its "hung" state. I waited approximately three minutes of CPU. A 133Megahertz Pentium with a CPU cache on a Dell computer is extremely fast, and ought to finish any test within two minutes. Tell me if I just failed to wait long enough for an increadibly inefficiently programmed test to complete, and I'll retry it. The fact that it did not respond to signals except KILL also indicates to me that it was comotose. (This discussion reminds me of a date where the person told me that the commands in Unix are very violent sounding and the names of the principles used by programmers are very anti-social. I'm glad someone thinks that way, since English itself is far, far worse, according to http://www.islandnet.com/~edonon/decoding.htm, and I said to myself "how can anybody use this language?" in disgust. Someday we'll fix that, too (and not just for historical politeness; for pureness of utility and efficiency -- snowballed efficiency!).) --- *** MEMORY FAULT test_fork1.py While the tests were running "test_fork1", I got a Memory Fault. Rerunning it manually worked, though, and I hid it also. (I did not test rerunning it.) While waiting for all these tests to hang, I got tired of it and now I want to request that you have all the tests run in parallel. That way, it is easier to weed out all the hanging ones in one shot. This is easy, right? *** HUNG test_compile.py Next to hang was this one: $ python ./Lib/test/test_compile.py Running tests on argument handling testing complex args 1 2 1 2 3 4 1 2 3 1 2 3 2 3 4 $ As you can see, it ran OK manually, and this time I had some output to look at. While looking at it I realized that I do not know if those are the expected results, and in the house I'm in, I have to listen to too much hollaring to be able to learn Python in a few minutes like I am usually able to do in proper environments. *** HUNG test_doctest.py test_doctest.py passed manually but automatically hung, too. It had too much output to include it all, but the last line said the test passed. *** HUNG & SEGFAULT test_threadedtempfile.py For test_threadedtempfile, I got a bad error: $ python Lib/test/test_threadedtempfile.py Creating Starting Reaping Segmentation fault (core dumped) $ rm *core $ python Lib/test/test_threadedtempfile.py Creating Starting Reaping ^C^C^C^Z ^Z^X^C Killed $ $ jobs [1]- Stopped less README [2]+ Stopped MAKE=gmake gmake test $ sync $ rm Lib/test/test_threadedt So far, a few tests ran better the second time than the first. Is the compiling working better than the interpreting? --- Brad Allen * ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-11 11:29 Message: Logged In: YES user_id=3066 The warnings are irrelevant -- any package that wraps those functions to make them available to applications will cause those warnings on OpenBSD, even if they are never used. The other issues require more attention than I can spare this week, so I'll leave this open. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416901&group_id=5470 From noreply@sourceforge.net Wed Jul 11 19:33:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 11:33:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-434479 ] os.listdir loses on linux w/NTFS vols Message-ID: Bugs item #434479, was opened at 2001-06-19 07:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434479&group_id=5470 Category: Python Library >Group: Irreproducible >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: jeremy bornstein (ukekuma) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: os.listdir loses on linux w/NTFS vols Initial Comment: os.listdir() on a directory which is on an NTFS volume omits one entry from the directory listing. Example: planet {188}: grep ntfs /etc/fstab /dev/hda1 /lose ntfs uid=500,gid=500,umask=555 1 2 planet {189}: ls /lose Documents and Settings/ My Music/ Program Files/ PUTTY.RND $Secure unzipped/ WINNT/ planet {190}: python2.1 Python 2.1 (#1, Jun 19 2001, 00:32:28) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import os >>> os.listdir('/lose') ['$Secure', 'Documents and Settings', 'My Music', 'Program Files', 'PUTTY.RND', 'unzipped'] >>> planet {191}: (In the example, note that the directory 'WINNT' is not returned by os.listdir.) I have verified this bug with/1.5.2, 1.6.1, and 2.1 on Linux (RH7.1) only. I have only tested it on this one NTFS volume and this one computer. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-11 11:33 Message: Logged In: YES user_id=3066 I was not able to reproduce this on my system (Mandrake 7.2, Linux 2.2.17). This may be a difference in configuration: I have an NTFS partition, but it's not the one that contains my \WINNT directory. If \WINNT is special in some way, I can't reproduce that. See also Martin's comment; he's likely to know exactly what he's talking about. I'm going to close this as irreproducible, acknowledging that it might really be a third-party bug. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 23:54 Message: Logged In: YES user_id=3066 Assigning this to me since I have a similar setup. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-23 12:45 Message: Logged In: YES user_id=21627 This is likely a bug in the NTFS driver, not in Python. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434479&group_id=5470 From noreply@sourceforge.net Wed Jul 11 19:49:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 11:49:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-439823 ] poll docs should mention timeout unit Message-ID: Bugs item #439823, was opened at 2001-07-09 13:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439823&group_id=5470 Category: Documentation Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: poll docs should mention timeout unit Initial Comment: the documentation about polling objects does not seem to mention what unit the timeout is specified in. it is especially important because it is in milliseconds whereas select.select and time.time use seconds. maybe it should be in bold. -- erno@iki.fi ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-11 11:49 Message: Logged In: YES user_id=3066 Ok, ok, I've read the manpage and the code now. Fixed in Doc/lib/libselect.tex revisions 1.18 and 1.17.4.1. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 11:29 Message: Logged In: YES user_id=6380 Fred, it *is* in milliseconds, and you can update the docs yourself. ;-) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-11 11:26 Message: Logged In: YES user_id=3066 Assigned to Andrew since he's familiar with poll() and the Python interface to it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439823&group_id=5470 From noreply@sourceforge.net Wed Jul 11 20:22:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 12:22:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-438050 ] configure doesn't look for poll.h in sys Message-ID: Bugs item #438050, was opened at 2001-07-02 15:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438050&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: David Dyck (dcd) Assigned to: A.M. Kuchling (akuchling) Summary: configure doesn't look for poll.h in sys Initial Comment: I was surprised to see python not build out of the box on this old libc5 system. seems to be a problem with configure finding poll.h If I manually add #include to "Modules/selectmodule.c" then make continues (Another workaround is to create a dummy /usr/include/poll.h that just #include's ) dd:dcd$ uname -a Linux dd 2.4.5-ac22 #2 Fri Jun 29 14:39:29 PDT 2001 i686 /lib/libc.so.5 -> libc.so.5.4.44* make[1]: Entering directory `/hdb2/jd/usr2/dcd/ftp2/python/Python-2.0.1/Modules' gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -I./../Include -I.. -DHAVE_CONFIG_H ./selectmodule.c: In function `update_ufd_array': ./selectmodule.c:319: sizeof applied to an incomplete type ./selectmodule.c:327: arithmetic on pointer to an incomplete type ./selectmodule.c:327: dereferencing pointer to incomplete type configure:1557: checking for poll.h configure:1567: gcc -E conftest.c >/dev/null 2>conftest.out configure:1563: poll.h: No such file or directory configure: failed program was: #line 1562 "configure" #include "confdefs.h" #include ---- ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-07-11 12:22 Message: Logged In: YES user_id=11375 OK. I've attached a patch to this bug that checks for sys/poll.h; can you please try it and let me know if it fixes the problem for you? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438050&group_id=5470 From noreply@sourceforge.net Wed Jul 11 20:25:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 12:25:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-440486 ] IPv6-related definitions always present Message-ID: Bugs item #440486, was opened at 2001-07-11 12:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440486&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Martin v. Löwis (loewis) Summary: IPv6-related definitions always present Initial Comment: Compiling Python today, I noticed that there are two new -D options: gcc -c -g -O3 -Wall -Wstrict-prototypes -Dss_family=__ss_family -Dss_len=__ss_len ... configure.in seems to always add them to OPT; is this necessary? Should they only be added if --enable-ipv6 is supplied, or moved into an appropriate .h file? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440486&group_id=5470 From noreply@sourceforge.net Wed Jul 11 20:28:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 12:28:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-432497 ] curses module doesn't build on HP-UX Message-ID: Bugs item #432497, was opened at 2001-06-12 11:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432497&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: A.M. Kuchling (akuchling) Summary: curses module doesn't build on HP-UX Initial Comment: The curses module does not build on HP-UX 11.00 (don't know about other versions). The reason according to Peter Stoldt (peter_stoldt@hp.com) who provided the fix below is to look for the curses header file in a different directory. Here is his fix: In py_curses.h exchange the line with #include with #include This would have to be done in a platform specific way of course. Perhaps all it takes is adding the curses_colr/ dir to the compiler call as -I option... not sure. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-07-11 12:28 Message: Logged In: YES user_id=11375 It seems reasonable to check for that directory in the configure script, and use it if present. I'll do that. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432497&group_id=5470 From noreply@sourceforge.net Wed Jul 11 21:09:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 13:09:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-437487 ] 2.1 build on Solaris fails if CC is set Message-ID: Bugs item #437487, was opened at 2001-06-29 15:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437487&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: A.M. Kuchling (akuchling) Summary: 2.1 build on Solaris fails if CC is set Initial Comment: If you have CC set to "gcc", then the "setup.py" script compiles the extensions incorrectly (in particular, the "-fPIC" on the compile is not used): ... PYTHONPATH= ./python ./setup.py build running build running build_ext building 'struct' extension creating build creating build/temp.solaris-2.7-sun4u-2.1 gcc -I. -I/extra/Python-2.1/./Include -I/usr/local/include -IInclude/ -c /extra/Python-2.1/Modules/structmodule.c -o build/temp.solaris-2.7-sun4u-2.1/structmodule.o creating build/lib.solaris-2.7-sun4u-2.1 gcc -shared build/temp.solaris-2.7-sun4u-2.1/structmodule.o -L/usr/local/lib -o build/lib.solaris-2.7-sun4u-2.1/struct.so Text relocation remains referenced against symbol offset in file 0x2094 build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x200c build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x3398 build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x2098 build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x2070 build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x206c .... If you want to compile code configured via "configure" with the "gcc" compiler and you have both the "gcc" and the Sun C compiler installed on your system, then you need to have the environment variable "CC" set to "gcc": CC=gcc So people (like myself) have "CC=gcc" in their .profile or equivalent in .login, and have had that for years without thinking about it. If you don't have "CC=gcc" set in your environment, then things work fine: ... PYTHONPATH= ./python ./setup.py build running build running build_ext building 'struct' extension creating build creating build/temp.solaris-2.7-sun4u-2.1 gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -I. -I/home/tflagg/projects/python/2.1sunos/Python-2.1/./Include -I/usr/local/include -IInclude/ -c /home/tflagg/projects/python/2.1sunos/Python-2.1/Modules/structmodule.c -o build/temp.solaris-2.7-sun4u-2.1/structmodule.o (In particular, the "-fPIC" flag needs to be there as shown above.) The problem lines in "setup.py" are: 112 # When you run "make CC=altcc" or something similar, you really want 113 # those environment variables passed into the setup.py phase. Here's 114 # a small set of useful ones. 115 compiler = os.environ.get('CC') <---------- 116 linker_so = os.environ.get('LDSHARED') 117 args = {} 118 # unfortunately, distutils doesn't let us provide separate C and C++ 119 # compilers 120 if compiler is not None: <--------------- 121 args['compiler_so'] = compiler <--------- It's true the user may want to set site-specific/user-specific compiler options. However, if "CC" is only "gcc" then the user is trying to communicate: - Use "gcc" rather than Sun's C compiler They are NOT trying to communicate: - Do not use any of the compiler flags for compiling shared objects. The reason this bug Solaris-specific is because Solaris installations are the most likely to have a non-gcc compiler installed, requiring the "CC=gcc" environment variable set. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-07-11 13:09 Message: Logged In: YES user_id=11375 Proposed patch attached; if the original poster is monitoring this bug, please try it and let me know if it helps. Otherwise, I'll check it in in a few days. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437487&group_id=5470 From noreply@sourceforge.net Wed Jul 11 21:16:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 13:16:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-440497 ] nested function with variables Message-ID: Bugs item #440497, was opened at 2001-07-11 13:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440497&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: nested function with variables Initial Comment: This code should not result in a syntax warning: def t0(): from math import * def t1(): print map(lambda x:x,[]) def t2(): print None SyntaxWarning: import * is not allowed in function 't0' because it contains a nested function with free variables Moving the function body one level out results in no warnings, removing the import as well. But the warnings persist for both t1 and t2 by itself. I have been trying to port my code to Python-2.1 (from 2.0) and encountered numerous problems due with SyntaxWarnings regarding the new scoping rules that I found way too confusing to be able to track it for my large code. These syntax warnings should be one of the major functions of 2.1 since they should help the migration to 2.2 with the new scoping enabled ...... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440497&group_id=5470 From noreply@sourceforge.net Wed Jul 11 21:24:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 13:24:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-440497 ] nested function with variables Message-ID: Bugs item #440497, was opened at 2001-07-11 13:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440497&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: nested function with variables Initial Comment: This code should not result in a syntax warning: def t0(): from math import * def t1(): print map(lambda x:x,[]) def t2(): print None SyntaxWarning: import * is not allowed in function 't0' because it contains a nested function with free variables Moving the function body one level out results in no warnings, removing the import as well. But the warnings persist for both t1 and t2 by itself. I have been trying to port my code to Python-2.1 (from 2.0) and encountered numerous problems due with SyntaxWarnings regarding the new scoping rules that I found way too confusing to be able to track it for my large code. These syntax warnings should be one of the major functions of 2.1 since they should help the migration to 2.2 with the new scoping enabled ...... ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 13:24 Message: Logged In: YES user_id=6380 You get the warning because the compiler doesn't know whether the math module exports objects named 'map' or 'None'. (This may be obvious to you, but the compiler isn't clairvoyant, and it can't go and import the module while it's compiling another module.) There are several ways to avoid the warning: 1) Move the import to the module level. (Why are you putting the import in the function? It's slower that way.) 2) Be specific about the functions you import, e.g. write from math import sin, cos, tan 3) Use "import math" and write "math.sin(x)" etc. rathern than "sin(x)". Your example doesn't show why you would write such code. Perhaps showing some real code that you use that runs into this problem can give a better insight in how to deal with your porting problem... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440497&group_id=5470 From noreply@sourceforge.net Wed Jul 11 21:24:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 13:24:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-440497 ] nested function with variables Message-ID: Bugs item #440497, was opened at 2001-07-11 13:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440497&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: nested function with variables Initial Comment: This code should not result in a syntax warning: def t0(): from math import * def t1(): print map(lambda x:x,[]) def t2(): print None SyntaxWarning: import * is not allowed in function 't0' because it contains a nested function with free variables Moving the function body one level out results in no warnings, removing the import as well. But the warnings persist for both t1 and t2 by itself. I have been trying to port my code to Python-2.1 (from 2.0) and encountered numerous problems due with SyntaxWarnings regarding the new scoping rules that I found way too confusing to be able to track it for my large code. These syntax warnings should be one of the major functions of 2.1 since they should help the migration to 2.2 with the new scoping enabled ...... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-07-11 13:24 Message: Logged In: YES user_id=6656 Consider what happens if math.py defines the name "None". It doesn't, and it won't ever, but there's nothing special about the name "None" to Python. Writing your second function as "def t2(): pass" should clear up the warnings (not checked as I don't have Python 2.1 on the box I'm posting from). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 13:24 Message: Logged In: YES user_id=6380 You get the warning because the compiler doesn't know whether the math module exports objects named 'map' or 'None'. (This may be obvious to you, but the compiler isn't clairvoyant, and it can't go and import the module while it's compiling another module.) There are several ways to avoid the warning: 1) Move the import to the module level. (Why are you putting the import in the function? It's slower that way.) 2) Be specific about the functions you import, e.g. write from math import sin, cos, tan 3) Use "import math" and write "math.sin(x)" etc. rathern than "sin(x)". Your example doesn't show why you would write such code. Perhaps showing some real code that you use that runs into this problem can give a better insight in how to deal with your porting problem... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440497&group_id=5470 From noreply@sourceforge.net Wed Jul 11 21:24:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 13:24:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-440497 ] nested function with variables Message-ID: Bugs item #440497, was opened at 2001-07-11 13:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440497&group_id=5470 >Category: Parser/Compiler Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: nested function with variables Initial Comment: This code should not result in a syntax warning: def t0(): from math import * def t1(): print map(lambda x:x,[]) def t2(): print None SyntaxWarning: import * is not allowed in function 't0' because it contains a nested function with free variables Moving the function body one level out results in no warnings, removing the import as well. But the warnings persist for both t1 and t2 by itself. I have been trying to port my code to Python-2.1 (from 2.0) and encountered numerous problems due with SyntaxWarnings regarding the new scoping rules that I found way too confusing to be able to track it for my large code. These syntax warnings should be one of the major functions of 2.1 since they should help the migration to 2.2 with the new scoping enabled ...... ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 13:24 Message: Logged In: YES user_id=6380 Closing this report since it's not a bug. (You can still add comments.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-07-11 13:24 Message: Logged In: YES user_id=6656 Consider what happens if math.py defines the name "None". It doesn't, and it won't ever, but there's nothing special about the name "None" to Python. Writing your second function as "def t2(): pass" should clear up the warnings (not checked as I don't have Python 2.1 on the box I'm posting from). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 13:24 Message: Logged In: YES user_id=6380 You get the warning because the compiler doesn't know whether the math module exports objects named 'map' or 'None'. (This may be obvious to you, but the compiler isn't clairvoyant, and it can't go and import the module while it's compiling another module.) There are several ways to avoid the warning: 1) Move the import to the module level. (Why are you putting the import in the function? It's slower that way.) 2) Be specific about the functions you import, e.g. write from math import sin, cos, tan 3) Use "import math" and write "math.sin(x)" etc. rathern than "sin(x)". Your example doesn't show why you would write such code. Perhaps showing some real code that you use that runs into this problem can give a better insight in how to deal with your porting problem... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440497&group_id=5470 From noreply@sourceforge.net Wed Jul 11 21:42:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 13:42:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-440037 ] Extending: need import examples Message-ID: Bugs item #440037, was opened at 2001-07-10 06:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440037&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: Extending: need import examples Initial Comment: Hello, I have been writing a code generator to call functions in a Python script from C. The code seems to be working fine. In the process, I found some things in the C API manual that can be improved: - I would expect 7.4 (numeric objects) before 7.2 (sequence objects) - PyList_SetItem() does not specify return value (probably the same as PyTuple_SetItem() "It returns 0 on success.") - PyList_SET_ITEM() returns a borrowed reference without specifying to what it refers. - PyDict_SetItem() doesnot use 'p' in the description (same for PyDict_SetItemString()) - Return value of both functions is also not specified. - In PyLong_AsLong(), a stray 'OverflowError' is at the end of the description. - Also at PyLong_AsUnsignedLong() (next entry) What I found lacking in the embedding and extending manual is the importing of modules, and finding a function with a specific name from C. Is this something that should be included in the EE manual ? (I'd be willing to give it some thought) Also, I found 2 'problems' in the interface at code level. I will add this seperately to the bug report data base. Albert (a.t.hofkamp@tue.nl) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-11 13:42 Message: Logged In: YES user_id=3066 The recommended re-ordering of sections has been implemented in Doc/api/api.tex revisions 1.130 and 1.117.2.9. The change was included in the 2.1 maintenance branch since this is a readability bug. All that remains for this issue are the additions to the Extending & Embedding manual, so I'm changing the summary as well. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-10 09:14 Message: Logged In: YES user_id=3066 The corrections and additions to the API manual have been committed as Doc/api/api.tex revisions 1.129 and 1.117.2.8. Re-ordering of sections will be considered separately. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-10 09:06 Message: Logged In: NO Regarding the order of numeric and sequence objects: My idea is that numeric objects are easier to understand than sequence objects. So when browsing through the documentation (I know the docs are not supposed to be browsed, but before being able to work with it, one has to read the EE manual, and probably browse the API manual to get a feel for the API calls available), the interface for the numeric objects are relatively easy to understand. With that knowledge, the next sections become easier, because the api's for the other objects have a similar structure. Albert ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-10 08:23 Message: Logged In: YES user_id=3066 I don't understand the comment on the ordering of the Numeric and Sequence object sections; what is the motivation for changing the ordering? Regarding the issue of import & function lookup: Yes, the EE manual should cover this. Suggested text would be greatly appreciated (without markup is fine), or I can work on it when time permits. I've fixed the other issues in my working copy; these should be checked in before too long. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440037&group_id=5470 From noreply@sourceforge.net Wed Jul 11 22:19:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 14:19:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn Message-ID: Bugs item #417845, was opened at 2001-04-21 08:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: Python 2.1: SocketServer.ThreadingMixIn Initial Comment: SocketServer.ThreadingMixIn does not work properly since it tries to close the socket of a request two times. Workaround for using SocketServer.ThreadingMixIn under Python 2.1: class MyThreadingHTTPServer( SocketServer.ThreadingMixIn, MyHTTPServer ): def close_request(self, request): pass ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-07-11 14:19 Message: Logged In: YES user_id=7887 Just wondering, is this bug fixed somewhere (cvs, etc)?? Python 2.1 + SOAP.py seem to have this problem, when using the ThreadingTCPServer. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 06:59 Message: Logged In: YES user_id=6380 Yes, the thread is responsible for calling self.close_request() in self.finish_request(). (Although if you just rely on reference counting, it should go away all by itself too.) I don't read the newsgroup frequently, but you can try email if you have more problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-10 05:47 Message: Logged In: NO I tried the fix and it seems to work. I'm wondering if the thread is responsible for calling self.close_request() in self.finish_request? Note: Can we discuss it in news:comp.lang.python? I hate that web interface with Cookies! That's the reason why I was too lazy to login when submitting this bug report. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 04:59 Message: Logged In: YES user_id=6380 I've developed a proper fix for this, I hope. Check out the latest SocketServer.py from the CVS tree. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-07-02 09:05 Message: Logged In: YES user_id=198402 There is still a problem with your solution, Mr glchapman: you make a copy to ensure that the server won't close the copy of the socket that is used in the child thread. Right. But WHO will close this very copy then? The thread still has to close it if one wants to be "clean". So as long as the child thread must close its copy in the threading case, why not make it a thumb rule? Why should we bother about closing anything in the main thread? I still think the solution that I provide is best: make the request handler always responsible for closing the socket from which the request comes. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2001-06-29 08:49 Message: Logged In: YES user_id=86307 Since the request socket object is only a lightweight wrapper around the real socket, why not simply pass request.dup() to the new thread? Then the server's call to close_request affects only its copy of request, not the copy being used in the thread. For example, the following change to ThreadingMixIn fixed this bug for me in a (very simple) test program: def process_request(self, request, client_address): """Start a new thread to process the request.""" import threading t = threading.Thread(target = self.finish_request, args = (request.dup(), client_address)) t.start() ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-28 05:20 Message: Logged In: YES user_id=198402 I have now started a project here concerning a SOCKS proxy written in python (PySocks). It is aimed mostly at people who use a windows box to share their internet connection and uses the threading server from the SocketServer module. So it becomes VERY important to me to know of what will be done about this bug, in the next release/patch of Python library. Could Mr Guido Vanrossum tell us about it? As for now I am forced to provide my patched version of SocketServer.py with my releases, what is not quite satisfactory. SocketServer is provided in the python distribution, so I'd rather tell "there is a patch for python..." Well... In fact I forgot to put it in my first release, but I'll correct this this evening :) ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-20 12:06 Message: Logged In: YES user_id=198402 Well I was wrong. We do need a "try" block to ensure the request is always correctly closed: def finish_request(self, request, client_address): """Finish one request by instantiating RequestHandlerClass.""" try: self.RequestHandlerClass(request, client_address, self) finally: self.close_request(request) This works better. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-13 09:09 Message: Logged In: YES user_id=198402 I forgot to tell: I can not test if it does not break the forking server. I only have a windows platform available for now, and forking doesn't work in the python/win32 environment for now as far as I know. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-13 08:51 Message: Logged In: YES user_id=198402 What I propose can be applied without any compatibility issue. I have tried something that seems to work, at least under windows (but it does need to be more fully tested though). Only 2 small modifications are required: -1- In BaseServer, modification of the last line of handle_request: 
    def handle_request(self):
        """Handle one request, possibly blocking."""
        #import time
        try:
            request, client_address = self.get_request()
        except socket.error:
            return
        if self.verify_request(request, client_address):
            try:
                print 'handle 1'
                self.process_request(request, 
client_address)
                print 'handle 2'
            except:
                self.handle_error(request, client_address)
                self.close_request(request)
Note that only the indentation of the last has been modified so that the close_request is executed only if an exception occur. Still we need to close the request after it had been processed, so here comes the second modification: -2- Still in BaseServer: 
    def finish_request(self, request, client_address):
        """Finish one request by instantiating 
RequestHandlerClass."""
        self.RequestHandlerClass(request, client_address, 
self)
        self.close_request(request)
There is already a try/except block in handle_request, so I thought it was not mandatory here to ensure the request was always closed. Oh... I don't know how <PRE> tags are supported by the bugtracking system of sourceforge, so the samples I give may not appear as I want. This is quite a problem with python :/ ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-12 15:46 Message: Logged In: YES user_id=80200 hi there mr xlagraula, yes, it would be a lot simpler... _if_ it wasn't for the fact that this code is likely to already be quite extensively used. a possible 'upgrade' path could be done by providing a... RequestHandler2 class, or some-such. it would be neater to do this, or similar: for t in self.thread_list: t.join(timeout=0.1) which would join all threads, or you do if stopped(), close_request. i looked into threads a bit more: join has a timeout, and there is a stopped-detection function. easy :) ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-12 14:18 Message: Logged In: YES user_id=198402 Another solution could be to modify the behaviour of the server so that it would be the responsibility of the "child" thread/process to close the socket (except for the forking/threading error cases). Wouldn't it be simplier than child process tracking and thread tracking? ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-04 04:17 Message: Logged In: YES user_id=80200 okay. the forkingmixin code does a fork, records how many children there are, and waits for one of them to exit, before proceeding - in particular, before proceeding to close the request, etc. ... so why is not something similar done in ThreadingMixIn? this kinda- tells me that thread-tracking is really needed, in a similar way to that in forkingmixin. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2001-05-03 16:26 Message: Logged In: YES user_id=413 Just a note of another casualty of this bug: I had to add the mentioned dummy close_request method hack to our own ThreadingMixIn class in mojo nation (in the sourceforge mojonation project's evil module, see the common/MojoNationHTTPServer.py file). Without it, python 2.1 would always raise an exception in the request handler as soon as it tried to call self.connection.makefile() because self.connection had apparently already been closed! (its fd was always -1) ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-02 01:41 Message: Logged In: YES user_id=80200 hi there mr jrielh, thank you very much for the details. what i am having a little difficulty with is, what's the difference between this and python 2.0 SocketServer.py? more specifically, i'm looking at python 2.0 SocketServer.py and, whilst i'm not a Threads expert, i see a t.start() but no t.join(). i've been looking at the Queue example code in the test method of threads.py, and start() is called on every thread, followed by join() on every thread. join waits for the thread to finish, yes? so... if that's the case, then python 2.0 SocketServer.py should suffer from exactly the same behaviour, yes? unless python behaves ever-so-slightly differently (timing issues?) when you have an extra base class like this, with the consequence that close_request() is more likely to be called before ThreadingMixIn.process_request(). ? ---------------------------------------------------------------------- Comment By: Jon Riehl (jriehl) Date: 2001-05-01 14:20 Message: Logged In: YES user_id=22448 This is related to bug #419873. The problem is not specifically in the ThreadingMixin specifically, but where BaseServer calls close_request() after calling process_request(). In the threading mixin, process_request() spins the thread and returns, causing the request socket to be invalidated while the thread is still running. The fix given above will keep the socket valid while the thread is running, but may cause the socket to not close properly (my threads generally close the socket when they are done anyway.) ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-04-26 05:41 Message: Logged In: YES user_id=80200 follow-up. i took a look at the differences between SocketServer.py in 2.0 and 2.1. there is one small change by guido to the ThreadingMixIn.process_request() function that calls self.server_close() instead of explicitly calling self.socket.close(), where TCPServer.server_close() calls self.socket.close(). if mr anonymous (hi!) has over-ridden server_close() and explicitly closes the *request* socket, then of course the socket will get closed twice. the rest of the code-mods is a straightforward code-shuffle moving code from TCPServer into BaseServer: from examining the diff, i really don't see how bypassing close_request(), as shown above with the Workaround in the original bug-report, will help: that will in fact cause the request _never_ to be closed! the rest of this report is part of an email exchange with guido, quoted here: "the bug-report doesn't state whether python 2.0 worked and 2.1 didn't: it also doesn't give enough info. for all we know, he's calling close_request() himself or request.close() directly somewhere in his code, and hasn't told anybody, which is why he has to over-ride close_request() and tell it to do nothing. or he's closing the socket in the HandlerClass, in finish(), or something. we just don't know. either that, or his HandlerClass creates a socket once and only once, with the result that close_request() closes the one socket, and he's _completely_ stuffed, then :)" ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-04-26 04:11 Message: Logged In: YES user_id=80200 hi there, i'm the person who wrote the BaseServer class. guido contacted me about it: could you please send me or post here a working test example that demonstrates the problem. i assume, but you do not state, that you have tested your MyHTTPServer with python 2.0, please let us know, here, if that is a correct assumption. thanks! luke ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470 From noreply@sourceforge.net Wed Jul 11 22:22:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 14:22:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn Message-ID: Bugs item #417845, was opened at 2001-04-21 08:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: Python 2.1: SocketServer.ThreadingMixIn Initial Comment: SocketServer.ThreadingMixIn does not work properly since it tries to close the socket of a request two times. Workaround for using SocketServer.ThreadingMixIn under Python 2.1: class MyThreadingHTTPServer( SocketServer.ThreadingMixIn, MyHTTPServer ): def close_request(self, request): pass ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 14:22 Message: Logged In: YES user_id=6380 Gustavo, yes it's fixed in CVS (just read on and you;ll see my announcement). We're going to release a bugfix update release for Python 2.1, Python 2.1.1 soon, and it will be in that release too. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-07-11 14:19 Message: Logged In: YES user_id=7887 Just wondering, is this bug fixed somewhere (cvs, etc)?? Python 2.1 + SOAP.py seem to have this problem, when using the ThreadingTCPServer. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 06:59 Message: Logged In: YES user_id=6380 Yes, the thread is responsible for calling self.close_request() in self.finish_request(). (Although if you just rely on reference counting, it should go away all by itself too.) I don't read the newsgroup frequently, but you can try email if you have more problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-10 05:47 Message: Logged In: NO I tried the fix and it seems to work. I'm wondering if the thread is responsible for calling self.close_request() in self.finish_request? Note: Can we discuss it in news:comp.lang.python? I hate that web interface with Cookies! That's the reason why I was too lazy to login when submitting this bug report. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 04:59 Message: Logged In: YES user_id=6380 I've developed a proper fix for this, I hope. Check out the latest SocketServer.py from the CVS tree. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-07-02 09:05 Message: Logged In: YES user_id=198402 There is still a problem with your solution, Mr glchapman: you make a copy to ensure that the server won't close the copy of the socket that is used in the child thread. Right. But WHO will close this very copy then? The thread still has to close it if one wants to be "clean". So as long as the child thread must close its copy in the threading case, why not make it a thumb rule? Why should we bother about closing anything in the main thread? I still think the solution that I provide is best: make the request handler always responsible for closing the socket from which the request comes. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2001-06-29 08:49 Message: Logged In: YES user_id=86307 Since the request socket object is only a lightweight wrapper around the real socket, why not simply pass request.dup() to the new thread? Then the server's call to close_request affects only its copy of request, not the copy being used in the thread. For example, the following change to ThreadingMixIn fixed this bug for me in a (very simple) test program: def process_request(self, request, client_address): """Start a new thread to process the request.""" import threading t = threading.Thread(target = self.finish_request, args = (request.dup(), client_address)) t.start() ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-28 05:20 Message: Logged In: YES user_id=198402 I have now started a project here concerning a SOCKS proxy written in python (PySocks). It is aimed mostly at people who use a windows box to share their internet connection and uses the threading server from the SocketServer module. So it becomes VERY important to me to know of what will be done about this bug, in the next release/patch of Python library. Could Mr Guido Vanrossum tell us about it? As for now I am forced to provide my patched version of SocketServer.py with my releases, what is not quite satisfactory. SocketServer is provided in the python distribution, so I'd rather tell "there is a patch for python..." Well... In fact I forgot to put it in my first release, but I'll correct this this evening :) ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-20 12:06 Message: Logged In: YES user_id=198402 Well I was wrong. We do need a "try" block to ensure the request is always correctly closed: def finish_request(self, request, client_address): """Finish one request by instantiating RequestHandlerClass.""" try: self.RequestHandlerClass(request, client_address, self) finally: self.close_request(request) This works better. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-13 09:09 Message: Logged In: YES user_id=198402 I forgot to tell: I can not test if it does not break the forking server. I only have a windows platform available for now, and forking doesn't work in the python/win32 environment for now as far as I know. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-13 08:51 Message: Logged In: YES user_id=198402 What I propose can be applied without any compatibility issue. I have tried something that seems to work, at least under windows (but it does need to be more fully tested though). Only 2 small modifications are required: -1- In BaseServer, modification of the last line of handle_request: 
    def handle_request(self):
        """Handle one request, possibly blocking."""
        #import time
        try:
            request, client_address = self.get_request()
        except socket.error:
            return
        if self.verify_request(request, client_address):
            try:
                print 'handle 1'
                self.process_request(request, 
client_address)
                print 'handle 2'
            except:
                self.handle_error(request, client_address)
                self.close_request(request)
Note that only the indentation of the last has been modified so that the close_request is executed only if an exception occur. Still we need to close the request after it had been processed, so here comes the second modification: -2- Still in BaseServer: 
    def finish_request(self, request, client_address):
        """Finish one request by instantiating 
RequestHandlerClass."""
        self.RequestHandlerClass(request, client_address, 
self)
        self.close_request(request)
There is already a try/except block in handle_request, so I thought it was not mandatory here to ensure the request was always closed. Oh... I don't know how <PRE> tags are supported by the bugtracking system of sourceforge, so the samples I give may not appear as I want. This is quite a problem with python :/ ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-12 15:46 Message: Logged In: YES user_id=80200 hi there mr xlagraula, yes, it would be a lot simpler... _if_ it wasn't for the fact that this code is likely to already be quite extensively used. a possible 'upgrade' path could be done by providing a... RequestHandler2 class, or some-such. it would be neater to do this, or similar: for t in self.thread_list: t.join(timeout=0.1) which would join all threads, or you do if stopped(), close_request. i looked into threads a bit more: join has a timeout, and there is a stopped-detection function. easy :) ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-12 14:18 Message: Logged In: YES user_id=198402 Another solution could be to modify the behaviour of the server so that it would be the responsibility of the "child" thread/process to close the socket (except for the forking/threading error cases). Wouldn't it be simplier than child process tracking and thread tracking? ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-04 04:17 Message: Logged In: YES user_id=80200 okay. the forkingmixin code does a fork, records how many children there are, and waits for one of them to exit, before proceeding - in particular, before proceeding to close the request, etc. ... so why is not something similar done in ThreadingMixIn? this kinda- tells me that thread-tracking is really needed, in a similar way to that in forkingmixin. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2001-05-03 16:26 Message: Logged In: YES user_id=413 Just a note of another casualty of this bug: I had to add the mentioned dummy close_request method hack to our own ThreadingMixIn class in mojo nation (in the sourceforge mojonation project's evil module, see the common/MojoNationHTTPServer.py file). Without it, python 2.1 would always raise an exception in the request handler as soon as it tried to call self.connection.makefile() because self.connection had apparently already been closed! (its fd was always -1) ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-02 01:41 Message: Logged In: YES user_id=80200 hi there mr jrielh, thank you very much for the details. what i am having a little difficulty with is, what's the difference between this and python 2.0 SocketServer.py? more specifically, i'm looking at python 2.0 SocketServer.py and, whilst i'm not a Threads expert, i see a t.start() but no t.join(). i've been looking at the Queue example code in the test method of threads.py, and start() is called on every thread, followed by join() on every thread. join waits for the thread to finish, yes? so... if that's the case, then python 2.0 SocketServer.py should suffer from exactly the same behaviour, yes? unless python behaves ever-so-slightly differently (timing issues?) when you have an extra base class like this, with the consequence that close_request() is more likely to be called before ThreadingMixIn.process_request(). ? ---------------------------------------------------------------------- Comment By: Jon Riehl (jriehl) Date: 2001-05-01 14:20 Message: Logged In: YES user_id=22448 This is related to bug #419873. The problem is not specifically in the ThreadingMixin specifically, but where BaseServer calls close_request() after calling process_request(). In the threading mixin, process_request() spins the thread and returns, causing the request socket to be invalidated while the thread is still running. The fix given above will keep the socket valid while the thread is running, but may cause the socket to not close properly (my threads generally close the socket when they are done anyway.) ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-04-26 05:41 Message: Logged In: YES user_id=80200 follow-up. i took a look at the differences between SocketServer.py in 2.0 and 2.1. there is one small change by guido to the ThreadingMixIn.process_request() function that calls self.server_close() instead of explicitly calling self.socket.close(), where TCPServer.server_close() calls self.socket.close(). if mr anonymous (hi!) has over-ridden server_close() and explicitly closes the *request* socket, then of course the socket will get closed twice. the rest of the code-mods is a straightforward code-shuffle moving code from TCPServer into BaseServer: from examining the diff, i really don't see how bypassing close_request(), as shown above with the Workaround in the original bug-report, will help: that will in fact cause the request _never_ to be closed! the rest of this report is part of an email exchange with guido, quoted here: "the bug-report doesn't state whether python 2.0 worked and 2.1 didn't: it also doesn't give enough info. for all we know, he's calling close_request() himself or request.close() directly somewhere in his code, and hasn't told anybody, which is why he has to over-ride close_request() and tell it to do nothing. or he's closing the socket in the HandlerClass, in finish(), or something. we just don't know. either that, or his HandlerClass creates a socket once and only once, with the result that close_request() closes the one socket, and he's _completely_ stuffed, then :)" ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-04-26 04:11 Message: Logged In: YES user_id=80200 hi there, i'm the person who wrote the BaseServer class. guido contacted me about it: could you please send me or post here a working test example that demonstrates the problem. i assume, but you do not state, that you have tested your MyHTTPServer with python 2.0, please let us know, here, if that is a correct assumption. thanks! luke ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470 From noreply@sourceforge.net Wed Jul 11 22:45:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 14:45:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn Message-ID: Bugs item #417845, was opened at 2001-04-21 08:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: Python 2.1: SocketServer.ThreadingMixIn Initial Comment: SocketServer.ThreadingMixIn does not work properly since it tries to close the socket of a request two times. Workaround for using SocketServer.ThreadingMixIn under Python 2.1: class MyThreadingHTTPServer( SocketServer.ThreadingMixIn, MyHTTPServer ): def close_request(self, request): pass ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-07-11 14:45 Message: Logged In: YES user_id=7887 Ohh, I'm sorry. I've read comments the other way around. The last comment seemed to be the one at bottom (as usual), then it looked like it was not definetly fixed. I'll checkout the fix from cvs. Thanks! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 14:22 Message: Logged In: YES user_id=6380 Gustavo, yes it's fixed in CVS (just read on and you;ll see my announcement). We're going to release a bugfix update release for Python 2.1, Python 2.1.1 soon, and it will be in that release too. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-07-11 14:19 Message: Logged In: YES user_id=7887 Just wondering, is this bug fixed somewhere (cvs, etc)?? Python 2.1 + SOAP.py seem to have this problem, when using the ThreadingTCPServer. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 06:59 Message: Logged In: YES user_id=6380 Yes, the thread is responsible for calling self.close_request() in self.finish_request(). (Although if you just rely on reference counting, it should go away all by itself too.) I don't read the newsgroup frequently, but you can try email if you have more problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-10 05:47 Message: Logged In: NO I tried the fix and it seems to work. I'm wondering if the thread is responsible for calling self.close_request() in self.finish_request? Note: Can we discuss it in news:comp.lang.python? I hate that web interface with Cookies! That's the reason why I was too lazy to login when submitting this bug report. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 04:59 Message: Logged In: YES user_id=6380 I've developed a proper fix for this, I hope. Check out the latest SocketServer.py from the CVS tree. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-07-02 09:05 Message: Logged In: YES user_id=198402 There is still a problem with your solution, Mr glchapman: you make a copy to ensure that the server won't close the copy of the socket that is used in the child thread. Right. But WHO will close this very copy then? The thread still has to close it if one wants to be "clean". So as long as the child thread must close its copy in the threading case, why not make it a thumb rule? Why should we bother about closing anything in the main thread? I still think the solution that I provide is best: make the request handler always responsible for closing the socket from which the request comes. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2001-06-29 08:49 Message: Logged In: YES user_id=86307 Since the request socket object is only a lightweight wrapper around the real socket, why not simply pass request.dup() to the new thread? Then the server's call to close_request affects only its copy of request, not the copy being used in the thread. For example, the following change to ThreadingMixIn fixed this bug for me in a (very simple) test program: def process_request(self, request, client_address): """Start a new thread to process the request.""" import threading t = threading.Thread(target = self.finish_request, args = (request.dup(), client_address)) t.start() ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-28 05:20 Message: Logged In: YES user_id=198402 I have now started a project here concerning a SOCKS proxy written in python (PySocks). It is aimed mostly at people who use a windows box to share their internet connection and uses the threading server from the SocketServer module. So it becomes VERY important to me to know of what will be done about this bug, in the next release/patch of Python library. Could Mr Guido Vanrossum tell us about it? As for now I am forced to provide my patched version of SocketServer.py with my releases, what is not quite satisfactory. SocketServer is provided in the python distribution, so I'd rather tell "there is a patch for python..." Well... In fact I forgot to put it in my first release, but I'll correct this this evening :) ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-20 12:06 Message: Logged In: YES user_id=198402 Well I was wrong. We do need a "try" block to ensure the request is always correctly closed: def finish_request(self, request, client_address): """Finish one request by instantiating RequestHandlerClass.""" try: self.RequestHandlerClass(request, client_address, self) finally: self.close_request(request) This works better. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-13 09:09 Message: Logged In: YES user_id=198402 I forgot to tell: I can not test if it does not break the forking server. I only have a windows platform available for now, and forking doesn't work in the python/win32 environment for now as far as I know. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-13 08:51 Message: Logged In: YES user_id=198402 What I propose can be applied without any compatibility issue. I have tried something that seems to work, at least under windows (but it does need to be more fully tested though). Only 2 small modifications are required: -1- In BaseServer, modification of the last line of handle_request: 
    def handle_request(self):
        """Handle one request, possibly blocking."""
        #import time
        try:
            request, client_address = self.get_request()
        except socket.error:
            return
        if self.verify_request(request, client_address):
            try:
                print 'handle 1'
                self.process_request(request, 
client_address)
                print 'handle 2'
            except:
                self.handle_error(request, client_address)
                self.close_request(request)
Note that only the indentation of the last has been modified so that the close_request is executed only if an exception occur. Still we need to close the request after it had been processed, so here comes the second modification: -2- Still in BaseServer: 
    def finish_request(self, request, client_address):
        """Finish one request by instantiating 
RequestHandlerClass."""
        self.RequestHandlerClass(request, client_address, 
self)
        self.close_request(request)
There is already a try/except block in handle_request, so I thought it was not mandatory here to ensure the request was always closed. Oh... I don't know how <PRE> tags are supported by the bugtracking system of sourceforge, so the samples I give may not appear as I want. This is quite a problem with python :/ ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-12 15:46 Message: Logged In: YES user_id=80200 hi there mr xlagraula, yes, it would be a lot simpler... _if_ it wasn't for the fact that this code is likely to already be quite extensively used. a possible 'upgrade' path could be done by providing a... RequestHandler2 class, or some-such. it would be neater to do this, or similar: for t in self.thread_list: t.join(timeout=0.1) which would join all threads, or you do if stopped(), close_request. i looked into threads a bit more: join has a timeout, and there is a stopped-detection function. easy :) ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-12 14:18 Message: Logged In: YES user_id=198402 Another solution could be to modify the behaviour of the server so that it would be the responsibility of the "child" thread/process to close the socket (except for the forking/threading error cases). Wouldn't it be simplier than child process tracking and thread tracking? ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-04 04:17 Message: Logged In: YES user_id=80200 okay. the forkingmixin code does a fork, records how many children there are, and waits for one of them to exit, before proceeding - in particular, before proceeding to close the request, etc. ... so why is not something similar done in ThreadingMixIn? this kinda- tells me that thread-tracking is really needed, in a similar way to that in forkingmixin. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2001-05-03 16:26 Message: Logged In: YES user_id=413 Just a note of another casualty of this bug: I had to add the mentioned dummy close_request method hack to our own ThreadingMixIn class in mojo nation (in the sourceforge mojonation project's evil module, see the common/MojoNationHTTPServer.py file). Without it, python 2.1 would always raise an exception in the request handler as soon as it tried to call self.connection.makefile() because self.connection had apparently already been closed! (its fd was always -1) ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-02 01:41 Message: Logged In: YES user_id=80200 hi there mr jrielh, thank you very much for the details. what i am having a little difficulty with is, what's the difference between this and python 2.0 SocketServer.py? more specifically, i'm looking at python 2.0 SocketServer.py and, whilst i'm not a Threads expert, i see a t.start() but no t.join(). i've been looking at the Queue example code in the test method of threads.py, and start() is called on every thread, followed by join() on every thread. join waits for the thread to finish, yes? so... if that's the case, then python 2.0 SocketServer.py should suffer from exactly the same behaviour, yes? unless python behaves ever-so-slightly differently (timing issues?) when you have an extra base class like this, with the consequence that close_request() is more likely to be called before ThreadingMixIn.process_request(). ? ---------------------------------------------------------------------- Comment By: Jon Riehl (jriehl) Date: 2001-05-01 14:20 Message: Logged In: YES user_id=22448 This is related to bug #419873. The problem is not specifically in the ThreadingMixin specifically, but where BaseServer calls close_request() after calling process_request(). In the threading mixin, process_request() spins the thread and returns, causing the request socket to be invalidated while the thread is still running. The fix given above will keep the socket valid while the thread is running, but may cause the socket to not close properly (my threads generally close the socket when they are done anyway.) ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-04-26 05:41 Message: Logged In: YES user_id=80200 follow-up. i took a look at the differences between SocketServer.py in 2.0 and 2.1. there is one small change by guido to the ThreadingMixIn.process_request() function that calls self.server_close() instead of explicitly calling self.socket.close(), where TCPServer.server_close() calls self.socket.close(). if mr anonymous (hi!) has over-ridden server_close() and explicitly closes the *request* socket, then of course the socket will get closed twice. the rest of the code-mods is a straightforward code-shuffle moving code from TCPServer into BaseServer: from examining the diff, i really don't see how bypassing close_request(), as shown above with the Workaround in the original bug-report, will help: that will in fact cause the request _never_ to be closed! the rest of this report is part of an email exchange with guido, quoted here: "the bug-report doesn't state whether python 2.0 worked and 2.1 didn't: it also doesn't give enough info. for all we know, he's calling close_request() himself or request.close() directly somewhere in his code, and hasn't told anybody, which is why he has to over-ride close_request() and tell it to do nothing. or he's closing the socket in the HandlerClass, in finish(), or something. we just don't know. either that, or his HandlerClass creates a socket once and only once, with the result that close_request() closes the one socket, and he's _completely_ stuffed, then :)" ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-04-26 04:11 Message: Logged In: YES user_id=80200 hi there, i'm the person who wrote the BaseServer class. guido contacted me about it: could you please send me or post here a working test example that demonstrates the problem. i assume, but you do not state, that you have tested your MyHTTPServer with python 2.0, please let us know, here, if that is a correct assumption. thanks! luke ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470 From noreply@sourceforge.net Wed Jul 11 23:03:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 15:03:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-440522 ] Linux/nice() changes break build Message-ID: Bugs item #440522, was opened at 2001-07-11 15:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440522&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Thomas Wouters (twouters) Summary: Linux/nice() changes break build Initial Comment: (Perhaps these changes only broke the build for some versions of Linux; appearantly they helped on other versions.) On Mandrake Linux 7.2 (kernel 2.2.17), the posix_nice() function fails to compile with gcc: gcc -g -O3 -Wall -Wstrict-prototypes -Dss_family=__ss_family -Dss_len=__ss_len -I. -I../Include -DHAVE_CONFIG_H -c ../Modules/posixmodule.c -o Modules/posixmodule.o ../Modules/posixmodule.c: In function `posix_nice': ../Modules/posixmodule.c:1139: warning: implicit declaration of function `getpriority' ../Modules/posixmodule.c:1139: `PRIO_PROCESS' undeclared (first use in this function) ../Modules/posixmodule.c:1139: (Each undeclared identifier is reported only once../Modules/posixmodule.c:1139: for each function it appears in.) make: *** [Modules/posixmodule.o] Error 1 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440522&group_id=5470 From noreply@sourceforge.net Wed Jul 11 23:10:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 15:10:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-440522 ] Linux/nice() changes break build Message-ID: Bugs item #440522, was opened at 2001-07-11 15:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440522&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Thomas Wouters (twouters) Summary: Linux/nice() changes break build Initial Comment: (Perhaps these changes only broke the build for some versions of Linux; appearantly they helped on other versions.) On Mandrake Linux 7.2 (kernel 2.2.17), the posix_nice() function fails to compile with gcc: gcc -g -O3 -Wall -Wstrict-prototypes -Dss_family=__ss_family -Dss_len=__ss_len -I. -I../Include -DHAVE_CONFIG_H -c ../Modules/posixmodule.c -o Modules/posixmodule.o ../Modules/posixmodule.c: In function `posix_nice': ../Modules/posixmodule.c:1139: warning: implicit declaration of function `getpriority' ../Modules/posixmodule.c:1139: `PRIO_PROCESS' undeclared (first use in this function) ../Modules/posixmodule.c:1139: (Each undeclared identifier is reported only once../Modules/posixmodule.c:1139: for each function it appears in.) make: *** [Modules/posixmodule.o] Error 1 ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-07-11 15:10 Message: Logged In: YES user_id=12800 Ploing! I just reported this same problem to python-dev. Attached is a patch that fixes it for me on my RH6.1-ish Linux box. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440522&group_id=5470 From noreply@sourceforge.net Wed Jul 11 23:36:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 15:36:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-417212 ] curses.newwin can return pads Message-ID: Bugs item #417212, was opened at 2001-04-18 19:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417212&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: David M. Cooke (dmcooke) Assigned to: A.M. Kuchling (akuchling) Summary: curses.newwin can return pads Initial Comment: In 2.1 (at least), curses.newwin can return a pad object if it's called with two arguments, i.e. win = curses.newwin(0,0) Since this is actually a pad, win.refresh has to be called with six arguments -- the syntax used for refreshing a pad -- instead of as just win.refresh() Looking at the code for _cursesmodule.c, it appears that only win.refresh() and win.noutrefresh() take different arguments depending on whether win is actually a window or a pad. It looks like there are three options here: - document that the two-argument version of curses.newwin returns a pad (and hence the six-argument .refresh() must be used) - make curses.newwin take four arguments only (as the two argument version is currently equivalent to newpad) - have win.refresh() and win.noutrefresh() do sensible things for pads (although I don't know what that would be...) I would think #2 is the best. Hmm, perhaps there should be a separate object type for pads, so we can tell the difference between pads and windows. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-07-11 15:36 Message: Logged In: YES user_id=11375 I think I agree with your choice of #2. It's also possible that the newpad() is a typo or cut-and-paste error of some sort; it's been there since Oliver Andrich's original ncurses module. I'll add a warning to the 2-argument newwin(), and it can disappear in Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417212&group_id=5470 From noreply@sourceforge.net Wed Jul 11 23:37:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 15:37:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-440522 ] Linux/nice() changes break build Message-ID: Bugs item #440522, was opened at 2001-07-11 15:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440522&group_id=5470 Category: Extension Modules Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Thomas Wouters (twouters) Summary: Linux/nice() changes break build Initial Comment: (Perhaps these changes only broke the build for some versions of Linux; appearantly they helped on other versions.) On Mandrake Linux 7.2 (kernel 2.2.17), the posix_nice() function fails to compile with gcc: gcc -g -O3 -Wall -Wstrict-prototypes -Dss_family=__ss_family -Dss_len=__ss_len -I. -I../Include -DHAVE_CONFIG_H -c ../Modules/posixmodule.c -o Modules/posixmodule.o ../Modules/posixmodule.c: In function `posix_nice': ../Modules/posixmodule.c:1139: warning: implicit declaration of function `getpriority' ../Modules/posixmodule.c:1139: `PRIO_PROCESS' undeclared (first use in this function) ../Modules/posixmodule.c:1139: (Each undeclared identifier is reported only once../Modules/posixmodule.c:1139: for each function it appears in.) make: *** [Modules/posixmodule.o] Error 1 ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-11 15:37 Message: Logged In: YES user_id=34209 Fixed in the CVS tree now. Geez, you impatient people just have no respect for dinner, do you ? Not to mention crash-and-burn-time at work ;-) ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-07-11 15:10 Message: Logged In: YES user_id=12800 Ploing! I just reported this same problem to python-dev. Attached is a patch that fixes it for me on my RH6.1-ish Linux box. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440522&group_id=5470 From noreply@sourceforge.net Wed Jul 11 23:43:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 15:43:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-417212 ] curses.newwin can return pads Message-ID: Bugs item #417212, was opened at 2001-04-18 19:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417212&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: David M. Cooke (dmcooke) Assigned to: A.M. Kuchling (akuchling) Summary: curses.newwin can return pads Initial Comment: In 2.1 (at least), curses.newwin can return a pad object if it's called with two arguments, i.e. win = curses.newwin(0,0) Since this is actually a pad, win.refresh has to be called with six arguments -- the syntax used for refreshing a pad -- instead of as just win.refresh() Looking at the code for _cursesmodule.c, it appears that only win.refresh() and win.noutrefresh() take different arguments depending on whether win is actually a window or a pad. It looks like there are three options here: - document that the two-argument version of curses.newwin returns a pad (and hence the six-argument .refresh() must be used) - make curses.newwin take four arguments only (as the two argument version is currently equivalent to newpad) - have win.refresh() and win.noutrefresh() do sensible things for pads (although I don't know what that would be...) I would think #2 is the best. Hmm, perhaps there should be a separate object type for pads, so we can tell the difference between pads and windows. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-07-11 15:43 Message: Logged In: YES user_id=11375 Hmm... another option would be to just use newwin() instead of newpad(), and set nlines and ncols to zero, making ncurses use the rest of the screen for the window. On reflection, I think I like this solution better because it makes the code reflect the document behaviour. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-07-11 15:36 Message: Logged In: YES user_id=11375 I think I agree with your choice of #2. It's also possible that the newpad() is a typo or cut-and-paste error of some sort; it's been there since Oliver Andrich's original ncurses module. I'll add a warning to the 2-argument newwin(), and it can disappear in Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417212&group_id=5470 From noreply@sourceforge.net Thu Jul 12 01:49:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 17:49:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-434479 ] os.listdir loses on linux w/NTFS vols Message-ID: Bugs item #434479, was opened at 2001-06-19 07:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434479&group_id=5470 Category: Python Library Group: Irreproducible Status: Closed Resolution: Works For Me Priority: 5 Submitted By: jeremy bornstein (ukekuma) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: os.listdir loses on linux w/NTFS vols Initial Comment: os.listdir() on a directory which is on an NTFS volume omits one entry from the directory listing. Example: planet {188}: grep ntfs /etc/fstab /dev/hda1 /lose ntfs uid=500,gid=500,umask=555 1 2 planet {189}: ls /lose Documents and Settings/ My Music/ Program Files/ PUTTY.RND $Secure unzipped/ WINNT/ planet {190}: python2.1 Python 2.1 (#1, Jun 19 2001, 00:32:28) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import os >>> os.listdir('/lose') ['$Secure', 'Documents and Settings', 'My Music', 'Program Files', 'PUTTY.RND', 'unzipped'] >>> planet {191}: (In the example, note that the directory 'WINNT' is not returned by os.listdir.) I have verified this bug with/1.5.2, 1.6.1, and 2.1 on Linux (RH7.1) only. I have only tested it on this one NTFS volume and this one computer. ---------------------------------------------------------------------- >Comment By: jeremy bornstein (ukekuma) Date: 2001-07-11 17:49 Message: Logged In: YES user_id=248973 I noticed that it was always the *final* directory entry which was not displayed. I don't think the problem has anything to do with the WINNT directory specifically, other than it the fact that it was the last one. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-11 11:33 Message: Logged In: YES user_id=3066 I was not able to reproduce this on my system (Mandrake 7.2, Linux 2.2.17). This may be a difference in configuration: I have an NTFS partition, but it's not the one that contains my \WINNT directory. If \WINNT is special in some way, I can't reproduce that. See also Martin's comment; he's likely to know exactly what he's talking about. I'm going to close this as irreproducible, acknowledging that it might really be a third-party bug. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 23:54 Message: Logged In: YES user_id=3066 Assigning this to me since I have a similar setup. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-23 12:45 Message: Logged In: YES user_id=21627 This is likely a bug in the NTFS driver, not in Python. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434479&group_id=5470 From noreply@sourceforge.net Thu Jul 12 02:14:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 18:14:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-434479 ] os.listdir loses on linux w/NTFS vols Message-ID: Bugs item #434479, was opened at 2001-06-19 07:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434479&group_id=5470 Category: Python Library Group: Irreproducible Status: Closed Resolution: Works For Me Priority: 5 Submitted By: jeremy bornstein (ukekuma) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: os.listdir loses on linux w/NTFS vols Initial Comment: os.listdir() on a directory which is on an NTFS volume omits one entry from the directory listing. Example: planet {188}: grep ntfs /etc/fstab /dev/hda1 /lose ntfs uid=500,gid=500,umask=555 1 2 planet {189}: ls /lose Documents and Settings/ My Music/ Program Files/ PUTTY.RND $Secure unzipped/ WINNT/ planet {190}: python2.1 Python 2.1 (#1, Jun 19 2001, 00:32:28) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import os >>> os.listdir('/lose') ['$Secure', 'Documents and Settings', 'My Music', 'Program Files', 'PUTTY.RND', 'unzipped'] >>> planet {191}: (In the example, note that the directory 'WINNT' is not returned by os.listdir.) I have verified this bug with/1.5.2, 1.6.1, and 2.1 on Linux (RH7.1) only. I have only tested it on this one NTFS volume and this one computer. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-11 18:14 Message: Logged In: YES user_id=3066 What's really strange is that Python & ls are returning different results. Python is just using opendir/readdir/closedir for Linux; I've not read the ls sources to know what that's doing (but it should be considered buggy if that's not what it's doing!). Now, if we could get Martin interested in working on the Linux NTFS driver again... ---------------------------------------------------------------------- Comment By: jeremy bornstein (ukekuma) Date: 2001-07-11 17:49 Message: Logged In: YES user_id=248973 I noticed that it was always the *final* directory entry which was not displayed. I don't think the problem has anything to do with the WINNT directory specifically, other than it the fact that it was the last one. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-11 11:33 Message: Logged In: YES user_id=3066 I was not able to reproduce this on my system (Mandrake 7.2, Linux 2.2.17). This may be a difference in configuration: I have an NTFS partition, but it's not the one that contains my \WINNT directory. If \WINNT is special in some way, I can't reproduce that. See also Martin's comment; he's likely to know exactly what he's talking about. I'm going to close this as irreproducible, acknowledging that it might really be a third-party bug. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 23:54 Message: Logged In: YES user_id=3066 Assigning this to me since I have a similar setup. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-23 12:45 Message: Logged In: YES user_id=21627 This is likely a bug in the NTFS driver, not in Python. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434479&group_id=5470 From noreply@sourceforge.net Thu Jul 12 03:32:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 19:32:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-436259 ] [Windows] exec*/spawn* problem with spaces in args Message-ID: Bugs item #436259, was opened at 2001-06-25 20:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436259&group_id=5470 >Category: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Ben Hutchings (wom-work) >Assigned to: Greg Ward (gward) >Summary: [Windows] exec*/spawn* problem with spaces in args Initial Comment: DOS and Windows processes are not given an argument vector, as Unix processes are; instead they are given a command line and are expected to perform any necessary argument parsing themselves. Each C run-time library must convert command lines into argument vectors for the main() function, and if it includes exec* and spawn* functions then those must convert argument vectors into a command-line. Naturally, the various implementations differ in interesting ways. The Visual C++ run-time library (MSVCRT) implementation of the exec* and spawn* functions is particularly awful in that it simply concatenates the strings with spaces in-between (see source file cenvarg.c), which means that arguments with embedded spaces are likely to turn into multiple arguments in the new process. Obviously, when Python is built using Visual C++, its os.exec* and os.spawn* functions behave in this way too. MS prefers to work around this bug (see Knowledge Base article Q145937) rather than to fix it. Therefore I think Python must work around it too when built with Visual C++. I experimented with MSVCRT and Cygwin (using the attached program print_args.c) and could not find a way to convert an argument vector into a command line that they would both convert back to the same argument vector, but I got close. MSVCRT's parser requires spaces that are part of an argument to be enclosed in double-quotes. The double-quotes do not have to enclose the whole argument. Literal double-quotes must be escaped by preceding them with a backslash. If an argument contains literal backslashes before a literal or delimiting double-quote, those backslashes must be escaped by doubling them. If there is an unmatched enclosing double-quote then the parser behaves as if there was another double-quote at the end of the line. Cygwin's parser requires spaces that are part of an argument to be enclosed in double-quotes. The double-quotes do not have to enclose the whole argument. Literal double-quotes may be escaped by preceding them with a backslash, but then they count as enclosing double-quote as well, which appears to be a bug. They may also be escaped by doubling them, in which case they must be enclosed in double-quotes; since MSVCRT does not accept this, it's useless. As far as I can see, literal backslashes before a literal double-quote must not be escaped and literal backslashes before an enclosing double-quote *cannot* be escaped. It's really quite hard to understand what its rules are for backslashes and double-quotes, and I think it's broken. If there is an unmatched enclosing double-quote then the parser behaves as if there was another double-quote at the end of the line. Here's a Python version of a partial fix for use in nt.exec* and nt.spawn*. This function modifies argument strings so that the resulting command line will satisfy programs that use MSVCRT, and programs that use Cygwin if that's possible. def escape(arg): import re # If arg contains no space or double-quote then # no escaping is needed. if not re.search(r'[ "]', arg): return arg # Otherwise the argument must be quoted and all # double-quotes, preceding backslashes, and # trailing backslashes, must be escaped. def repl(match): if match.group(2): return match.group(1) * 2 + '\"' else: return match.group(1) * 2 return '"' + re.sub(r'(\*)("|$)', repl, arg) + '"' This could perhaps be used as a workaround for the problem. Unfortunately it would conflict with workarounds implemented at the Python level (which I have been using for a while). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-11 19:32 Message: Logged In: YES user_id=31435 Note that processes using WinMain can get at argc and argv under MSVC via including stdlib.h and using __argc and __argv instead. I agree the space behavior sucks regardless. However, as you've discovered, there's nothing magical we can do about it without breaking the workarounds people have already developed on their own -- including distutils. The right way to address this is to add more smarts to spawn.py in distutils, then press to adopt that in the std library (distutils already does *some* magical arg quoting on win32 systems, and could use your help to do a better job of it). Accordingly, I added [Windows] to the summary line, changed the category to distutils, and reassigned to Greg Ward for consideration. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436259&group_id=5470 From noreply@sourceforge.net Thu Jul 12 05:30:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 21:30:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-436259 ] [Windows] exec*/spawn* problem with spaces in args Message-ID: Bugs item #436259, was opened at 2001-06-25 20:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436259&group_id=5470 Category: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Ben Hutchings (wom-work) Assigned to: Greg Ward (gward) Summary: [Windows] exec*/spawn* problem with spaces in args Initial Comment: DOS and Windows processes are not given an argument vector, as Unix processes are; instead they are given a command line and are expected to perform any necessary argument parsing themselves. Each C run-time library must convert command lines into argument vectors for the main() function, and if it includes exec* and spawn* functions then those must convert argument vectors into a command-line. Naturally, the various implementations differ in interesting ways. The Visual C++ run-time library (MSVCRT) implementation of the exec* and spawn* functions is particularly awful in that it simply concatenates the strings with spaces in-between (see source file cenvarg.c), which means that arguments with embedded spaces are likely to turn into multiple arguments in the new process. Obviously, when Python is built using Visual C++, its os.exec* and os.spawn* functions behave in this way too. MS prefers to work around this bug (see Knowledge Base article Q145937) rather than to fix it. Therefore I think Python must work around it too when built with Visual C++. I experimented with MSVCRT and Cygwin (using the attached program print_args.c) and could not find a way to convert an argument vector into a command line that they would both convert back to the same argument vector, but I got close. MSVCRT's parser requires spaces that are part of an argument to be enclosed in double-quotes. The double-quotes do not have to enclose the whole argument. Literal double-quotes must be escaped by preceding them with a backslash. If an argument contains literal backslashes before a literal or delimiting double-quote, those backslashes must be escaped by doubling them. If there is an unmatched enclosing double-quote then the parser behaves as if there was another double-quote at the end of the line. Cygwin's parser requires spaces that are part of an argument to be enclosed in double-quotes. The double-quotes do not have to enclose the whole argument. Literal double-quotes may be escaped by preceding them with a backslash, but then they count as enclosing double-quote as well, which appears to be a bug. They may also be escaped by doubling them, in which case they must be enclosed in double-quotes; since MSVCRT does not accept this, it's useless. As far as I can see, literal backslashes before a literal double-quote must not be escaped and literal backslashes before an enclosing double-quote *cannot* be escaped. It's really quite hard to understand what its rules are for backslashes and double-quotes, and I think it's broken. If there is an unmatched enclosing double-quote then the parser behaves as if there was another double-quote at the end of the line. Here's a Python version of a partial fix for use in nt.exec* and nt.spawn*. This function modifies argument strings so that the resulting command line will satisfy programs that use MSVCRT, and programs that use Cygwin if that's possible. def escape(arg): import re # If arg contains no space or double-quote then # no escaping is needed. if not re.search(r'[ "]', arg): return arg # Otherwise the argument must be quoted and all # double-quotes, preceding backslashes, and # trailing backslashes, must be escaped. def repl(match): if match.group(2): return match.group(1) * 2 + '\"' else: return match.group(1) * 2 return '"' + re.sub(r'(\*)("|$)', repl, arg) + '"' This could perhaps be used as a workaround for the problem. Unfortunately it would conflict with workarounds implemented at the Python level (which I have been using for a while). ---------------------------------------------------------------------- >Comment By: Ben Hutchings (wom-work) Date: 2001-07-11 21:30 Message: Logged In: YES user_id=203860 "Note that processes using WinMain can get at argc and argv under MSVC via including stdlib.h and using __argc and __argv instead." This is irrelevant. The OS passes the command line into a process as a single string, which it makes accessible through the GetCommandLine() function. The argument vector received by main() or accessible as __argv is generated from this by the C run-time library. "The right way to address this is to add more smarts to spawn.py in distutils" I disagree. The right thing to do is to make these functions behave in the same way across platforms, as far as possible. Perhaps this could be done in two stages - in the first release, make the fix optional, and in the second, use it all the time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 19:32 Message: Logged In: YES user_id=31435 Note that processes using WinMain can get at argc and argv under MSVC via including stdlib.h and using __argc and __argv instead. I agree the space behavior sucks regardless. However, as you've discovered, there's nothing magical we can do about it without breaking the workarounds people have already developed on their own -- including distutils. The right way to address this is to add more smarts to spawn.py in distutils, then press to adopt that in the std library (distutils already does *some* magical arg quoting on win32 systems, and could use your help to do a better job of it). Accordingly, I added [Windows] to the summary line, changed the category to distutils, and reassigned to Greg Ward for consideration. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436259&group_id=5470 From noreply@sourceforge.net Thu Jul 12 05:57:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Jul 2001 21:57:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-436259 ] [Windows] exec*/spawn* problem with spaces in args Message-ID: Bugs item #436259, was opened at 2001-06-25 20:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436259&group_id=5470 Category: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Ben Hutchings (wom-work) Assigned to: Greg Ward (gward) Summary: [Windows] exec*/spawn* problem with spaces in args Initial Comment: DOS and Windows processes are not given an argument vector, as Unix processes are; instead they are given a command line and are expected to perform any necessary argument parsing themselves. Each C run-time library must convert command lines into argument vectors for the main() function, and if it includes exec* and spawn* functions then those must convert argument vectors into a command-line. Naturally, the various implementations differ in interesting ways. The Visual C++ run-time library (MSVCRT) implementation of the exec* and spawn* functions is particularly awful in that it simply concatenates the strings with spaces in-between (see source file cenvarg.c), which means that arguments with embedded spaces are likely to turn into multiple arguments in the new process. Obviously, when Python is built using Visual C++, its os.exec* and os.spawn* functions behave in this way too. MS prefers to work around this bug (see Knowledge Base article Q145937) rather than to fix it. Therefore I think Python must work around it too when built with Visual C++. I experimented with MSVCRT and Cygwin (using the attached program print_args.c) and could not find a way to convert an argument vector into a command line that they would both convert back to the same argument vector, but I got close. MSVCRT's parser requires spaces that are part of an argument to be enclosed in double-quotes. The double-quotes do not have to enclose the whole argument. Literal double-quotes must be escaped by preceding them with a backslash. If an argument contains literal backslashes before a literal or delimiting double-quote, those backslashes must be escaped by doubling them. If there is an unmatched enclosing double-quote then the parser behaves as if there was another double-quote at the end of the line. Cygwin's parser requires spaces that are part of an argument to be enclosed in double-quotes. The double-quotes do not have to enclose the whole argument. Literal double-quotes may be escaped by preceding them with a backslash, but then they count as enclosing double-quote as well, which appears to be a bug. They may also be escaped by doubling them, in which case they must be enclosed in double-quotes; since MSVCRT does not accept this, it's useless. As far as I can see, literal backslashes before a literal double-quote must not be escaped and literal backslashes before an enclosing double-quote *cannot* be escaped. It's really quite hard to understand what its rules are for backslashes and double-quotes, and I think it's broken. If there is an unmatched enclosing double-quote then the parser behaves as if there was another double-quote at the end of the line. Here's a Python version of a partial fix for use in nt.exec* and nt.spawn*. This function modifies argument strings so that the resulting command line will satisfy programs that use MSVCRT, and programs that use Cygwin if that's possible. def escape(arg): import re # If arg contains no space or double-quote then # no escaping is needed. if not re.search(r'[ "]', arg): return arg # Otherwise the argument must be quoted and all # double-quotes, preceding backslashes, and # trailing backslashes, must be escaped. def repl(match): if match.group(2): return match.group(1) * 2 + '\"' else: return match.group(1) * 2 return '"' + re.sub(r'(\*)("|$)', repl, arg) + '"' This could perhaps be used as a workaround for the problem. Unfortunately it would conflict with workarounds implemented at the Python level (which I have been using for a while). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-11 21:57 Message: Logged In: YES user_id=31435 distutils is *trying* to make spawn work the same way across platforms, via spawn.py. Help it! You're not likely to get anywhere with a change to the os.spawn family because you already know it will break code -- and it will break disutils in particular. If you want to break code, this needs a PEP first: write up your "two stage" approach in PEP and let the community have at it. If you read c.l.py, you should have a feel for how warmly that's likely to be received . The bit about __argv was just FYI (you seemed unaware of it; I agree it's irrelevant to what you want to achieve). ---------------------------------------------------------------------- Comment By: Ben Hutchings (wom-work) Date: 2001-07-11 21:30 Message: Logged In: YES user_id=203860 "Note that processes using WinMain can get at argc and argv under MSVC via including stdlib.h and using __argc and __argv instead." This is irrelevant. The OS passes the command line into a process as a single string, which it makes accessible through the GetCommandLine() function. The argument vector received by main() or accessible as __argv is generated from this by the C run-time library. "The right way to address this is to add more smarts to spawn.py in distutils" I disagree. The right thing to do is to make these functions behave in the same way across platforms, as far as possible. Perhaps this could be done in two stages - in the first release, make the fix optional, and in the second, use it all the time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-11 19:32 Message: Logged In: YES user_id=31435 Note that processes using WinMain can get at argc and argv under MSVC via including stdlib.h and using __argc and __argv instead. I agree the space behavior sucks regardless. However, as you've discovered, there's nothing magical we can do about it without breaking the workarounds people have already developed on their own -- including distutils. The right way to address this is to add more smarts to spawn.py in distutils, then press to adopt that in the std library (distutils already does *some* magical arg quoting on win32 systems, and could use your help to do a better job of it). Accordingly, I added [Windows] to the summary line, changed the category to distutils, and reassigned to Greg Ward for consideration. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436259&group_id=5470 From noreply@sourceforge.net Thu Jul 12 13:06:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Jul 2001 05:06:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-440497 ] nested function with variables Message-ID: Bugs item #440497, was opened at 2001-07-11 13:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440497&group_id=5470 Category: Parser/Compiler Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: nested function with variables Initial Comment: This code should not result in a syntax warning: def t0(): from math import * def t1(): print map(lambda x:x,[]) def t2(): print None SyntaxWarning: import * is not allowed in function 't0' because it contains a nested function with free variables Moving the function body one level out results in no warnings, removing the import as well. But the warnings persist for both t1 and t2 by itself. I have been trying to port my code to Python-2.1 (from 2.0) and encountered numerous problems due with SyntaxWarnings regarding the new scoping rules that I found way too confusing to be able to track it for my large code. These syntax warnings should be one of the major functions of 2.1 since they should help the migration to 2.2 with the new scoping enabled ...... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-12 05:06 Message: Logged In: NO OK, my fault that I ignored the status of "map", "filter" and "None". My "user experience" of porting my 2.0 code to 2.1 is however fairly pityful. Here some destilled suggestions: * separate warnings for "potential" "import *" problems for standard modules (as in the examples) -- sure we know what math exports right now and "from math import *" is a common idiom. * run-time warnings for shadowed constructs * listing of the variables that are imported and one may want to import by name instead (or qualify) While I really like the new scoping rules and they support my programming style their practical impact on existing code is quite large. A better support would be fairly important -- I have 50.000 lines of code to port .... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 13:24 Message: Logged In: YES user_id=6380 Closing this report since it's not a bug. (You can still add comments.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-07-11 13:24 Message: Logged In: YES user_id=6656 Consider what happens if math.py defines the name "None". It doesn't, and it won't ever, but there's nothing special about the name "None" to Python. Writing your second function as "def t2(): pass" should clear up the warnings (not checked as I don't have Python 2.1 on the box I'm posting from). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 13:24 Message: Logged In: YES user_id=6380 You get the warning because the compiler doesn't know whether the math module exports objects named 'map' or 'None'. (This may be obvious to you, but the compiler isn't clairvoyant, and it can't go and import the module while it's compiling another module.) There are several ways to avoid the warning: 1) Move the import to the module level. (Why are you putting the import in the function? It's slower that way.) 2) Be specific about the functions you import, e.g. write from math import sin, cos, tan 3) Use "import math" and write "math.sin(x)" etc. rathern than "sin(x)". Your example doesn't show why you would write such code. Perhaps showing some real code that you use that runs into this problem can give a better insight in how to deal with your porting problem... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440497&group_id=5470 From noreply@sourceforge.net Thu Jul 12 16:51:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Jul 2001 08:51:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-440707 ] doctest crashes on cross-platform .pyc Message-ID: Bugs item #440707, was opened at 2001-07-12 08:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440707&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Nobody/Anonymous (nobody) Summary: doctest crashes on cross-platform .pyc Initial Comment: doctest.py raises an exception when run on true cross- platform .pyc files (i.e., MacOS .py compiled with compileall.compile_dir on Windows). The problem is, _extract_examples splits up __doc__ strings with: lines = s.split("\n") MacOS-compiled-on-Windows .pyc __doc__ strings contain \r, not \n. The fix is to replace the line above (line 5 of _extract_examples) with: lines = s.splitlines() + [''] The reason for the "+ ['']" is that the behavior of s.splitlines() is subtly different from s.split("\n"): splitlines() doesn't return a final null string at the end of, say, "one\ntwo\n", whereas split("\n") does. (Is this difference of behavior a bug? If not, should it be described in the docs?) The "+ ['']" also circumvents errors when the docstring doesn't end with a newline, ie: """ >>> print 'hi' hi""" ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440707&group_id=5470 From noreply@sourceforge.net Thu Jul 12 17:02:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Jul 2001 09:02:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-437487 ] 2.1 build on Solaris fails if CC is set Message-ID: Bugs item #437487, was opened at 2001-06-29 15:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437487&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: A.M. Kuchling (akuchling) Summary: 2.1 build on Solaris fails if CC is set Initial Comment: If you have CC set to "gcc", then the "setup.py" script compiles the extensions incorrectly (in particular, the "-fPIC" on the compile is not used): ... PYTHONPATH= ./python ./setup.py build running build running build_ext building 'struct' extension creating build creating build/temp.solaris-2.7-sun4u-2.1 gcc -I. -I/extra/Python-2.1/./Include -I/usr/local/include -IInclude/ -c /extra/Python-2.1/Modules/structmodule.c -o build/temp.solaris-2.7-sun4u-2.1/structmodule.o creating build/lib.solaris-2.7-sun4u-2.1 gcc -shared build/temp.solaris-2.7-sun4u-2.1/structmodule.o -L/usr/local/lib -o build/lib.solaris-2.7-sun4u-2.1/struct.so Text relocation remains referenced against symbol offset in file 0x2094 build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x200c build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x3398 build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x2098 build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x2070 build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x206c .... If you want to compile code configured via "configure" with the "gcc" compiler and you have both the "gcc" and the Sun C compiler installed on your system, then you need to have the environment variable "CC" set to "gcc": CC=gcc So people (like myself) have "CC=gcc" in their .profile or equivalent in .login, and have had that for years without thinking about it. If you don't have "CC=gcc" set in your environment, then things work fine: ... PYTHONPATH= ./python ./setup.py build running build running build_ext building 'struct' extension creating build creating build/temp.solaris-2.7-sun4u-2.1 gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -I. -I/home/tflagg/projects/python/2.1sunos/Python-2.1/./Include -I/usr/local/include -IInclude/ -c /home/tflagg/projects/python/2.1sunos/Python-2.1/Modules/structmodule.c -o build/temp.solaris-2.7-sun4u-2.1/structmodule.o (In particular, the "-fPIC" flag needs to be there as shown above.) The problem lines in "setup.py" are: 112 # When you run "make CC=altcc" or something similar, you really want 113 # those environment variables passed into the setup.py phase. Here's 114 # a small set of useful ones. 115 compiler = os.environ.get('CC') <---------- 116 linker_so = os.environ.get('LDSHARED') 117 args = {} 118 # unfortunately, distutils doesn't let us provide separate C and C++ 119 # compilers 120 if compiler is not None: <--------------- 121 args['compiler_so'] = compiler <--------- It's true the user may want to set site-specific/user-specific compiler options. However, if "CC" is only "gcc" then the user is trying to communicate: - Use "gcc" rather than Sun's C compiler They are NOT trying to communicate: - Do not use any of the compiler flags for compiling shared objects. The reason this bug Solaris-specific is because Solaris installations are the most likely to have a non-gcc compiler installed, requiring the "CC=gcc" environment variable set. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-12 09:02 Message: Logged In: YES user_id=34209 AMK, I'm running into this problem now, while testing on Solaris 2.7. However, the patch attached here, seems to be the wrong one (it adds checking for sys/poll.h, looks like.) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-07-11 13:09 Message: Logged In: YES user_id=11375 Proposed patch attached; if the original poster is monitoring this bug, please try it and let me know if it helps. Otherwise, I'll check it in in a few days. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437487&group_id=5470 From noreply@sourceforge.net Thu Jul 12 17:16:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Jul 2001 09:16:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-437487 ] 2.1 build on Solaris fails if CC is set Message-ID: Bugs item #437487, was opened at 2001-06-29 15:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437487&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: A.M. Kuchling (akuchling) Summary: 2.1 build on Solaris fails if CC is set Initial Comment: If you have CC set to "gcc", then the "setup.py" script compiles the extensions incorrectly (in particular, the "-fPIC" on the compile is not used): ... PYTHONPATH= ./python ./setup.py build running build running build_ext building 'struct' extension creating build creating build/temp.solaris-2.7-sun4u-2.1 gcc -I. -I/extra/Python-2.1/./Include -I/usr/local/include -IInclude/ -c /extra/Python-2.1/Modules/structmodule.c -o build/temp.solaris-2.7-sun4u-2.1/structmodule.o creating build/lib.solaris-2.7-sun4u-2.1 gcc -shared build/temp.solaris-2.7-sun4u-2.1/structmodule.o -L/usr/local/lib -o build/lib.solaris-2.7-sun4u-2.1/struct.so Text relocation remains referenced against symbol offset in file 0x2094 build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x200c build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x3398 build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x2098 build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x2070 build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x206c .... If you want to compile code configured via "configure" with the "gcc" compiler and you have both the "gcc" and the Sun C compiler installed on your system, then you need to have the environment variable "CC" set to "gcc": CC=gcc So people (like myself) have "CC=gcc" in their .profile or equivalent in .login, and have had that for years without thinking about it. If you don't have "CC=gcc" set in your environment, then things work fine: ... PYTHONPATH= ./python ./setup.py build running build running build_ext building 'struct' extension creating build creating build/temp.solaris-2.7-sun4u-2.1 gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -I. -I/home/tflagg/projects/python/2.1sunos/Python-2.1/./Include -I/usr/local/include -IInclude/ -c /home/tflagg/projects/python/2.1sunos/Python-2.1/Modules/structmodule.c -o build/temp.solaris-2.7-sun4u-2.1/structmodule.o (In particular, the "-fPIC" flag needs to be there as shown above.) The problem lines in "setup.py" are: 112 # When you run "make CC=altcc" or something similar, you really want 113 # those environment variables passed into the setup.py phase. Here's 114 # a small set of useful ones. 115 compiler = os.environ.get('CC') <---------- 116 linker_so = os.environ.get('LDSHARED') 117 args = {} 118 # unfortunately, distutils doesn't let us provide separate C and C++ 119 # compilers 120 if compiler is not None: <--------------- 121 args['compiler_so'] = compiler <--------- It's true the user may want to set site-specific/user-specific compiler options. However, if "CC" is only "gcc" then the user is trying to communicate: - Use "gcc" rather than Sun's C compiler They are NOT trying to communicate: - Do not use any of the compiler flags for compiling shared objects. The reason this bug Solaris-specific is because Solaris installations are the most likely to have a non-gcc compiler installed, requiring the "CC=gcc" environment variable set. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-07-12 09:16 Message: Logged In: YES user_id=11375 The dangers of multiple machines... try this patch, instead. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-12 09:02 Message: Logged In: YES user_id=34209 AMK, I'm running into this problem now, while testing on Solaris 2.7. However, the patch attached here, seems to be the wrong one (it adds checking for sys/poll.h, looks like.) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-07-11 13:09 Message: Logged In: YES user_id=11375 Proposed patch attached; if the original poster is monitoring this bug, please try it and let me know if it helps. Otherwise, I'll check it in in a few days. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437487&group_id=5470 From noreply@sourceforge.net Thu Jul 12 17:30:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Jul 2001 09:30:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-440725 ] setup.py does not properly build bsddb Message-ID: Bugs item #440725, was opened at 2001-07-12 09:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440725&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: setup.py does not properly build bsddb Initial Comment: On my Mandrake system, if the db2-devel RPM is installed it will compile and link bsddb.o and bsddb.so, but importing bsddb fails because the .so wasn't linked with -ldb2, so the dbopen symbol isn't defined. The attached context diff solves the problem for me. Note that it's possible that any or all of libdb3, libdb2, or libdb1 are installed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440725&group_id=5470 From noreply@sourceforge.net Thu Jul 12 21:27:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Jul 2001 13:27:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-440707 ] doctest crashes on cross-platform .pyc Message-ID: Bugs item #440707, was opened at 2001-07-12 08:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440707&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Nobody/Anonymous (nobody) Summary: doctest crashes on cross-platform .pyc Initial Comment: doctest.py raises an exception when run on true cross- platform .pyc files (i.e., MacOS .py compiled with compileall.compile_dir on Windows). The problem is, _extract_examples splits up __doc__ strings with: lines = s.split("\n") MacOS-compiled-on-Windows .pyc __doc__ strings contain \r, not \n. The fix is to replace the line above (line 5 of _extract_examples) with: lines = s.splitlines() + [''] The reason for the "+ ['']" is that the behavior of s.splitlines() is subtly different from s.split("\n"): splitlines() doesn't return a final null string at the end of, say, "one\ntwo\n", whereas split("\n") does. (Is this difference of behavior a bug? If not, should it be described in the docs?) The "+ ['']" also circumvents errors when the docstring doesn't end with a newline, ie: """ >>> print 'hi' hi""" ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-12 13:27 Message: Logged In: YES user_id=6380 I'll have to look into this more, but I strongly recommend against fixing doctest in the way you suggest. The bug must somehow be in the portability of .pyc files. I'm surprised that string literals compiled on Windows contain \r in the .pyc file. Are you *sure* this is what causes your problem? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440707&group_id=5470 From noreply@sourceforge.net Thu Jul 12 21:54:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Jul 2001 13:54:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-440707 ] doctest crashes on cross-platform .pyc Message-ID: Bugs item #440707, was opened at 2001-07-12 08:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440707&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Nobody/Anonymous (nobody) Summary: doctest crashes on cross-platform .pyc Initial Comment: doctest.py raises an exception when run on true cross- platform .pyc files (i.e., MacOS .py compiled with compileall.compile_dir on Windows). The problem is, _extract_examples splits up __doc__ strings with: lines = s.split("\n") MacOS-compiled-on-Windows .pyc __doc__ strings contain \r, not \n. The fix is to replace the line above (line 5 of _extract_examples) with: lines = s.splitlines() + [''] The reason for the "+ ['']" is that the behavior of s.splitlines() is subtly different from s.split("\n"): splitlines() doesn't return a final null string at the end of, say, "one\ntwo\n", whereas split("\n") does. (Is this difference of behavior a bug? If not, should it be described in the docs?) The "+ ['']" also circumvents errors when the docstring doesn't end with a newline, ie: """ >>> print 'hi' hi""" ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-12 13:54 Message: Logged In: YES user_id=6380 I experimented (on Windows) and looked at the source some more, and I cannot see how a \r could ever have ended up in the .pyc file for a newline, no matter how or where the .pyc file was written. The only other theory that might explain what you see is that when you transfered the .pyc file from Windows to Mac, \n got translated into \r. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-12 13:27 Message: Logged In: YES user_id=6380 I'll have to look into this more, but I strongly recommend against fixing doctest in the way you suggest. The bug must somehow be in the portability of .pyc files. I'm surprised that string literals compiled on Windows contain \r in the .pyc file. Are you *sure* this is what causes your problem? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440707&group_id=5470 From noreply@sourceforge.net Fri Jul 13 00:01:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Jul 2001 16:01:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-417491 ] UnixWare BUILD *STILL* uses ld -G Message-ID: Bugs item #417491, was opened at 2001-04-19 16:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417491&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Larry Rosenman (ler) >Assigned to: Martin v. Löwis (loewis) Summary: UnixWare BUILD *STILL* uses ld -G Initial Comment: bug 231439 is BACK in the 2.1 final release. It still uses ld -G. ALL shared objects, ESPECIALLY those using threads, should be compiled *AND* linked using cc -G. I'm very disappointed in that the bug was closed but the QA process dropped the fix(es). ALSO, when doing the initial build using Shared Objects, you need to set -R and/or set LD_LIBRARY_PATH to suit. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-12 16:01 Message: Logged In: YES user_id=3066 Assigning to Martin since I'm about to approve his patch, and he'll need to close this one. Regarding the QA issue: we have no way to test on most of the platforms we support, so it's pretty hard to know which changes break where. We appreciate the effort to which you've gone to let us know what needs to be fixed to support your platform. ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-04-21 19:55 Message: Logged In: YES user_id=36452 Oh, and I'm VERY willing to test RC's. I didn't realize it was close to release..... ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-04-21 19:35 Message: Logged In: YES user_id=36452 Ok. Sorry for the screaming, but the CVS sources are STILL broken. Can someone look at the patch I generated, and see if it can be integrated into current CVS? I've built 2.1 with it on UnixWare 7 7.1.1 with the UDK FS 7.1.1b compiler. It works. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-04-21 19:30 Message: Logged In: YES user_id=31435 LARRY, there's REALLY no need to SCREAM on *EACH* word in THREE . You're not impressed by QA -- join the club. Testing is done by volunteers, and if there are no volunteers *trying* the release candidates on a new platform, we have no way to know whether they work. Linux and Windows and Mac Classic are pretty well covered by volunteers, but that's about it. If UnixWare is important enough to you, volunteer to test release candidates there yourself, or even pay someone to do it. But don't go honking on Martin! That's out of line. About your "The last comments on this patch are telling.", the last comments on that patch were made *after* the release. Before the release, Guido checked in the patch that the UnixWare user said was needed. He can't guess whether a patch actually works on a platform he doesn't use. The last patch comment by a UnixWare user *before* the release reads """Every thing looks fine (as far as I can tell).""" WRT "why the H*LL didn't the release .tar get RE-ROLLED?", it's because nobody said anything was broken until after the release shipped (your bug report here was 2 days after the release). ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-04-21 17:34 Message: Logged In: YES user_id=36452 OK, here is a patch I wrote to configure.in to fix this. regen configure and config.h.in Let me know if this is acceptable. THis is against the 2.1-RELEASE version. Larry ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-04-21 15:45 Message: Logged In: YES user_id=36452 Oh, and 1.215 is *BROKE*, as it spec's ld -G, not CC -G, around line 615 or so. PLEASE fix. PLEASE generate a FIX RELEASE for the 2.1 RELEASE. This is *NOT* a good sign that a broken PORT didn't stop the release process. ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-04-21 15:23 Message: Logged In: YES user_id=36452 OK, why the H*LL didn't the release .tar get RE-ROLLED? The last comments on this patch are telling. I'm *NOT* impressed, and the bug reported here is mentioned in that stream, so why wasn't the RELEASE held for this? the port is PROMINENTLY mentioned in the release notes, but it's BROKE in the RELEASE. How can I get a new tarball from y'all? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-21 05:55 Message: Logged In: YES user_id=21627 I agree this is very unfortunate. Please have a look at patch 413011, which was committed as 1.215 of configure.in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417491&group_id=5470 From noreply@sourceforge.net Fri Jul 13 00:04:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Jul 2001 16:04:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-213797 ] Build problems on Reliant Unix Message-ID: Bugs item #213797, was opened at 2000-09-07 07:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=213797&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Daniel Dittmar (ddittmar) >Assigned to: Martin v. Löwis (loewis) Summary: Build problems on Reliant Unix Initial Comment: - the linker requires the options '-W1 -Blargedynsym', otherwise, Python's global functions and variables are not visible to external modules - when building --with-threads, the linker requires the option -Kpthread - mmapmodule.o requires a special library Python version: 2.0b1 compiler version:CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000 CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-12 16:04 Message: Logged In: YES user_id=3066 Marin, you should be able to close this when you check in your UnixWare/ReliantUNIX patch. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-10-12 09:28 Message: I'm recording here part of the needed patch for threads; this is needed in configure.in to get the -Kpthread option passed to the compiler and linker in all the appropriate places. There are still problems in the code. (It won't look right in a browser, but it provides all the needed information.) *************** *** 752,757 **** --- 752,761 ---- if test ! -z "$withval" -a -d "$withval" then LDFLAGS="$LDFLAGS -L$withval" fi + case "$ac_sys_system" in + ReliantUNIX*) LDFLAGS="$LDFLAGS -Kpthread"; + OPT="$OPT -Kpthread";; + esac AC_DEFINE(_REENTRANT) AC_CHECK_HEADER(mach/cthreads.h, [AC_DEFINE(WITH_THREAD) AC_DEFINE(C_THREADS) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-10-05 19:00 Message: This won't be resolved for Python 2.0. There's enough that would be effected by revising the thread identification code that we don't want to destabilize the sources at this point. We should be able to resolve this for Python 2.1. I've added a comment about this to the platform notes section of the README file (revision 1.102) to alert the reader to this situation. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-10-03 09:22 Message: I've sent a note to Daniel asking for the config.h and config.log files generated by configure. There's a real problem with the way we're creating thread identifiers; casting to a long just isn't sufficient. It might be good to know what kind of processor is on the machine. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-10-03 09:16 Message: Daniel Dittmar's response: - the configure script works, except that the correct option is '-Kpthread' (you mistyped '-Lpthread' - there's a compilation error in thread_pthread.h:181: the expression '(long) threadid' is not valid. The definition of pthread_t is typedef struct PTHREAD_HANDLE_T { void *field1; short int field2; short int field3; } pthread_handle_t; typedef pthread_handle_t pthread_t; so I doubt that the alternative return (long) *(long *) &threadid is valid. I could compile it with this version, but I doubt it's returning a meaningful thread id. Is there a test for the thread module? I'm away for the rest of the week, so I couldn't test anything for the Wednesday date. - for your information, I'm including the results of 'make test', at least the failed ones: test test_fork1 crashed -- exceptions.OSError: [Errno 4] Interrupted system call test test_popen2 crashed -- exceptions.IOError: [Errno 4] Interrupted system call test_signal Trace/Breakpoint Trap - core dumped make: *** Error code 133 (ignored) make: *** Error code 133 (bu21) (ignored) These test leave a few python processes around. I'll probably look into this when I return. Daniel ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-10-02 08:30 Message: Sent another version of the configure script to Daniel Dittmar for testing the thread support. I think this is the last remaining problem listed in this bug report. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-10-01 10:51 Message: mmap patch checked in as Modules/mmapmodule.c revision 2.24. ---------------------------------------------------------------------- Comment By: Daniel Dittmar (ddittmar) Date: 2000-10-01 09:34 Message: The patch for the mmap module works on 2.0b2 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-09-28 10:36 Message: I've sent a patch for the mmap module to Daniel to test on Reliant UNIX; the patch should remove the need to link to libucb on that platform (the only platform that needed that as far as we know). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-09-25 08:10 Message: Fix to make sure the public API properly exposed to extensions checked in as configure.in revision 1.155. The rest of these issues can be dealt with in 2.0 final. ---------------------------------------------------------------------- Comment By: Daniel Dittmar (ddittmar) Date: 2000-09-24 05:46 Message: - configure --without-threads works with the configure patch Revision 1.158 - mmapmodule would work if it includes the lines #include static int getpagesize (void) { return sysconf (_SC_PAGESIZE); } This would be the preferred way as using the BSD compatibility with -lucb is discouraged. It requires chages to configure (has_pagesize, has_sysconf_sc_pagesize) - configure --with-threads doesn't build yet, keeping contact with fdrake ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-09-21 08:46 Message: Received message from Daniel indicating he should get a chace to test the changes this weekend, so it should be available for 2.0b2. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-09-21 08:17 Message: Sent query to Daniel Dittmar asking if he's had a chance to test the revised configure script I sent. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-09-15 13:37 Message: I'm sending a modified version of the configure script to Daniel Dittmar to test for the first two points in this bug report. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-09-15 11:57 Message: For the mmap issue, I've added a comment to Modules/Setup.in to let installers know that -lucb may be needed. In revision 1.110. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-09-12 21:59 Message: Received the following response from Daniel Dittmar : > We need to know the output of "uname -s" and "uname -r" > for this system. (If "uname -r" reports an error, please > try "uname -v".) uname -s ReliantUNIX-N uname -r 5.45 > Are you willing to test a modified configure script on > this platform? sure. > What additional library is required for the mmap module? The man page states -lucb. This didn't work on my machine as the BSD compatibility layer is not active. I tell you more as soon as I know how to activate it. *********** Another problem: to detect pthreads, the compiler must be called with -Kpthread. Otherwise, pthread.h goes into a branch where it tries to include a non existent header, fails, and configure reports 'no pthreads'. Daniel ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-09-08 13:45 Message: We need to know the output of "uname -s" and "uname -r" for this system. (If "uname -r" reports an error, please try "uname -v".) Are you willing to test a modified configure script on this platform? What additional library is required for the mmap module? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2000-09-07 15:05 Message: Please do triage on this bug. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=213797&group_id=5470 From noreply@sourceforge.net Fri Jul 13 04:31:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Jul 2001 20:31:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-440911 ] typo in xor docs Message-ID: Bugs item #440911, was opened at 2001-07-12 20:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440911&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: typo in xor docs Initial Comment: In the following text (from http://www.python.org/doc/current/api/number.html): PyObject* PyNumber_InPlaceXor(PyObject *o1, PyObject *o2) Return value: New reference. Returns the ``bitwise exclusive or'' of o1 by o2 on success, or NULL on failure. The operation is done in- place when o1 supports it. This is the equivalent of the Python expression "o1 = o2". I think the Python expression should be "o1 ^= o2" ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440911&group_id=5470 From noreply@sourceforge.net Fri Jul 13 05:29:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Jul 2001 21:29:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-440707 ] doctest crashes on cross-platform .pyc Message-ID: Bugs item #440707, was opened at 2001-07-12 08:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440707&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Nobody/Anonymous (nobody) Summary: doctest crashes on cross-platform .pyc Initial Comment: doctest.py raises an exception when run on true cross- platform .pyc files (i.e., MacOS .py compiled with compileall.compile_dir on Windows). The problem is, _extract_examples splits up __doc__ strings with: lines = s.split("\n") MacOS-compiled-on-Windows .pyc __doc__ strings contain \r, not \n. The fix is to replace the line above (line 5 of _extract_examples) with: lines = s.splitlines() + [''] The reason for the "+ ['']" is that the behavior of s.splitlines() is subtly different from s.split("\n"): splitlines() doesn't return a final null string at the end of, say, "one\ntwo\n", whereas split("\n") does. (Is this difference of behavior a bug? If not, should it be described in the docs?) The "+ ['']" also circumvents errors when the docstring doesn't end with a newline, ie: """ >>> print 'hi' hi""" ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2001-07-12 21:29 Message: Logged In: YES user_id=7733 I'm doing MacOS-based cross-platform development. I like to keep the working files with Mac line-endings. So I run this "test_all" script on Windows: python -c 'import compileall; compileall.compile_dir(".")' python test_utils.pyc ... If test_utils.py has \r line endings, docstrings in test_utils.pyc also end up with \r line endings. (The .pyc's are generated on Windows, from Mac-format .py files.) This breaks doctest. Perhaps compileall.py is the module with the bug? Or is my approach flawed or too rare to merit attention? :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-12 13:54 Message: Logged In: YES user_id=6380 I experimented (on Windows) and looked at the source some more, and I cannot see how a \r could ever have ended up in the .pyc file for a newline, no matter how or where the .pyc file was written. The only other theory that might explain what you see is that when you transfered the .pyc file from Windows to Mac, \n got translated into \r. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-12 13:27 Message: Logged In: YES user_id=6380 I'll have to look into this more, but I strongly recommend against fixing doctest in the way you suggest. The bug must somehow be in the portability of .pyc files. I'm surprised that string literals compiled on Windows contain \r in the .pyc file. Are you *sure* this is what causes your problem? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440707&group_id=5470 From noreply@sourceforge.net Fri Jul 13 09:40:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Jul 2001 01:40:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-440961 ] UnboundLocalError. Message-ID: Bugs item #440961, was opened at 2001-07-13 01:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440961&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: UnboundLocalError. Initial Comment: I compiled and installed python1.6 in my Debian Linux 2.14 without any errors but when I tried to run python I got the following message: Built-in exception class not found: UnboundLocalError. Library mismatch? Fatal Python error: Standard exceptions could not be initialized. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440961&group_id=5470 From noreply@sourceforge.net Fri Jul 13 10:30:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Jul 2001 02:30:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-440707 ] doctest crashes on cross-platform .pyc Message-ID: Bugs item #440707, was opened at 2001-07-12 08:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440707&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Nobody/Anonymous (nobody) Summary: doctest crashes on cross-platform .pyc Initial Comment: doctest.py raises an exception when run on true cross- platform .pyc files (i.e., MacOS .py compiled with compileall.compile_dir on Windows). The problem is, _extract_examples splits up __doc__ strings with: lines = s.split("\n") MacOS-compiled-on-Windows .pyc __doc__ strings contain \r, not \n. The fix is to replace the line above (line 5 of _extract_examples) with: lines = s.splitlines() + [''] The reason for the "+ ['']" is that the behavior of s.splitlines() is subtly different from s.split("\n"): splitlines() doesn't return a final null string at the end of, say, "one\ntwo\n", whereas split("\n") does. (Is this difference of behavior a bug? If not, should it be described in the docs?) The "+ ['']" also circumvents errors when the docstring doesn't end with a newline, ie: """ >>> print 'hi' hi""" ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-13 02:30 Message: Logged In: YES user_id=31435 Which version of Python are you using? Guido is baffled (as am I) because a modern py_compile.py (which produces the .pyc files) contains these lines: f = open(file) codestring = f.read() codestring = codestring.replace("\r\n","\n") codestring = codestring.replace("\r","\n") That is, there's simply no way a carriage return can survive. The checkin comment that introduced this hack (it's "a hack" because Python doesn't *generally* try to support non-native line conventions -- you're skating on the edge here at best) reads: revision 1.16 date: 2000/09/15 06:57:26; author: loewis; state: Exp; lines: +5 -0 Support \r in source files. Closes bug #101425. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2001-07-12 21:29 Message: Logged In: YES user_id=7733 I'm doing MacOS-based cross-platform development. I like to keep the working files with Mac line-endings. So I run this "test_all" script on Windows: python -c 'import compileall; compileall.compile_dir(".")' python test_utils.pyc ... If test_utils.py has \r line endings, docstrings in test_utils.pyc also end up with \r line endings. (The .pyc's are generated on Windows, from Mac-format .py files.) This breaks doctest. Perhaps compileall.py is the module with the bug? Or is my approach flawed or too rare to merit attention? :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-12 13:54 Message: Logged In: YES user_id=6380 I experimented (on Windows) and looked at the source some more, and I cannot see how a \r could ever have ended up in the .pyc file for a newline, no matter how or where the .pyc file was written. The only other theory that might explain what you see is that when you transfered the .pyc file from Windows to Mac, \n got translated into \r. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-12 13:27 Message: Logged In: YES user_id=6380 I'll have to look into this more, but I strongly recommend against fixing doctest in the way you suggest. The bug must somehow be in the portability of .pyc files. I'm surprised that string literals compiled on Windows contain \r in the .pyc file. Are you *sure* this is what causes your problem? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440707&group_id=5470 From noreply@sourceforge.net Fri Jul 13 11:00:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Jul 2001 03:00:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-437487 ] 2.1 build on Solaris fails if CC is set Message-ID: Bugs item #437487, was opened at 2001-06-29 15:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437487&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: A.M. Kuchling (akuchling) Summary: 2.1 build on Solaris fails if CC is set Initial Comment: If you have CC set to "gcc", then the "setup.py" script compiles the extensions incorrectly (in particular, the "-fPIC" on the compile is not used): ... PYTHONPATH= ./python ./setup.py build running build running build_ext building 'struct' extension creating build creating build/temp.solaris-2.7-sun4u-2.1 gcc -I. -I/extra/Python-2.1/./Include -I/usr/local/include -IInclude/ -c /extra/Python-2.1/Modules/structmodule.c -o build/temp.solaris-2.7-sun4u-2.1/structmodule.o creating build/lib.solaris-2.7-sun4u-2.1 gcc -shared build/temp.solaris-2.7-sun4u-2.1/structmodule.o -L/usr/local/lib -o build/lib.solaris-2.7-sun4u-2.1/struct.so Text relocation remains referenced against symbol offset in file 0x2094 build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x200c build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x3398 build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x2098 build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x2070 build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x206c .... If you want to compile code configured via "configure" with the "gcc" compiler and you have both the "gcc" and the Sun C compiler installed on your system, then you need to have the environment variable "CC" set to "gcc": CC=gcc So people (like myself) have "CC=gcc" in their .profile or equivalent in .login, and have had that for years without thinking about it. If you don't have "CC=gcc" set in your environment, then things work fine: ... PYTHONPATH= ./python ./setup.py build running build running build_ext building 'struct' extension creating build creating build/temp.solaris-2.7-sun4u-2.1 gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -I. -I/home/tflagg/projects/python/2.1sunos/Python-2.1/./Include -I/usr/local/include -IInclude/ -c /home/tflagg/projects/python/2.1sunos/Python-2.1/Modules/structmodule.c -o build/temp.solaris-2.7-sun4u-2.1/structmodule.o (In particular, the "-fPIC" flag needs to be there as shown above.) The problem lines in "setup.py" are: 112 # When you run "make CC=altcc" or something similar, you really want 113 # those environment variables passed into the setup.py phase. Here's 114 # a small set of useful ones. 115 compiler = os.environ.get('CC') <---------- 116 linker_so = os.environ.get('LDSHARED') 117 args = {} 118 # unfortunately, distutils doesn't let us provide separate C and C++ 119 # compilers 120 if compiler is not None: <--------------- 121 args['compiler_so'] = compiler <--------- It's true the user may want to set site-specific/user-specific compiler options. However, if "CC" is only "gcc" then the user is trying to communicate: - Use "gcc" rather than Sun's C compiler They are NOT trying to communicate: - Do not use any of the compiler flags for compiling shared objects. The reason this bug Solaris-specific is because Solaris installations are the most likely to have a non-gcc compiler installed, requiring the "CC=gcc" environment variable set. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-13 03:00 Message: Logged In: YES user_id=34209 This works, but I'm not sure if it has any effect... the shared modules were compiling fine before it, except for a few that referenced libraries that itself referenced other shared libraries (I suspect) -- like the readline and socket (with SSL) modules. Disabling SSL makes the socketmodule work okay. I'm not sure what kind of effect this has on applications that embed Python, or that extend Python and want to link to one or more externals libraries... :-P Could it be that distutils is picking up static libraries, and linking them the 'wrong' way ('-llibrary' instead of '/path/to/library.a') ? Note that this Solaris 7 machine is not in real use, and I *might* be running into installation issues... but I don't think so, I thought a colleague had compiled things on it before. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-07-12 09:16 Message: Logged In: YES user_id=11375 The dangers of multiple machines... try this patch, instead. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-12 09:02 Message: Logged In: YES user_id=34209 AMK, I'm running into this problem now, while testing on Solaris 2.7. However, the patch attached here, seems to be the wrong one (it adds checking for sys/poll.h, looks like.) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-07-11 13:09 Message: Logged In: YES user_id=11375 Proposed patch attached; if the original poster is monitoring this bug, please try it and let me know if it helps. Otherwise, I'll check it in in a few days. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437487&group_id=5470 From noreply@sourceforge.net Fri Jul 13 15:51:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Jul 2001 07:51:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-440961 ] UnboundLocalError. Message-ID: Bugs item #440961, was opened at 2001-07-13 01:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440961&group_id=5470 >Category: Installation Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: UnboundLocalError. Initial Comment: I compiled and installed python1.6 in my Debian Linux 2.14 without any errors but when I tried to run python I got the following message: Built-in exception class not found: UnboundLocalError. Library mismatch? Fatal Python error: Standard exceptions could not be initialized. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-13 07:51 Message: Logged In: YES user_id=6380 Sounds like you have an older Python version on your system. Try to get rid of that. Also check $PYTHONPATH. Closing this report, as it's not a bug in Python, but rather an installation problem. (Why are you using Python 1.6?) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440961&group_id=5470 From noreply@sourceforge.net Fri Jul 13 16:11:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Jul 2001 08:11:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-441074 ] Python with Numeric module segfaults Message-ID: Bugs item #441074, was opened at 2001-07-13 08:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441074&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Python with Numeric module segfaults Initial Comment: Python 2.0 (#6, Jan 31 2001, 09:46:47) [C] on sunos5, but I guess the problem is with numeric module. Segmentation fault occurs when trying to run the following code. #!/usr/bin/env python # from Numeric import * from math import * import random N=1000 sigma=fromfunction(lambda x:random.uniform(0.1,3.0),range(N)) # one gets segfault on the above line. # What I meant is said bellow, but I think it should complain # rather than segfault sigma=fromfunction(lambda x:random.uniform(0.1,3.0),(N,)) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441074&group_id=5470 From noreply@sourceforge.net Fri Jul 13 16:21:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Jul 2001 08:21:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-441074 ] Python with Numeric module segfaults Message-ID: Bugs item #441074, was opened at 2001-07-13 08:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441074&group_id=5470 >Category: None >Group: 3rd Party >Status: Closed Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Python with Numeric module segfaults Initial Comment: Python 2.0 (#6, Jan 31 2001, 09:46:47) [C] on sunos5, but I guess the problem is with numeric module. Segmentation fault occurs when trying to run the following code. #!/usr/bin/env python # from Numeric import * from math import * import random N=1000 sigma=fromfunction(lambda x:random.uniform(0.1,3.0),range(N)) # one gets segfault on the above line. # What I meant is said bellow, but I think it should complain # rather than segfault sigma=fromfunction(lambda x:random.uniform(0.1,3.0),(N,)) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-13 08:21 Message: Logged In: YES user_id=6380 This problem is with Numeric. Please use the bug manager for the Numeric project; the core Python developers cannot help you with this. Closing this report. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441074&group_id=5470 From noreply@sourceforge.net Fri Jul 13 17:26:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Jul 2001 09:26:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-440707 ] doctest crashes on cross-platform .pyc Message-ID: Bugs item #440707, was opened at 2001-07-12 08:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440707&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Nobody/Anonymous (nobody) Summary: doctest crashes on cross-platform .pyc Initial Comment: doctest.py raises an exception when run on true cross- platform .pyc files (i.e., MacOS .py compiled with compileall.compile_dir on Windows). The problem is, _extract_examples splits up __doc__ strings with: lines = s.split("\n") MacOS-compiled-on-Windows .pyc __doc__ strings contain \r, not \n. The fix is to replace the line above (line 5 of _extract_examples) with: lines = s.splitlines() + [''] The reason for the "+ ['']" is that the behavior of s.splitlines() is subtly different from s.split("\n"): splitlines() doesn't return a final null string at the end of, say, "one\ntwo\n", whereas split("\n") does. (Is this difference of behavior a bug? If not, should it be described in the docs?) The "+ ['']" also circumvents errors when the docstring doesn't end with a newline, ie: """ >>> print 'hi' hi""" ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2001-07-13 09:26 Message: Logged In: YES user_id=7733 I'm using Python 2.1 final on Win NT 4.0. Try as I might, I can't reproduce yesterday's behavior. (Although you may want to mention in the docs that "Docstrings must end with a newline.") Thanks for your attention, and apologies for time wasted. I was either totally confused, the victim of an environment glitch, or a target of the PSU's time ma ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-13 02:30 Message: Logged In: YES user_id=31435 Which version of Python are you using? Guido is baffled (as am I) because a modern py_compile.py (which produces the .pyc files) contains these lines: f = open(file) codestring = f.read() codestring = codestring.replace("\r\n","\n") codestring = codestring.replace("\r","\n") That is, there's simply no way a carriage return can survive. The checkin comment that introduced this hack (it's "a hack" because Python doesn't *generally* try to support non-native line conventions -- you're skating on the edge here at best) reads: revision 1.16 date: 2000/09/15 06:57:26; author: loewis; state: Exp; lines: +5 -0 Support \r in source files. Closes bug #101425. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2001-07-12 21:29 Message: Logged In: YES user_id=7733 I'm doing MacOS-based cross-platform development. I like to keep the working files with Mac line-endings. So I run this "test_all" script on Windows: python -c 'import compileall; compileall.compile_dir(".")' python test_utils.pyc ... If test_utils.py has \r line endings, docstrings in test_utils.pyc also end up with \r line endings. (The .pyc's are generated on Windows, from Mac-format .py files.) This breaks doctest. Perhaps compileall.py is the module with the bug? Or is my approach flawed or too rare to merit attention? :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-12 13:54 Message: Logged In: YES user_id=6380 I experimented (on Windows) and looked at the source some more, and I cannot see how a \r could ever have ended up in the .pyc file for a newline, no matter how or where the .pyc file was written. The only other theory that might explain what you see is that when you transfered the .pyc file from Windows to Mac, \n got translated into \r. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-12 13:27 Message: Logged In: YES user_id=6380 I'll have to look into this more, but I strongly recommend against fixing doctest in the way you suggest. The bug must somehow be in the portability of .pyc files. I'm surprised that string literals compiled on Windows contain \r in the .pyc file. Are you *sure* this is what causes your problem? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440707&group_id=5470 From noreply@sourceforge.net Fri Jul 13 17:29:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Jul 2001 09:29:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-440707 ] doctest crashes on cross-platform .pyc Message-ID: Bugs item #440707, was opened at 2001-07-12 08:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440707&group_id=5470 >Category: Windows >Group: Irreproducible >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Nobody/Anonymous (nobody) Summary: doctest crashes on cross-platform .pyc Initial Comment: doctest.py raises an exception when run on true cross- platform .pyc files (i.e., MacOS .py compiled with compileall.compile_dir on Windows). The problem is, _extract_examples splits up __doc__ strings with: lines = s.split("\n") MacOS-compiled-on-Windows .pyc __doc__ strings contain \r, not \n. The fix is to replace the line above (line 5 of _extract_examples) with: lines = s.splitlines() + [''] The reason for the "+ ['']" is that the behavior of s.splitlines() is subtly different from s.split("\n"): splitlines() doesn't return a final null string at the end of, say, "one\ntwo\n", whereas split("\n") does. (Is this difference of behavior a bug? If not, should it be described in the docs?) The "+ ['']" also circumvents errors when the docstring doesn't end with a newline, ie: """ >>> print 'hi' hi""" ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-13 09:29 Message: Logged In: YES user_id=6380 OK, closing this bug. Curious: how do you transfer files between Mac & Win? ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2001-07-13 09:26 Message: Logged In: YES user_id=7733 I'm using Python 2.1 final on Win NT 4.0. Try as I might, I can't reproduce yesterday's behavior. (Although you may want to mention in the docs that "Docstrings must end with a newline.") Thanks for your attention, and apologies for time wasted. I was either totally confused, the victim of an environment glitch, or a target of the PSU's time ma ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-13 02:30 Message: Logged In: YES user_id=31435 Which version of Python are you using? Guido is baffled (as am I) because a modern py_compile.py (which produces the .pyc files) contains these lines: f = open(file) codestring = f.read() codestring = codestring.replace("\r\n","\n") codestring = codestring.replace("\r","\n") That is, there's simply no way a carriage return can survive. The checkin comment that introduced this hack (it's "a hack" because Python doesn't *generally* try to support non-native line conventions -- you're skating on the edge here at best) reads: revision 1.16 date: 2000/09/15 06:57:26; author: loewis; state: Exp; lines: +5 -0 Support \r in source files. Closes bug #101425. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2001-07-12 21:29 Message: Logged In: YES user_id=7733 I'm doing MacOS-based cross-platform development. I like to keep the working files with Mac line-endings. So I run this "test_all" script on Windows: python -c 'import compileall; compileall.compile_dir(".")' python test_utils.pyc ... If test_utils.py has \r line endings, docstrings in test_utils.pyc also end up with \r line endings. (The .pyc's are generated on Windows, from Mac-format .py files.) This breaks doctest. Perhaps compileall.py is the module with the bug? Or is my approach flawed or too rare to merit attention? :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-12 13:54 Message: Logged In: YES user_id=6380 I experimented (on Windows) and looked at the source some more, and I cannot see how a \r could ever have ended up in the .pyc file for a newline, no matter how or where the .pyc file was written. The only other theory that might explain what you see is that when you transfered the .pyc file from Windows to Mac, \n got translated into \r. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-12 13:27 Message: Logged In: YES user_id=6380 I'll have to look into this more, but I strongly recommend against fixing doctest in the way you suggest. The bug must somehow be in the portability of .pyc files. I'm surprised that string literals compiled on Windows contain \r in the .pyc file. Are you *sure* this is what causes your problem? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440707&group_id=5470 From noreply@sourceforge.net Fri Jul 13 18:41:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Jul 2001 10:41:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-440707 ] doctest crashes on cross-platform .pyc Message-ID: Bugs item #440707, was opened at 2001-07-12 08:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440707&group_id=5470 Category: Windows Group: Irreproducible Status: Closed Resolution: Works For Me Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Nobody/Anonymous (nobody) Summary: doctest crashes on cross-platform .pyc Initial Comment: doctest.py raises an exception when run on true cross- platform .pyc files (i.e., MacOS .py compiled with compileall.compile_dir on Windows). The problem is, _extract_examples splits up __doc__ strings with: lines = s.split("\n") MacOS-compiled-on-Windows .pyc __doc__ strings contain \r, not \n. The fix is to replace the line above (line 5 of _extract_examples) with: lines = s.splitlines() + [''] The reason for the "+ ['']" is that the behavior of s.splitlines() is subtly different from s.split("\n"): splitlines() doesn't return a final null string at the end of, say, "one\ntwo\n", whereas split("\n") does. (Is this difference of behavior a bug? If not, should it be described in the docs?) The "+ ['']" also circumvents errors when the docstring doesn't end with a newline, ie: """ >>> print 'hi' hi""" ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2001-07-13 10:41 Message: Logged In: YES user_id=7733 GvR> Curious: how do you transfer files between Mac & Win? The old-fashioned way: by floppy disk. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-13 09:29 Message: Logged In: YES user_id=6380 OK, closing this bug. Curious: how do you transfer files between Mac & Win? ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2001-07-13 09:26 Message: Logged In: YES user_id=7733 I'm using Python 2.1 final on Win NT 4.0. Try as I might, I can't reproduce yesterday's behavior. (Although you may want to mention in the docs that "Docstrings must end with a newline.") Thanks for your attention, and apologies for time wasted. I was either totally confused, the victim of an environment glitch, or a target of the PSU's time ma ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-13 02:30 Message: Logged In: YES user_id=31435 Which version of Python are you using? Guido is baffled (as am I) because a modern py_compile.py (which produces the .pyc files) contains these lines: f = open(file) codestring = f.read() codestring = codestring.replace("\r\n","\n") codestring = codestring.replace("\r","\n") That is, there's simply no way a carriage return can survive. The checkin comment that introduced this hack (it's "a hack" because Python doesn't *generally* try to support non-native line conventions -- you're skating on the edge here at best) reads: revision 1.16 date: 2000/09/15 06:57:26; author: loewis; state: Exp; lines: +5 -0 Support \r in source files. Closes bug #101425. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2001-07-12 21:29 Message: Logged In: YES user_id=7733 I'm doing MacOS-based cross-platform development. I like to keep the working files with Mac line-endings. So I run this "test_all" script on Windows: python -c 'import compileall; compileall.compile_dir(".")' python test_utils.pyc ... If test_utils.py has \r line endings, docstrings in test_utils.pyc also end up with \r line endings. (The .pyc's are generated on Windows, from Mac-format .py files.) This breaks doctest. Perhaps compileall.py is the module with the bug? Or is my approach flawed or too rare to merit attention? :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-12 13:54 Message: Logged In: YES user_id=6380 I experimented (on Windows) and looked at the source some more, and I cannot see how a \r could ever have ended up in the .pyc file for a newline, no matter how or where the .pyc file was written. The only other theory that might explain what you see is that when you transfered the .pyc file from Windows to Mac, \n got translated into \r. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-12 13:27 Message: Logged In: YES user_id=6380 I'll have to look into this more, but I strongly recommend against fixing doctest in the way you suggest. The bug must somehow be in the portability of .pyc files. I'm surprised that string literals compiled on Windows contain \r in the .pyc file. Are you *sure* this is what causes your problem? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440707&group_id=5470 From noreply@sourceforge.net Fri Jul 13 19:02:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Jul 2001 11:02:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-440707 ] doctest crashes on cross-platform .pyc Message-ID: Bugs item #440707, was opened at 2001-07-12 08:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440707&group_id=5470 Category: Windows Group: Irreproducible Status: Closed Resolution: Works For Me Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Nobody/Anonymous (nobody) Summary: doctest crashes on cross-platform .pyc Initial Comment: doctest.py raises an exception when run on true cross- platform .pyc files (i.e., MacOS .py compiled with compileall.compile_dir on Windows). The problem is, _extract_examples splits up __doc__ strings with: lines = s.split("\n") MacOS-compiled-on-Windows .pyc __doc__ strings contain \r, not \n. The fix is to replace the line above (line 5 of _extract_examples) with: lines = s.splitlines() + [''] The reason for the "+ ['']" is that the behavior of s.splitlines() is subtly different from s.split("\n"): splitlines() doesn't return a final null string at the end of, say, "one\ntwo\n", whereas split("\n") does. (Is this difference of behavior a bug? If not, should it be described in the docs?) The "+ ['']" also circumvents errors when the docstring doesn't end with a newline, ie: """ >>> print 'hi' hi""" ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-13 11:02 Message: Logged In: YES user_id=6380 Thenk I stick to my theory that somehow the .pyc files went through a file conversion process that "helpfully" translated \n to \r... ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2001-07-13 10:41 Message: Logged In: YES user_id=7733 GvR> Curious: how do you transfer files between Mac & Win? The old-fashioned way: by floppy disk. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-13 09:29 Message: Logged In: YES user_id=6380 OK, closing this bug. Curious: how do you transfer files between Mac & Win? ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2001-07-13 09:26 Message: Logged In: YES user_id=7733 I'm using Python 2.1 final on Win NT 4.0. Try as I might, I can't reproduce yesterday's behavior. (Although you may want to mention in the docs that "Docstrings must end with a newline.") Thanks for your attention, and apologies for time wasted. I was either totally confused, the victim of an environment glitch, or a target of the PSU's time ma ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-13 02:30 Message: Logged In: YES user_id=31435 Which version of Python are you using? Guido is baffled (as am I) because a modern py_compile.py (which produces the .pyc files) contains these lines: f = open(file) codestring = f.read() codestring = codestring.replace("\r\n","\n") codestring = codestring.replace("\r","\n") That is, there's simply no way a carriage return can survive. The checkin comment that introduced this hack (it's "a hack" because Python doesn't *generally* try to support non-native line conventions -- you're skating on the edge here at best) reads: revision 1.16 date: 2000/09/15 06:57:26; author: loewis; state: Exp; lines: +5 -0 Support \r in source files. Closes bug #101425. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2001-07-12 21:29 Message: Logged In: YES user_id=7733 I'm doing MacOS-based cross-platform development. I like to keep the working files with Mac line-endings. So I run this "test_all" script on Windows: python -c 'import compileall; compileall.compile_dir(".")' python test_utils.pyc ... If test_utils.py has \r line endings, docstrings in test_utils.pyc also end up with \r line endings. (The .pyc's are generated on Windows, from Mac-format .py files.) This breaks doctest. Perhaps compileall.py is the module with the bug? Or is my approach flawed or too rare to merit attention? :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-12 13:54 Message: Logged In: YES user_id=6380 I experimented (on Windows) and looked at the source some more, and I cannot see how a \r could ever have ended up in the .pyc file for a newline, no matter how or where the .pyc file was written. The only other theory that might explain what you see is that when you transfered the .pyc file from Windows to Mac, \n got translated into \r. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-12 13:27 Message: Logged In: YES user_id=6380 I'll have to look into this more, but I strongly recommend against fixing doctest in the way you suggest. The bug must somehow be in the portability of .pyc files. I'm surprised that string literals compiled on Windows contain \r in the .pyc file. Are you *sure* this is what causes your problem? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440707&group_id=5470 From noreply@sourceforge.net Fri Jul 13 21:35:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Jul 2001 13:35:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-441172 ] Tree Widget does not cancell entry Message-ID: Bugs item #441172, was opened at 2001-07-13 13:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441172&group_id=5470 Category: IDLE Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Tree Widget does not cancell entry Initial Comment: Tree Widget in Idle does not cancell properly. Pressing escape validates the entry even though the proper funciton is called. I'm running it on both Red Hat, and OpenBSD. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441172&group_id=5470 From noreply@sourceforge.net Fri Jul 13 21:42:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Jul 2001 13:42:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-441172 ] Tree Widget does not cancell entry Message-ID: Bugs item #441172, was opened at 2001-07-13 13:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441172&group_id=5470 Category: IDLE >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Tree Widget does not cancell entry Initial Comment: Tree Widget in Idle does not cancell properly. Pressing escape validates the entry even though the proper funciton is called. I'm running it on both Red Hat, and OpenBSD. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-13 13:42 Message: Logged In: YES user_id=6380 Please provide more information. Are you writing code that uses the tree widget, or are you simply using IDLE? If the former, please show us your code. If the latter, which window did you have open? In either case, please tell us in more detail what you did, what you expected, and what happened instead. Also, please let us know what Pythin version and what IDLE version. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441172&group_id=5470 From noreply@sourceforge.net Fri Jul 13 22:51:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Jul 2001 14:51:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn Message-ID: Bugs item #417845, was opened at 2001-04-21 08:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: Python 2.1: SocketServer.ThreadingMixIn Initial Comment: SocketServer.ThreadingMixIn does not work properly since it tries to close the socket of a request two times. Workaround for using SocketServer.ThreadingMixIn under Python 2.1: class MyThreadingHTTPServer( SocketServer.ThreadingMixIn, MyHTTPServer ): def close_request(self, request): pass ---------------------------------------------------------------------- Comment By: Stian Soiland (stain) Date: 2001-07-13 14:51 Message: Logged In: YES user_id=25921 I don't think it's a good idea to let closing the request be the handler's responsibility. It's better to let the ThreadingMixIn do it: stain@zoidberg:~$ diff -u SocketServer-cvs-1.24.2.1.py SocketServer.py --- SocketServer-cvs-1.24.2.1.py Fri Jul 13 23:20:26 2001 +++ SocketServer.py Fri Jul 13 23:34:02 2001 @@ -451,8 +451,10 @@ def process_request(self, request, client_address): """Start a new thread to process the request.""" import threading - t = threading.Thread(target = self.finish_request, - args = (request, client_address)) + # Call the BaseServers process_request to close the + # socket after finally_request. + t = threading.Thread(target = BaseServer.process_request, + args = (self, request, client_address)) t.start() In my eyes this is the best, making the overriden process_request behaving like the original process_request. This would make the difference between Threading-servers and other servers smaller. If it looks bad with BaseServer-references inside ThreadingMixIn, what about a method of ThreadingMixIn named __process_request with the same code as BaseServer.process_request? -- Stian Soiland ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-07-11 14:45 Message: Logged In: YES user_id=7887 Ohh, I'm sorry. I've read comments the other way around. The last comment seemed to be the one at bottom (as usual), then it looked like it was not definetly fixed. I'll checkout the fix from cvs. Thanks! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 14:22 Message: Logged In: YES user_id=6380 Gustavo, yes it's fixed in CVS (just read on and you;ll see my announcement). We're going to release a bugfix update release for Python 2.1, Python 2.1.1 soon, and it will be in that release too. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-07-11 14:19 Message: Logged In: YES user_id=7887 Just wondering, is this bug fixed somewhere (cvs, etc)?? Python 2.1 + SOAP.py seem to have this problem, when using the ThreadingTCPServer. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 06:59 Message: Logged In: YES user_id=6380 Yes, the thread is responsible for calling self.close_request() in self.finish_request(). (Although if you just rely on reference counting, it should go away all by itself too.) I don't read the newsgroup frequently, but you can try email if you have more problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-10 05:47 Message: Logged In: NO I tried the fix and it seems to work. I'm wondering if the thread is responsible for calling self.close_request() in self.finish_request? Note: Can we discuss it in news:comp.lang.python? I hate that web interface with Cookies! That's the reason why I was too lazy to login when submitting this bug report. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 04:59 Message: Logged In: YES user_id=6380 I've developed a proper fix for this, I hope. Check out the latest SocketServer.py from the CVS tree. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-07-02 09:05 Message: Logged In: YES user_id=198402 There is still a problem with your solution, Mr glchapman: you make a copy to ensure that the server won't close the copy of the socket that is used in the child thread. Right. But WHO will close this very copy then? The thread still has to close it if one wants to be "clean". So as long as the child thread must close its copy in the threading case, why not make it a thumb rule? Why should we bother about closing anything in the main thread? I still think the solution that I provide is best: make the request handler always responsible for closing the socket from which the request comes. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2001-06-29 08:49 Message: Logged In: YES user_id=86307 Since the request socket object is only a lightweight wrapper around the real socket, why not simply pass request.dup() to the new thread? Then the server's call to close_request affects only its copy of request, not the copy being used in the thread. For example, the following change to ThreadingMixIn fixed this bug for me in a (very simple) test program: def process_request(self, request, client_address): """Start a new thread to process the request.""" import threading t = threading.Thread(target = self.finish_request, args = (request.dup(), client_address)) t.start() ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-28 05:20 Message: Logged In: YES user_id=198402 I have now started a project here concerning a SOCKS proxy written in python (PySocks). It is aimed mostly at people who use a windows box to share their internet connection and uses the threading server from the SocketServer module. So it becomes VERY important to me to know of what will be done about this bug, in the next release/patch of Python library. Could Mr Guido Vanrossum tell us about it? As for now I am forced to provide my patched version of SocketServer.py with my releases, what is not quite satisfactory. SocketServer is provided in the python distribution, so I'd rather tell "there is a patch for python..." Well... In fact I forgot to put it in my first release, but I'll correct this this evening :) ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-20 12:06 Message: Logged In: YES user_id=198402 Well I was wrong. We do need a "try" block to ensure the request is always correctly closed: def finish_request(self, request, client_address): """Finish one request by instantiating RequestHandlerClass.""" try: self.RequestHandlerClass(request, client_address, self) finally: self.close_request(request) This works better. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-13 09:09 Message: Logged In: YES user_id=198402 I forgot to tell: I can not test if it does not break the forking server. I only have a windows platform available for now, and forking doesn't work in the python/win32 environment for now as far as I know. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-13 08:51 Message: Logged In: YES user_id=198402 What I propose can be applied without any compatibility issue. I have tried something that seems to work, at least under windows (but it does need to be more fully tested though). Only 2 small modifications are required: -1- In BaseServer, modification of the last line of handle_request: 
    def handle_request(self):
        """Handle one request, possibly blocking."""
        #import time
        try:
            request, client_address = self.get_request()
        except socket.error:
            return
        if self.verify_request(request, client_address):
            try:
                print 'handle 1'
                self.process_request(request, 
client_address)
                print 'handle 2'
            except:
                self.handle_error(request, client_address)
                self.close_request(request)
Note that only the indentation of the last has been modified so that the close_request is executed only if an exception occur. Still we need to close the request after it had been processed, so here comes the second modification: -2- Still in BaseServer: 
    def finish_request(self, request, client_address):
        """Finish one request by instantiating 
RequestHandlerClass."""
        self.RequestHandlerClass(request, client_address, 
self)
        self.close_request(request)
There is already a try/except block in handle_request, so I thought it was not mandatory here to ensure the request was always closed. Oh... I don't know how <PRE> tags are supported by the bugtracking system of sourceforge, so the samples I give may not appear as I want. This is quite a problem with python :/ ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-12 15:46 Message: Logged In: YES user_id=80200 hi there mr xlagraula, yes, it would be a lot simpler... _if_ it wasn't for the fact that this code is likely to already be quite extensively used. a possible 'upgrade' path could be done by providing a... RequestHandler2 class, or some-such. it would be neater to do this, or similar: for t in self.thread_list: t.join(timeout=0.1) which would join all threads, or you do if stopped(), close_request. i looked into threads a bit more: join has a timeout, and there is a stopped-detection function. easy :) ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-12 14:18 Message: Logged In: YES user_id=198402 Another solution could be to modify the behaviour of the server so that it would be the responsibility of the "child" thread/process to close the socket (except for the forking/threading error cases). Wouldn't it be simplier than child process tracking and thread tracking? ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-04 04:17 Message: Logged In: YES user_id=80200 okay. the forkingmixin code does a fork, records how many children there are, and waits for one of them to exit, before proceeding - in particular, before proceeding to close the request, etc. ... so why is not something similar done in ThreadingMixIn? this kinda- tells me that thread-tracking is really needed, in a similar way to that in forkingmixin. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2001-05-03 16:26 Message: Logged In: YES user_id=413 Just a note of another casualty of this bug: I had to add the mentioned dummy close_request method hack to our own ThreadingMixIn class in mojo nation (in the sourceforge mojonation project's evil module, see the common/MojoNationHTTPServer.py file). Without it, python 2.1 would always raise an exception in the request handler as soon as it tried to call self.connection.makefile() because self.connection had apparently already been closed! (its fd was always -1) ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-02 01:41 Message: Logged In: YES user_id=80200 hi there mr jrielh, thank you very much for the details. what i am having a little difficulty with is, what's the difference between this and python 2.0 SocketServer.py? more specifically, i'm looking at python 2.0 SocketServer.py and, whilst i'm not a Threads expert, i see a t.start() but no t.join(). i've been looking at the Queue example code in the test method of threads.py, and start() is called on every thread, followed by join() on every thread. join waits for the thread to finish, yes? so... if that's the case, then python 2.0 SocketServer.py should suffer from exactly the same behaviour, yes? unless python behaves ever-so-slightly differently (timing issues?) when you have an extra base class like this, with the consequence that close_request() is more likely to be called before ThreadingMixIn.process_request(). ? ---------------------------------------------------------------------- Comment By: Jon Riehl (jriehl) Date: 2001-05-01 14:20 Message: Logged In: YES user_id=22448 This is related to bug #419873. The problem is not specifically in the ThreadingMixin specifically, but where BaseServer calls close_request() after calling process_request(). In the threading mixin, process_request() spins the thread and returns, causing the request socket to be invalidated while the thread is still running. The fix given above will keep the socket valid while the thread is running, but may cause the socket to not close properly (my threads generally close the socket when they are done anyway.) ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-04-26 05:41 Message: Logged In: YES user_id=80200 follow-up. i took a look at the differences between SocketServer.py in 2.0 and 2.1. there is one small change by guido to the ThreadingMixIn.process_request() function that calls self.server_close() instead of explicitly calling self.socket.close(), where TCPServer.server_close() calls self.socket.close(). if mr anonymous (hi!) has over-ridden server_close() and explicitly closes the *request* socket, then of course the socket will get closed twice. the rest of the code-mods is a straightforward code-shuffle moving code from TCPServer into BaseServer: from examining the diff, i really don't see how bypassing close_request(), as shown above with the Workaround in the original bug-report, will help: that will in fact cause the request _never_ to be closed! the rest of this report is part of an email exchange with guido, quoted here: "the bug-report doesn't state whether python 2.0 worked and 2.1 didn't: it also doesn't give enough info. for all we know, he's calling close_request() himself or request.close() directly somewhere in his code, and hasn't told anybody, which is why he has to over-ride close_request() and tell it to do nothing. or he's closing the socket in the HandlerClass, in finish(), or something. we just don't know. either that, or his HandlerClass creates a socket once and only once, with the result that close_request() closes the one socket, and he's _completely_ stuffed, then :)" ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-04-26 04:11 Message: Logged In: YES user_id=80200 hi there, i'm the person who wrote the BaseServer class. guido contacted me about it: could you please send me or post here a working test example that demonstrates the problem. i assume, but you do not state, that you have tested your MyHTTPServer with python 2.0, please let us know, here, if that is a correct assumption. thanks! luke ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470 From noreply@sourceforge.net Fri Jul 13 23:26:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Jul 2001 15:26:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-441172 ] Tree Widget does not cancell entry Message-ID: Bugs item #441172, was opened at 2001-07-13 13:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441172&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Tree Widget does not cancell entry Initial Comment: Tree Widget in Idle does not cancell properly. Pressing escape validates the entry even though the proper funciton is called. I'm running it on both Red Hat, and OpenBSD. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-13 15:26 Message: Logged In: NO Apparently I have forgotten a few things. I've tried it both with Python2.0 and 2.1. Idle 0.6 I am writing my own code that extends the Tree Widget but the easiest way to reproduce the error is to: import TreeWidget TreeWidget.test2() Try to change the name of one of the files and press 'escape' to get out of it. The name still gets changed. (the widget still calls edit_cancel but it doesn't get the previous entry??) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-13 13:42 Message: Logged In: YES user_id=6380 Please provide more information. Are you writing code that uses the tree widget, or are you simply using IDLE? If the former, please show us your code. If the latter, which window did you have open? In either case, please tell us in more detail what you did, what you expected, and what happened instead. Also, please let us know what Pythin version and what IDLE version. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441172&group_id=5470 From noreply@sourceforge.net Sat Jul 14 04:08:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Jul 2001 20:08:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-440911 ] typo in xor docs Message-ID: Bugs item #440911, was opened at 2001-07-12 20:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440911&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: typo in xor docs Initial Comment: In the following text (from http://www.python.org/doc/current/api/number.html): PyObject* PyNumber_InPlaceXor(PyObject *o1, PyObject *o2) Return value: New reference. Returns the ``bitwise exclusive or'' of o1 by o2 on success, or NULL on failure. The operation is done in- place when o1 supports it. This is the equivalent of the Python expression "o1 = o2". I think the Python expression should be "o1 ^= o2" ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-13 20:08 Message: Logged In: YES user_id=3066 This was a markup error; LaTeX swallow the caret character. ;-( Fixed in Doc/api/api.tex revisions 1.132 and 1.117.2.10. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440911&group_id=5470 From noreply@sourceforge.net Sat Jul 14 12:11:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Jul 2001 04:11:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-441279 ] ConfigParser.options return default opts Message-ID: Bugs item #441279, was opened at 2001-07-14 04:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441279&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: eXom (jkuan) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser.options return default opts Initial Comment: I have a config file which has the following sections ------------------ [DEFAULT] logLevel = 9 port = 17870 [SECURITY] user = hello ------------------- On python, if I do the followings: Python 2.0 (#1, Oct 16 2000, 18:10:03) [GCC 2.95.2 19991024 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from ConfigParser import * >>> f = open('/tmp/testrc', 'r') >>> a = ConfigParser() >>> a.defaults() {} >>> a.readfp(f) >>> a.defaults() {'port': '17870', 'loglevel': '9'} >>> a.options("SECURITY") ['port', 'user', 'loglevel'] <<<<<<<>> I thought a.options("SECURITY") will only return ['user'], however it returns everything including the default options. I am a bit confused. Thanks Joe ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441279&group_id=5470 From noreply@sourceforge.net Sat Jul 14 19:08:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Jul 2001 11:08:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-441314 ] __init__ not callable if non existant. Message-ID: Bugs item #441314, was opened at 2001-07-14 11:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441314&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Cogdon (chriscog) Assigned to: Nobody/Anonymous (nobody) Summary: __init__ not callable if non existant. Initial Comment: "Good OO programming" dictates that one should never rely on the base class you are inheriting from to not change. To this end, if I was to have a class C inheriting from B, and was to write my own __init__ method, then I should also call B's __init__ method too. Viz: class C (B): def __init__ ( self, some_args_for_C ): B.__init__ ( self ) Unfortuantely, if B does not have a __init__ method, then instantiating C will cause an AttributeError. This makes sense, of course, but it does mean that if B is ever changed to include a __init__ method, then /every/ class that derives from B, directly or indirectly, and has their own __init__ methods, have to be modified to call their immediate base class' __init__ method. This is Bad. The rule should be: if you inherit, and have your own __init__ method, then you should call your base class' __init__ method in your own __init__. The python interpreter should be modified to allow this 'forsight' in OO programming. Suggest somehow special-casing calls to __init__ so that the exception is suppressed, and is simply a NOOP. I appreciate that, in reality, it's getattr that needs to be special-cased, and have it return a NOOP function. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441314&group_id=5470 From noreply@sourceforge.net Sat Jul 14 19:15:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Jul 2001 11:15:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-441314 ] __init__ not callable if non existant. Message-ID: Bugs item #441314, was opened at 2001-07-14 11:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441314&group_id=5470 Category: Python Interpreter Core >Group: Feature Request >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Chris Cogdon (chriscog) >Assigned to: Guido van Rossum (gvanrossum) Summary: __init__ not callable if non existant. Initial Comment: "Good OO programming" dictates that one should never rely on the base class you are inheriting from to not change. To this end, if I was to have a class C inheriting from B, and was to write my own __init__ method, then I should also call B's __init__ method too. Viz: class C (B): def __init__ ( self, some_args_for_C ): B.__init__ ( self ) Unfortuantely, if B does not have a __init__ method, then instantiating C will cause an AttributeError. This makes sense, of course, but it does mean that if B is ever changed to include a __init__ method, then /every/ class that derives from B, directly or indirectly, and has their own __init__ methods, have to be modified to call their immediate base class' __init__ method. This is Bad. The rule should be: if you inherit, and have your own __init__ method, then you should call your base class' __init__ method in your own __init__. The python interpreter should be modified to allow this 'forsight' in OO programming. Suggest somehow special-casing calls to __init__ so that the exception is suppressed, and is simply a NOOP. I appreciate that, in reality, it's getattr that needs to be special-cased, and have it return a NOOP function. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-14 11:15 Message: Logged In: YES user_id=6380 Good point. In the short term, it's best to make sure that the author of B defines an empty __init__. In the long term, I'm working on redoing the class definition machinery to allow subclassing built-in types, and there will be a universal base class, 'object', whose __init__ you will automatically inherit. See PEP 253 (warning: unfinished!). I'm closing this issue, because I don't think I want to do something else about this now. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441314&group_id=5470 From noreply@sourceforge.net Sat Jul 14 19:24:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Jul 2001 11:24:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-441314 ] __init__ not callable if non existant. Message-ID: Bugs item #441314, was opened at 2001-07-14 11:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441314&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Closed Resolution: Accepted Priority: 5 Submitted By: Chris Cogdon (chriscog) Assigned to: Guido van Rossum (gvanrossum) Summary: __init__ not callable if non existant. Initial Comment: "Good OO programming" dictates that one should never rely on the base class you are inheriting from to not change. To this end, if I was to have a class C inheriting from B, and was to write my own __init__ method, then I should also call B's __init__ method too. Viz: class C (B): def __init__ ( self, some_args_for_C ): B.__init__ ( self ) Unfortuantely, if B does not have a __init__ method, then instantiating C will cause an AttributeError. This makes sense, of course, but it does mean that if B is ever changed to include a __init__ method, then /every/ class that derives from B, directly or indirectly, and has their own __init__ methods, have to be modified to call their immediate base class' __init__ method. This is Bad. The rule should be: if you inherit, and have your own __init__ method, then you should call your base class' __init__ method in your own __init__. The python interpreter should be modified to allow this 'forsight' in OO programming. Suggest somehow special-casing calls to __init__ so that the exception is suppressed, and is simply a NOOP. I appreciate that, in reality, it's getattr that needs to be special-cased, and have it return a NOOP function. ---------------------------------------------------------------------- >Comment By: Chris Cogdon (chriscog) Date: 2001-07-14 11:24 Message: Logged In: YES user_id=67116 Workaround, and long-term solution work for me. Thanks for the speedy reply! :) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-14 11:15 Message: Logged In: YES user_id=6380 Good point. In the short term, it's best to make sure that the author of B defines an empty __init__. In the long term, I'm working on redoing the class definition machinery to allow subclassing built-in types, and there will be a universal base class, 'object', whose __init__ you will automatically inherit. See PEP 253 (warning: unfinished!). I'm closing this issue, because I don't think I want to do something else about this now. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441314&group_id=5470 From noreply@sourceforge.net Sat Jul 14 21:28:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Jul 2001 13:28:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-437487 ] 2.1 build on Solaris fails if CC is set Message-ID: Bugs item #437487, was opened at 2001-06-29 15:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437487&group_id=5470 Category: Build Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: A.M. Kuchling (akuchling) Summary: 2.1 build on Solaris fails if CC is set Initial Comment: If you have CC set to "gcc", then the "setup.py" script compiles the extensions incorrectly (in particular, the "-fPIC" on the compile is not used): ... PYTHONPATH= ./python ./setup.py build running build running build_ext building 'struct' extension creating build creating build/temp.solaris-2.7-sun4u-2.1 gcc -I. -I/extra/Python-2.1/./Include -I/usr/local/include -IInclude/ -c /extra/Python-2.1/Modules/structmodule.c -o build/temp.solaris-2.7-sun4u-2.1/structmodule.o creating build/lib.solaris-2.7-sun4u-2.1 gcc -shared build/temp.solaris-2.7-sun4u-2.1/structmodule.o -L/usr/local/lib -o build/lib.solaris-2.7-sun4u-2.1/struct.so Text relocation remains referenced against symbol offset in file 0x2094 build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x200c build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x3398 build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x2098 build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x2070 build/temp.solaris-2.7-sun4u-2.1/structmodule.o 0x206c .... If you want to compile code configured via "configure" with the "gcc" compiler and you have both the "gcc" and the Sun C compiler installed on your system, then you need to have the environment variable "CC" set to "gcc": CC=gcc So people (like myself) have "CC=gcc" in their .profile or equivalent in .login, and have had that for years without thinking about it. If you don't have "CC=gcc" set in your environment, then things work fine: ... PYTHONPATH= ./python ./setup.py build running build running build_ext building 'struct' extension creating build creating build/temp.solaris-2.7-sun4u-2.1 gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -I. -I/home/tflagg/projects/python/2.1sunos/Python-2.1/./Include -I/usr/local/include -IInclude/ -c /home/tflagg/projects/python/2.1sunos/Python-2.1/Modules/structmodule.c -o build/temp.solaris-2.7-sun4u-2.1/structmodule.o (In particular, the "-fPIC" flag needs to be there as shown above.) The problem lines in "setup.py" are: 112 # When you run "make CC=altcc" or something similar, you really want 113 # those environment variables passed into the setup.py phase. Here's 114 # a small set of useful ones. 115 compiler = os.environ.get('CC') <---------- 116 linker_so = os.environ.get('LDSHARED') 117 args = {} 118 # unfortunately, distutils doesn't let us provide separate C and C++ 119 # compilers 120 if compiler is not None: <--------------- 121 args['compiler_so'] = compiler <--------- It's true the user may want to set site-specific/user-specific compiler options. However, if "CC" is only "gcc" then the user is trying to communicate: - Use "gcc" rather than Sun's C compiler They are NOT trying to communicate: - Do not use any of the compiler flags for compiling shared objects. The reason this bug Solaris-specific is because Solaris installations are the most likely to have a non-gcc compiler installed, requiring the "CC=gcc" environment variable set. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-07-14 13:28 Message: Logged In: YES user_id=11375 I did verify that this fixes the original submitter's problem, though it may not fix whatever Thomas is running into, so it's been checked in as revision 1.42 of setup.py. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-13 03:00 Message: Logged In: YES user_id=34209 This works, but I'm not sure if it has any effect... the shared modules were compiling fine before it, except for a few that referenced libraries that itself referenced other shared libraries (I suspect) -- like the readline and socket (with SSL) modules. Disabling SSL makes the socketmodule work okay. I'm not sure what kind of effect this has on applications that embed Python, or that extend Python and want to link to one or more externals libraries... :-P Could it be that distutils is picking up static libraries, and linking them the 'wrong' way ('-llibrary' instead of '/path/to/library.a') ? Note that this Solaris 7 machine is not in real use, and I *might* be running into installation issues... but I don't think so, I thought a colleague had compiled things on it before. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-07-12 09:16 Message: Logged In: YES user_id=11375 The dangers of multiple machines... try this patch, instead. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-12 09:02 Message: Logged In: YES user_id=34209 AMK, I'm running into this problem now, while testing on Solaris 2.7. However, the patch attached here, seems to be the wrong one (it adds checking for sys/poll.h, looks like.) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-07-11 13:09 Message: Logged In: YES user_id=11375 Proposed patch attached; if the original poster is monitoring this bug, please try it and let me know if it helps. Otherwise, I'll check it in in a few days. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437487&group_id=5470 From noreply@sourceforge.net Sat Jul 14 21:39:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Jul 2001 13:39:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-417212 ] curses.newwin can return pads Message-ID: Bugs item #417212, was opened at 2001-04-18 19:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417212&group_id=5470 Category: Extension Modules Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David M. Cooke (dmcooke) Assigned to: A.M. Kuchling (akuchling) Summary: curses.newwin can return pads Initial Comment: In 2.1 (at least), curses.newwin can return a pad object if it's called with two arguments, i.e. win = curses.newwin(0,0) Since this is actually a pad, win.refresh has to be called with six arguments -- the syntax used for refreshing a pad -- instead of as just win.refresh() Looking at the code for _cursesmodule.c, it appears that only win.refresh() and win.noutrefresh() take different arguments depending on whether win is actually a window or a pad. It looks like there are three options here: - document that the two-argument version of curses.newwin returns a pad (and hence the six-argument .refresh() must be used) - make curses.newwin take four arguments only (as the two argument version is currently equivalent to newpad) - have win.refresh() and win.noutrefresh() do sensible things for pads (although I don't know what that would be...) I would think #2 is the best. Hmm, perhaps there should be a separate object type for pads, so we can tell the difference between pads and windows. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-07-14 13:39 Message: Logged In: YES user_id=11375 Fixed in rev. 2.53 of _cursesmodule.c, by taking my suggested second course of action and having newwin() never return a pad at all. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-07-11 15:43 Message: Logged In: YES user_id=11375 Hmm... another option would be to just use newwin() instead of newpad(), and set nlines and ncols to zero, making ncurses use the rest of the screen for the window. On reflection, I think I like this solution better because it makes the code reflect the document behaviour. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-07-11 15:36 Message: Logged In: YES user_id=11375 I think I agree with your choice of #2. It's also possible that the newpad() is a typo or cut-and-paste error of some sort; it's been there since Oliver Andrich's original ncurses module. I'll add a warning to the 2-argument newwin(), and it can disappear in Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417212&group_id=5470 From noreply@sourceforge.net Sat Jul 14 21:57:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Jul 2001 13:57:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-438050 ] configure doesn't look for poll.h in sys Message-ID: Bugs item #438050, was opened at 2001-07-02 15:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438050&group_id=5470 Category: Build Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Dyck (dcd) Assigned to: A.M. Kuchling (akuchling) Summary: configure doesn't look for poll.h in sys Initial Comment: I was surprised to see python not build out of the box on this old libc5 system. seems to be a problem with configure finding poll.h If I manually add #include to "Modules/selectmodule.c" then make continues (Another workaround is to create a dummy /usr/include/poll.h that just #include's ) dd:dcd$ uname -a Linux dd 2.4.5-ac22 #2 Fri Jun 29 14:39:29 PDT 2001 i686 /lib/libc.so.5 -> libc.so.5.4.44* make[1]: Entering directory `/hdb2/jd/usr2/dcd/ftp2/python/Python-2.0.1/Modules' gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -I./../Include -I.. -DHAVE_CONFIG_H ./selectmodule.c: In function `update_ufd_array': ./selectmodule.c:319: sizeof applied to an incomplete type ./selectmodule.c:327: arithmetic on pointer to an incomplete type ./selectmodule.c:327: dereferencing pointer to incomplete type configure:1557: checking for poll.h configure:1567: gcc -E conftest.c >/dev/null 2>conftest.out configure:1563: poll.h: No such file or directory configure: failed program was: #line 1562 "configure" #include "confdefs.h" #include ---- ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-07-14 13:57 Message: Logged In: YES user_id=11375 Fixed in configure.in 1.228 and selectmodule.c 2.52. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-07-11 12:22 Message: Logged In: YES user_id=11375 OK. I've attached a patch to this bug that checks for sys/poll.h; can you please try it and let me know if it fixes the problem for you? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438050&group_id=5470 From noreply@sourceforge.net Sat Jul 14 22:02:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Jul 2001 14:02:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-419462 ] python 2.0 compile fails on mandrake 8 Message-ID: Bugs item #419462, was opened at 2001-04-27 05:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419462&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Luke Kenneth Casson Leighton (lkcl) Assigned to: A.M. Kuchling (akuchling) Summary: python 2.0 compile fails on mandrake 8 Initial Comment: bddbmodule fails to compile on mandrake 8. if bdb is not a mandatory module, autoconf should be used to detect that bdb is or is not installed. [it's looking for R_NEXT etc. which don't exist] ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-07-14 14:02 Message: Logged In: YES user_id=11375 Autoconf no longer mucks around with BSDDB at all; it was ripped out for Python 2.1, so this bug can be closed, to be replaced by a multitude of setup.py bugs. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-05-09 08:55 Message: Logged In: YES user_id=31392 I wonder if the builtin bsddb module should be deprecated. The fact that it gets built causes a fair bit of trouble for users of bsddb3, which I assume is the preferred interface. ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-04 04:12 Message: Logged In: YES user_id=80200 update: there is an option in the Modules setup which can be used to explicity disable bddb. however, this, i feel, should be totally unnecessary. why exactly, is autoconf used, when it cannot be told - correctly - not to use bddb? i attempted a compile with --without-bddb (or whatever it was), and it still failed. because there just _happens_ to be a db.h file _somewhere_ on the system, the configure test "assumes" that there is a valid bddb somewhere, which there isn't. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419462&group_id=5470 From noreply@sourceforge.net Sat Jul 14 22:05:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Jul 2001 14:05:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-411127 ] README file for Unix not up to date Message-ID: Bugs item #411127, was opened at 2001-03-24 21:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411127&group_id=5470 Category: Documentation Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: A.M. Kuchling (akuchling) Summary: README file for Unix not up to date Initial Comment: The README file instructions for building Python suggest editing the Modules/Setup directory to select the modules to be built. The new build process automatically builds some of the modules. Is there a reason for leaving the modules in Setup if they are built automatically? Perhaps the introductory paragraph or README should mention the distutil build process. With the rework of the build process is the instructions for using VPATH still valid? ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-07-14 14:05 Message: Logged In: YES user_id=11375 The README now discusses setup.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411127&group_id=5470 From noreply@sourceforge.net Sun Jul 15 00:40:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Jul 2001 16:40:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-441357 ] time.clock() docs wrong for Windows Message-ID: Bugs item #441357, was opened at 2001-07-14 16:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441357&group_id=5470 Category: Documentation Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: time.clock() docs wrong for Windows Initial Comment: Almost nothing about the time.clock() docs is correct on Windows. Here's the Windows Truth: On Windows, time.clock() uses the Win32 QueryPerformanceCounter API. The value returned is an approximation to wall-clock seconds elapsed since the first time time.clock() was called during a program run. The resolution is typically better than a microsecond. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441357&group_id=5470 From noreply@sourceforge.net Sun Jul 15 02:20:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Jul 2001 18:20:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-432621 ] httplib: multiple Set-Cookie headers Message-ID: Bugs item #432621, was opened at 2001-06-12 19:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432621&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: httplib: multiple Set-Cookie headers Initial Comment: httplib does not support multiple headers of the same name, because the headers are stored in a dictionary. This causes a problem because an HTTP response can contain multiple "Set-Cookie". It is stated in RFC2109 - HTTP State Management Mechanism that "An origin server may include multiple Set-Cookie headers in a response. " With the current python implementation, only the last "Set-Cookie" header is included in the headers dictionary, effectively meaning that the other cookies were lost. ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2001-07-14 18:20 Message: Logged In: YES user_id=139865 I'm willing to fix this, but I could use some clarification of the relevant RFCs (822 and 2045). Do either of these allow multiple headers with the same field names? I get the impression from looking around in Google that reusing a field is discouraged, but necessary for things like HTTP's Set-Cookie header. If one or both of the standards allow the above, I'll add an optional argument (defaulting to the current behaviour) that controls the handling of duplicate field names. If the flag is passed, any field name having more than one value will return the duplicate values in a list. For example: foo: yes bar: false bar: true will be returned as {foo: yes, bar: [false, true]} as opposed to the old return value {foo: yes, bar: true} HTTPResponse will always use this new behaviour, which may break some programs that rely on the old behaviour. Does anyone have comments before I code up this solution? While I am concerned about breaking compatibility, it seems like a correctness issue that headers aren't handled properly. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 23:01 Message: Logged In: YES user_id=3066 Categorized as a feature request. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432621&group_id=5470 From noreply@sourceforge.net Sun Jul 15 05:13:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Jul 2001 21:13:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-219707 ] urllib failure when return code not 200 Message-ID: Bugs item #219707, was opened at 2000-10-29 16:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=219707&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeremy Hylton (jhylton) Summary: urllib failure when return code not 200 Initial Comment: urllib fails sometimes. A traceback follows but the problem is that, on line 286, fp is used as a parameter when it has a value of None. Not sure why; HTTP.getreply seems like it always returns a file. Not time right now to look further into it... brian@sweetapp.com Traceback (most recent call last): File "/usr/home/sweetapp/public_html/zonewatcher/Rating", line 83, in ? UpdatePlayerRatings( database, zonePlayer ) File "/usr/home/sweetapp/public_html/zonewatcher/Rating", line 59, in UpdatePlayerRatings mainRatings = GetMainRatings( zonePlayer.GetZoneName( ), AOEIImainRating, AOEIIexpansionMainRating ) File "/usr/home/sweetapp/public_html/zonewatcher/Rating", line 20, in GetMainRatings ratingsPage = GetRatingsPage( zoneID ) File "/usr/home/sweetapp/public_html/zonewatcher/Rating", line 14, in GetRatingsPage url = urllib.urlopen( 'http://www.zone.com/Profile/RatingsPlayer.asp?PlayerID=' + zoneID ) File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 61, in urlopen return _urlopener.open(url) File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 166, in open return getattr(self, name)(url) File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 286, in open_http return self.http_error(url, fp, errcode, errmsg, headers) File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 303, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 518, in http_error_default return addinfourl(fp, headers, "http:" + url) File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 772, in __init__ addbase.__init__(self, fp) File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 726, in __init__ self.read = self.fp.read AttributeError: 'None' object has no attribute 'read' ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2001-07-14 21:13 Message: Logged In: YES user_id=139865 I've spoken with brian@sweetapp.com, and neither he (with 2.1) nor I (with 2.0) could reproduce this bug. Have you had any luck Jeremey? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-12-12 13:17 Message: Jeremy, can you see if this is a valid bug report? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=219707&group_id=5470 From noreply@sourceforge.net Sun Jul 15 05:18:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Jul 2001 21:18:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-219707 ] urllib failure when return code not 200 Message-ID: Bugs item #219707, was opened at 2000-10-29 16:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=219707&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeremy Hylton (jhylton) Summary: urllib failure when return code not 200 Initial Comment: urllib fails sometimes. A traceback follows but the problem is that, on line 286, fp is used as a parameter when it has a value of None. Not sure why; HTTP.getreply seems like it always returns a file. Not time right now to look further into it... brian@sweetapp.com Traceback (most recent call last): File "/usr/home/sweetapp/public_html/zonewatcher/Rating", line 83, in ? UpdatePlayerRatings( database, zonePlayer ) File "/usr/home/sweetapp/public_html/zonewatcher/Rating", line 59, in UpdatePlayerRatings mainRatings = GetMainRatings( zonePlayer.GetZoneName( ), AOEIImainRating, AOEIIexpansionMainRating ) File "/usr/home/sweetapp/public_html/zonewatcher/Rating", line 20, in GetMainRatings ratingsPage = GetRatingsPage( zoneID ) File "/usr/home/sweetapp/public_html/zonewatcher/Rating", line 14, in GetRatingsPage url = urllib.urlopen( 'http://www.zone.com/Profile/RatingsPlayer.asp?PlayerID=' + zoneID ) File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 61, in urlopen return _urlopener.open(url) File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 166, in open return getattr(self, name)(url) File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 286, in open_http return self.http_error(url, fp, errcode, errmsg, headers) File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 303, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 518, in http_error_default return addinfourl(fp, headers, "http:" + url) File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 772, in __init__ addbase.__init__(self, fp) File "/usr/home/sweetapp/Python-2.0/Lib/urllib.py", line 726, in __init__ self.read = self.fp.read AttributeError: 'None' object has no attribute 'read' ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2001-07-14 21:18 Message: Logged In: YES user_id=139865 I've spoken with brian@sweetapp.com, and neither he (with 2.1) nor I (with 2.0) could reproduce this bug. Have you had any luck Jeremey? ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2001-07-14 21:13 Message: Logged In: YES user_id=139865 I've spoken with brian@sweetapp.com, and neither he (with 2.1) nor I (with 2.0) could reproduce this bug. Have you had any luck Jeremey? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-12-12 13:17 Message: Jeremy, can you see if this is a valid bug report? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=219707&group_id=5470 From noreply@sourceforge.net Sun Jul 15 07:57:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Jul 2001 23:57:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-441400 ] [UNIX] #define NDEBUG for release build Message-ID: Bugs item #441400, was opened at 2001-07-14 23:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441400&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Barry Warsaw (bwarsaw) Summary: [UNIX] #define NDEBUG for release build Initial Comment: In the Windows release build of Python, assert()s are disabled because we #define NDEBUG on the cmdline at compile-time. Non-Windows builds don't appear to do this, but should (see Python-Dev for more). Assigned to Barry to help him meet his checkin velocity quota . ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441400&group_id=5470 From noreply@sourceforge.net Sun Jul 15 08:30:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Jul 2001 00:30:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-441409 ] re.compile of non-string misleading Message-ID: Bugs item #441409, was opened at 2001-07-15 00:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441409&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Escoto (bescoto) Assigned to: Nobody/Anonymous (nobody) Summary: re.compile of non-string misleading Initial Comment: re.compile(foo) returns foo, instead of raising an error or returning a regular expression object, if foo isn't a string. For instance: >>> import re >>> re.compile(5) 5 Instead, it seems an exception should be raised. This is especially confusing when foo is a UserString or another class that subclasses it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441409&group_id=5470 From noreply@sourceforge.net Sun Jul 15 12:18:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Jul 2001 04:18:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-441429 ] curses, can't write to loverright corner Message-ID: Bugs item #441429, was opened at 2001-07-15 04:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441429&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: curses, can't write to loverright corner Initial Comment: Whenever I try to write something to a window that would cause text to appear in the lower right corner I get an error w = curses.newwin(2,10,0,0) w.addstr(1,9,"X") -> _curses.error: addstr() returned ERR w.addch(1,9,ord("x")) -> _curses.error: addch() returned ERR Same behaviour on all versions I tried. 1.5.2 2.1 2.0 ncurses-5.2 if that is of importance. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441429&group_id=5470 From noreply@sourceforge.net Sun Jul 15 17:05:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Jul 2001 09:05:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-441409 ] re.compile of non-string misleading Message-ID: Bugs item #441409, was opened at 2001-07-15 00:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441409&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Escoto (bescoto) >Assigned to: Fredrik Lundh (effbot) Summary: re.compile of non-string misleading Initial Comment: re.compile(foo) returns foo, instead of raising an error or returning a regular expression object, if foo isn't a string. For instance: >>> import re >>> re.compile(5) 5 Instead, it seems an exception should be raised. This is especially confusing when foo is a UserString or another class that subclasses it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441409&group_id=5470 From noreply@sourceforge.net Sun Jul 15 17:40:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Jul 2001 09:40:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-441429 ] curses, can't write to loverright corner Message-ID: Bugs item #441429, was opened at 2001-07-15 04:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441429&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: A.M. Kuchling (akuchling) Summary: curses, can't write to loverright corner Initial Comment: Whenever I try to write something to a window that would cause text to appear in the lower right corner I get an error w = curses.newwin(2,10,0,0) w.addstr(1,9,"X") -> _curses.error: addstr() returned ERR w.addch(1,9,ord("x")) -> _curses.error: addch() returned ERR Same behaviour on all versions I tried. 1.5.2 2.1 2.0 ncurses-5.2 if that is of importance. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441429&group_id=5470 From noreply@sourceforge.net Sun Jul 15 17:58:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Jul 2001 09:58:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-441400 ] [UNIX] #define NDEBUG for release build Message-ID: Bugs item #441400, was opened at 2001-07-14 23:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441400&group_id=5470 Category: Build Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Tim Peters (tim_one) >Assigned to: Guido van Rossum (gvanrossum) Summary: [UNIX] #define NDEBUG for release build Initial Comment: In the Windows release build of Python, assert()s are disabled because we #define NDEBUG on the cmdline at compile-time. Non-Windows builds don't appear to do this, but should (see Python-Dev for more). Assigned to Barry to help him meet his checkin velocity quota . ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-15 09:58 Message: Logged In: YES user_id=6380 Sorry, you snooze, you lose, Barry. ;-) Fixed in Python.h rev. 2.33. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441400&group_id=5470 From noreply@sourceforge.net Mon Jul 16 05:05:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Jul 2001 21:05:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-441580 ] can't import readline in 2.1.1c1 Message-ID: Bugs item #441580, was opened at 2001-07-15 21:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441580&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: can't import readline in 2.1.1c1 Initial Comment: I get the following error for 2.1.1c1 built on SuSE Linux 7.1 , gcc 2.95.2 : >>> import readline Traceback (most recent call last): File "", line 1, in ? ImportError: undefined symbol: BC Needless to say, this makes the interactive session interesting as readline is not imported on startup. Temporary fix for me is to use readline.so from 2.0 - it seems to work fine in 2.1.1c1. Chuck ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441580&group_id=5470 From noreply@sourceforge.net Mon Jul 16 06:29:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Jul 2001 22:29:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-441600 ] Misleading doc of $ metacharacter in re Message-ID: Bugs item #441600, was opened at 2001-07-15 22:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441600&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Misleading doc of $ metacharacter in re Initial Comment: From: machin_john_888@hotmail.com (John Machin) Newsgroups: comp.lang.python Subject: Re: re Challenge: More Compact? References: NNTP-Posting-Host: 140.168.16.251 Message-ID: <92ae279c.0107152124.4c049d5e@posting.google.com> "Tim Peters" wrote in message news:... > BTW, does it bother anyone that all of these solutions accept an IP ending > with a newline? > > regexps-are-surprising-ly y'rs - tim Straight out of the horse's mouth at http://python.sourceforge.net/devel-docs/lib/re- syntax.html (this is in section 4.2.1 of the Python Library Reference): "$" Matches the end of the string, and in MULTILINE mode also matches before a newline. foo matches both 'foo' and 'foobar', while the regular expression foo$ matches only 'foo'. But the real story only emerges two pages later (in section 4.2.3): M MULTILINE When specified, the pattern character "^" matches at the beginning of the string and at the beginning of each line (immediately following each newline); and the pattern character "$" matches at the end of the string and at the end of each line (immediately preceding each newline). By default, "^" matches only at the beginning of the string, and "$" only at the end of the string and immediately before the newline (if any) at the end of the string. I shall enter a bug report and leave it up to the powers_that_be to decide whether to change the behaviour or section 4.2.1 of the documentation. To answer Tim's question, yes it bothers me ... the solution of course always when you want to validate that the pattern matches the whole string (and not some leading substring) is to have \Z at the end of your pattern (not $). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441600&group_id=5470 From noreply@sourceforge.net Mon Jul 16 12:39:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 04:39:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-441664 ] Python crash on del of a slice of a mmap Message-ID: Bugs item #441664, was opened at 2001-07-16 04:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441664&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: Python crash on del of a slice of a mmap Initial Comment: Python 2.1.1c1 (#19, Jul 13 2001, 00:25:06) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> flob=open('foo.txt','r+') >>> import mmap >>> mm=mmap.mmap(flob.fileno(),0) >>> mm[:] 'uno\r\ndue\r\ntre\r\ne quattro\r\n' >>> del mm[:10] This crashes the Python interpreter. Reproduced on both Windows/98 and NT4 SP6a. I think it's a very simple bug at line 666 (sic!) of mmapmodule.c: it calls PyString_Check(v), without previously checking v!=0, and that macro defererences v (line 52 of stringobject.h); but slice deletion calls slice-assignment exactly with v set to 0. So I believe it should be fixed by just checking v!=0 and giving a msg about mmap not supporting slice deletion, just before line 666 in mmapmodule.c. Hopefully can still be done for 2.1.1 final...? Alex ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441664&group_id=5470 From noreply@sourceforge.net Mon Jul 16 14:35:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 06:35:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-441580 ] can't import readline in 2.1.1c1 Message-ID: Bugs item #441580, was opened at 2001-07-15 21:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441580&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Thomas Wouters (twouters) Summary: can't import readline in 2.1.1c1 Initial Comment: I get the following error for 2.1.1c1 built on SuSE Linux 7.1 , gcc 2.95.2 : >>> import readline Traceback (most recent call last): File "", line 1, in ? ImportError: undefined symbol: BC Needless to say, this makes the interactive session interesting as readline is not imported on startup. Temporary fix for me is to use readline.so from 2.0 - it seems to work fine in 2.1.1c1. Chuck ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441580&group_id=5470 From noreply@sourceforge.net Mon Jul 16 16:11:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 08:11:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-441712 ] Exception using passive ftp with OS 390 Message-ID: Bugs item #441712, was opened at 2001-07-16 08:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441712&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Henrik Weber (hweber) Assigned to: Nobody/Anonymous (nobody) Summary: Exception using passive ftp with OS 390 Initial Comment: Machines equipped with OS 390 (IBM mainframes) sometimes use a product called TCPaccess, built by a company called Interlink. Among other things this includes a FTP server. Starting with Python 2.1 ftplib tries to switch to passive mode when one uses a command like dir. The syntax of the response of the TCPacess FTP server is not what ftplib expects, so an exception is raised. This is the traceback: Traceback (most recent call last): File "", line 1, in ? File "c:\programme\python21\lib\ftplib.py", line 420, in dir self.retrlines(cmd, func) File "c:\programme\python21\lib\ftplib.py", line 352, in retrlines conn = self.transfercmd(cmd) File "c:\programme\python21\lib\ftplib.py", line 296, in transfercmd return self.ntransfercmd(cmd, rest)[0] File "c:\programme\python21\lib\ftplib.py", line 273, in ntransfercmd host, port = parse227(self.sendcmd('PASV')) File "c:\programme\python21\lib\ftplib.py", line 514, in parse227 if left < 0: raise error_proto, resp error_proto: 227 Entering passive mode 25,64,88,88,16,7 Function parse227, which raises the exception, expects the address and port in brackets, which the server doesn't deliver in this case. This causes the function to raise the exception shown. Passive mode is not the default in versions prior to Python 2.1 so the problem didn't show before, although versions prior to 2.1 would have reacted the same way when trying to use passive mode. Although the fault is on the side of the server the function can easily be changed to accept this kind of syntax as well, which would make life easier for people who are trying to interface to that kind of machine: diff -u ftplib.py c:/tmp/ftplib.py --- ftplib.py Sun Apr 8 23:24:52 2001 +++ c:/tmp/ftplib.py Mon Jul 16 14:16:14 2001 import os import sys import string +import re # Import SOCKS module if it exists, else standard socket module socket try: @@ -510,12 +511,10 @@ if resp[:3] != '227': raise error_reply, resp - left = resp.find('(') - if left < 0: raise error_proto, resp - right = resp.find(')', left + 1) - if right < 0: - raise error_proto, resp # should contain '(h1,h2,h3,h4,p1,p2)' - numbers = resp[left+1:right].split(',') + tuple = re.search(r'\d{1,3},\d{1,3},\d{1,3},\d {1,3},\d{1,3},\d{1,3}', resp).group() + if not tuple: + raise error_proto, resp + numbers = tuple.split(',') if len(numbers) != 6: raise error_proto, resp host = '.'.join(numbers[:4]) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441712&group_id=5470 From noreply@sourceforge.net Mon Jul 16 16:11:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 08:11:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-441580 ] can't import readline in 2.1.1c1 Message-ID: Bugs item #441580, was opened at 2001-07-15 21:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441580&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Thomas Wouters (twouters) Summary: can't import readline in 2.1.1c1 Initial Comment: I get the following error for 2.1.1c1 built on SuSE Linux 7.1 , gcc 2.95.2 : >>> import readline Traceback (most recent call last): File "", line 1, in ? ImportError: undefined symbol: BC Needless to say, this makes the interactive session interesting as readline is not imported on startup. Temporary fix for me is to use readline.so from 2.0 - it seems to work fine in 2.1.1c1. Chuck ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-16 08:11 Message: Logged In: YES user_id=34209 Did this work in Python 2.1(.0) ? Nothing readline-specific changed in 2.1.1c1... It looks like setup.py is using the wrong libraries to link with. When you enable readline.so in 2.0's Setup file, do you edit the list of include/library paths or libraries linked with ? I don't have a SuSe installation to test with, unfortunately. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441580&group_id=5470 From noreply@sourceforge.net Mon Jul 16 16:42:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 08:42:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-441357 ] time.clock() docs wrong for Windows Message-ID: Bugs item #441357, was opened at 2001-07-14 16:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441357&group_id=5470 Category: Documentation Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: time.clock() docs wrong for Windows Initial Comment: Almost nothing about the time.clock() docs is correct on Windows. Here's the Windows Truth: On Windows, time.clock() uses the Win32 QueryPerformanceCounter API. The value returned is an approximation to wall-clock seconds elapsed since the first time time.clock() was called during a program run. The resolution is typically better than a microsecond. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-16 08:42 Message: Logged In: YES user_id=3066 Fixed in Doc/lib/libtime.tex revisions 1.42 and 1.37.4.3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441357&group_id=5470 From noreply@sourceforge.net Mon Jul 16 16:49:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 08:49:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-441664 ] Python crash on del of a slice of a mmap Message-ID: Bugs item #441664, was opened at 2001-07-16 04:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441664&group_id=5470 >Category: Extension Modules Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Alex Martelli (aleax) >Assigned to: Thomas Wouters (twouters) Summary: Python crash on del of a slice of a mmap Initial Comment: Python 2.1.1c1 (#19, Jul 13 2001, 00:25:06) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> flob=open('foo.txt','r+') >>> import mmap >>> mm=mmap.mmap(flob.fileno(),0) >>> mm[:] 'uno\r\ndue\r\ntre\r\ne quattro\r\n' >>> del mm[:10] This crashes the Python interpreter. Reproduced on both Windows/98 and NT4 SP6a. I think it's a very simple bug at line 666 (sic!) of mmapmodule.c: it calls PyString_Check(v), without previously checking v!=0, and that macro defererences v (line 52 of stringobject.h); but slice deletion calls slice-assignment exactly with v set to 0. So I believe it should be fixed by just checking v!=0 and giving a msg about mmap not supporting slice deletion, just before line 666 in mmapmodule.c. Hopefully can still be done for 2.1.1 final...? Alex ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-16 08:49 Message: Logged In: YES user_id=34209 Actually, the crash happens both on a del of the slice and of an item, and on UNIX as well as Windows -- and any other platform that could compile it. It's been around at least since 2.0, and probably forever. Your diagnosis is spot-on, by the way, that made it easy to fix :) Fixed in revision 2.32 (head) and 2.27.4.2 (2.1.1 tree) so it'll be fixed in Python 2.2a1 and Python 2.1.1-final. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441664&group_id=5470 From noreply@sourceforge.net Mon Jul 16 16:56:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 08:56:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-438786 ] CVS 2.1.1c1 broken on osf1V4 Message-ID: Bugs item #438786, was opened at 2001-07-05 07:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Nobody/Anonymous (nobody) Summary: CVS 2.1.1c1 broken on osf1V4 Initial Comment: As of right now, the CVS branch for the 2.1 bugfix release cannot import the math module on my Digital Unix platform. ImportError: Unresolved symbol in /tmp_mnt/home/gball/usr/src/python/dist/src/build/lib.osf1-V4.0-alpha-2.1/math.so: __eprintf uname is OSF1 surya V4.0 878 alpha ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-16 08:56 Message: Logged In: YES user_id=34209 Ah, yes, that sounds very plausible. The fix for that problem, which was checked in on the trunk, will be in Python 2.1.1-final as well. The Solaris bugreport has a patch attached to it; could you test it to see if it solves your 2.1.1c1 problem ? ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-09 08:48 Message: Logged In: YES user_id=11365 The problem goes away if I clear $CC instead of having it set to gcc. There's a similar problem on Solaris reported recently. I think the configure script should try to spot this sort of thing, but I suppose that's an Autoconf feature request, not a python bug... Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-08 14:06 Message: Logged In: YES user_id=21627 This sounds like a bug in your compiler installation. __eprintf is typically defined in libgcc.a; make sure you use a consistent compiler capable of building binaries for your system throughout the build process. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 From noreply@sourceforge.net Mon Jul 16 20:01:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 12:01:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-441781 ] parser module does not support yield Message-ID: Bugs item #441781, was opened at 2001-07-16 12:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441781&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: parser module does not support yield Initial Comment: The "yield" statement is not supported by the parser module. It should do so. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441781&group_id=5470 From noreply@sourceforge.net Mon Jul 16 20:02:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 12:02:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-441781 ] parser module does not support yield Message-ID: Bugs item #441781, was opened at 2001-07-16 12:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441781&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: parser module does not support yield Initial Comment: The "yield" statement is not supported by the parser module. It should do so. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441781&group_id=5470 From noreply@sourceforge.net Mon Jul 16 21:00:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 13:00:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-437395 ] RFC 2822 conformance Message-ID: Bugs item #437395, was opened at 2001-06-29 09:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437395&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Barry Warsaw (bwarsaw) Summary: RFC 2822 conformance Initial Comment: The rfc822 and smtplib modules need to be checked for conformance with RFC 2822, which obsoletes RFC 822. (Added this to the tracker so we don't lose track of this.) ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-07-16 13:00 Message: Logged In: YES user_id=12800 philhunt is correct in this case. The relevant section of RFC 2822 is $4.1 Miscellaneous obsolete tokens. "Period" (aka "full stop" or ".") is defined as obsolete syntax, specifically in the obs-phrase production. We MUST accept this. Attached is the meat of the patch for rfc822.py to fix this (there will be some other changes included in what I check in though -- mostly updates to docstrings and such). ---------------------------------------------------------------------- Comment By: Philip Hunt (philhunt) Date: 2001-07-08 12:05 Message: Logged In: YES user_id=236441 rfc822 *doesn't* conform to RFC2822. As an example, when we have a field From: From: A. N. Other then getaddr("From") returns ('', 'A.N.Other') which is incorrect. When the from line is changed to: From: From: A N Other then getaddr("From") correctly returns ('A N Other', 'another@nowhere.org.ca') The relevant parts of the syntax specified in rfc2822 are: from = "From:" mailbox-list CRLF mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list mailbox = name-addr / addr-spec name-addr = [display-name] angle-addr display-name = phrase phrase = 1*word / obs-phrase obs-phrase = word *(word / "." / CFWS) >From rfc2822, section 4.1: Note: The "period" (or "full stop") character (".") in obs-phrase is not a form that was allowed in earlier versions of this or any other standard. Period (nor any other character from specials) was not allowed in phrase because it introduced a parsing difficulty distinguishing between phrases and portions of an addr-spec (see section 4.4). It appears here because the period character is currently used in many messages in the display-name portion of addresses, especially for initials in names, and therefore must be interpreted properly. In the future, period may appear in the regular syntax of phrase. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437395&group_id=5470 From noreply@sourceforge.net Mon Jul 16 21:41:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 13:41:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-437395 ] RFC 2822 conformance Message-ID: Bugs item #437395, was opened at 2001-06-29 09:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437395&group_id=5470 Category: Python Library Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Barry Warsaw (bwarsaw) Summary: RFC 2822 conformance Initial Comment: The rfc822 and smtplib modules need to be checked for conformance with RFC 2822, which obsoletes RFC 822. (Added this to the tracker so we don't lose track of this.) ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-07-16 13:41 Message: Logged In: YES user_id=12800 Patch applied to rfc822.py 1.58 ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-07-16 13:00 Message: Logged In: YES user_id=12800 philhunt is correct in this case. The relevant section of RFC 2822 is $4.1 Miscellaneous obsolete tokens. "Period" (aka "full stop" or ".") is defined as obsolete syntax, specifically in the obs-phrase production. We MUST accept this. Attached is the meat of the patch for rfc822.py to fix this (there will be some other changes included in what I check in though -- mostly updates to docstrings and such). ---------------------------------------------------------------------- Comment By: Philip Hunt (philhunt) Date: 2001-07-08 12:05 Message: Logged In: YES user_id=236441 rfc822 *doesn't* conform to RFC2822. As an example, when we have a field From: From: A. N. Other then getaddr("From") returns ('', 'A.N.Other') which is incorrect. When the from line is changed to: From: From: A N Other then getaddr("From") correctly returns ('A N Other', 'another@nowhere.org.ca') The relevant parts of the syntax specified in rfc2822 are: from = "From:" mailbox-list CRLF mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list mailbox = name-addr / addr-spec name-addr = [display-name] angle-addr display-name = phrase phrase = 1*word / obs-phrase obs-phrase = word *(word / "." / CFWS) >From rfc2822, section 4.1: Note: The "period" (or "full stop") character (".") in obs-phrase is not a form that was allowed in earlier versions of this or any other standard. Period (nor any other character from specials) was not allowed in phrase because it introduced a parsing difficulty distinguishing between phrases and portions of an addr-spec (see section 4.4). It appears here because the period character is currently used in many messages in the display-name portion of addresses, especially for initials in names, and therefore must be interpreted properly. In the future, period may appear in the regular syntax of phrase. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437395&group_id=5470 From noreply@sourceforge.net Mon Jul 16 23:40:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 15:40:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-441833 ] Rule-based logic Message-ID: Bugs item #441833, was opened at 2001-07-16 15:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441833&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Rule-based logic Initial Comment: It would be awesome to make Python understand rule- based statements like those in JESS, CLIPS, LISP, and PROLOG. In addition to procedural and object-oriented principles, Python should use non-algorithmic concepts such as facts, rules, constraints, etc. This will allow building expert systems in Python and making "executable pseudocode" truly high-level. All of logic-based systems use the Rete algorithm and lisp- like syntax. Perhaps with Python's economical, intuitive syntax and strong typing the results will be better than in other languages. References: JESS: http://herzberg.ca.sandia.gov/jess/ CLIPS: http://www.ghg.net/clips/CLIPS.html LISP: http://www.norvig.com/lisp_talk_final.htm PROLOG: http://www.amzi.com/articles/prolog_books_tutorials.htm Thank you! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441833&group_id=5470 From noreply@sourceforge.net Tue Jul 17 01:27:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 17:27:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-441580 ] can't import readline in 2.1.1c1 Message-ID: Bugs item #441580, was opened at 2001-07-15 21:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441580&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Thomas Wouters (twouters) Summary: can't import readline in 2.1.1c1 Initial Comment: I get the following error for 2.1.1c1 built on SuSE Linux 7.1 , gcc 2.95.2 : >>> import readline Traceback (most recent call last): File "", line 1, in ? ImportError: undefined symbol: BC Needless to say, this makes the interactive session interesting as readline is not imported on startup. Temporary fix for me is to use readline.so from 2.0 - it seems to work fine in 2.1.1c1. Chuck ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-16 17:27 Message: Logged In: NO Ok, I looked at the Setup file for 2.0 from SuSE. They had readline readline.c -lreadline -lncurses #-ltermcap whereas 2.1.1c1 had readline readline.c -lreadline -ltermcap I made the change, recompiled, and everything is dandy. Chuck ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-16 08:11 Message: Logged In: YES user_id=34209 Did this work in Python 2.1(.0) ? Nothing readline-specific changed in 2.1.1c1... It looks like setup.py is using the wrong libraries to link with. When you enable readline.so in 2.0's Setup file, do you edit the list of include/library paths or libraries linked with ? I don't have a SuSe installation to test with, unfortunately. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441580&group_id=5470 From noreply@sourceforge.net Tue Jul 17 01:30:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 17:30:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-441851 ] SystemError in sre scanner Message-ID: Bugs item #441851, was opened at 2001-07-16 17:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441851&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: SystemError in sre scanner Initial Comment: File "mbr_id.py", line 91, in set_up_dict akf = non_an_ripper("", akf).upper() File "c:\python21\lib\sre.py", line 164, in _sub return _subn(pattern, template, string, count)[0] File "c:\python21\lib\sre.py", line 177, in _subn c = pattern.scanner(string) SystemError: NULL object passed to PyObject_Init where: non_an_ripper = re.compile("[^A-Za-z0-9]").sub and akf contains typically a short string like 'A123456(7)' or 'XG123456-7' This happens with Python 2.1 running under Windows 95B. The primary problem is mine (out of memory) : (a) if I wrap a try/except around my invocation of non_an_ripper (), the effect is to trigger a MemoryError exception somewhere else in my code (b) if I give Python enough memory (e.g. by shutting down Excel, IE5.5, etc), then there is no exception raised at all, and execution completes as expected. However there seems to be a secondary problem: maybe sre is not checking the return value from some .*alloc () function. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441851&group_id=5470 From noreply@sourceforge.net Tue Jul 17 04:03:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Jul 2001 20:03:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-441781 ] parser module does not support yield Message-ID: Bugs item #441781, was opened at 2001-07-16 12:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441781&group_id=5470 Category: Extension Modules Group: None >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: parser module does not support yield Initial Comment: The "yield" statement is not supported by the parser module. It should do so. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-16 20:03 Message: Logged In: YES user_id=3066 Fixed in Modules/parsermodule.c revision 2.62. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441781&group_id=5470 From noreply@sourceforge.net Tue Jul 17 10:02:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Jul 2001 02:02:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-441851 ] SystemError in sre scanner Message-ID: Bugs item #441851, was opened at 2001-07-16 17:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441851&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fredrik Lundh (effbot) Summary: SystemError in sre scanner Initial Comment: File "mbr_id.py", line 91, in set_up_dict akf = non_an_ripper("", akf).upper() File "c:\python21\lib\sre.py", line 164, in _sub return _subn(pattern, template, string, count)[0] File "c:\python21\lib\sre.py", line 177, in _subn c = pattern.scanner(string) SystemError: NULL object passed to PyObject_Init where: non_an_ripper = re.compile("[^A-Za-z0-9]").sub and akf contains typically a short string like 'A123456(7)' or 'XG123456-7' This happens with Python 2.1 running under Windows 95B. The primary problem is mine (out of memory) : (a) if I wrap a try/except around my invocation of non_an_ripper (), the effect is to trigger a MemoryError exception somewhere else in my code (b) if I give Python enough memory (e.g. by shutting down Excel, IE5.5, etc), then there is no exception raised at all, and execution completes as expected. However there seems to be a secondary problem: maybe sre is not checking the return value from some .*alloc () function. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441851&group_id=5470 From noreply@sourceforge.net Tue Jul 17 12:00:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Jul 2001 04:00:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-411612 ] cgi.py sometimes ignores QUERY_STRING Message-ID: Bugs item #411612, was opened at 2001-03-27 03:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411612&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 3 Submitted By: Viktor Fougstedt (viktordt) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.py sometimes ignores QUERY_STRING Initial Comment: [Using Python 2.0/Sparc Solaris 8, should be independent of operating system] cgi.py sometimes ignores the QUERY_STRING when REQUEST_METHOD is POST. The CGI specifications says nothing about how programs should respond to this particular combination. It does however state that QUERY_STRING should always be set by the server, regardless of the request method. Since QUERY_STRING is set, it seems reasonable that the cgi module should parse it as well and not just ignore it. If cgi.py intentionally ignores QUERY_STRING under these circumstances, I think it should be documented. :-) What this means is that if i have a HTML form a'la
and some_cgi is a python script using cgi.py, I should get both foo and bar set. Currently, the QUERY_STRING (i.e. "foo=foo") is ignored, and only bar gets set by cgi.py. I consider this a "bug" insofar as it is an unexpected and somewhat inconsistent behaviour. If I e.g. use the url "/cgi-bin/myprog/session_id=10023" everywhere in my program, I must suddenly alter it if the URL is used in a FORM action attribute, and instead insert a hidden variable called session_id into the form to get cgi.py to parse it. The parse() function in cgi.py correctly checks and appends QUERY_STRING if it is set. But the FieldStorage read_urlencoded() method does not, and that is the function that is actually used, not cgi.parse(). The fix should be to add two lines (marked with '>' below) after the initial assignment to qs in the read_urlencoded() method of the FieldStorage class so that it begins: def read_urlencoded(self): """Internal: read data in query string format.""" qs = self.fp.read(self.length) if os.environ.has_key('QUERY_STRING'): if qs: qs = qs + '&' qs = qs + environ['QUERY_STRING'] (the three last lines are new, and identical to the three lines in the cgi.parse() function which accomplishes the same task). ---------------------------------------------------------------------- Comment By: Steve Holden (holdenweb) Date: 2001-07-17 04:00 Message: Logged In: YES user_id=88157 This appears to be a somewhat grey area: certainly the CGI specifications say that the QUERY_STRING must be made available, but does it make sense to treat QUERY_STRING data as of equal importance when standard input is present in a POST method request? In particular, if QUERY_STRING contains "spam=eggs" and the standard input contains "spam=chips" then should FieldStorage().getitem("spam") return ["eggs", "chips"]? Appealing to the behaviour of other servers is possibly not the best guide for the cgi library's action, but it might be instructive to see how other systems have approached this problem before changes are made. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 08:30 Message: Logged In: YES user_id=6380 The idea is right, but since nobody volunteered a working patch, this won't make it into 2.1. Sorry. Try again after 2.1! ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-03-27 04:23 Message: Logged In: NO Quick check: That "fix" does not work. It duplicates the QUERY_STRING if you use the GET method. Additional checks are necessary to ensure correct operation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411612&group_id=5470 From noreply@sourceforge.net Tue Jul 17 12:23:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Jul 2001 04:23:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-434479 ] os.listdir loses on linux w/NTFS vols Message-ID: Bugs item #434479, was opened at 2001-06-19 07:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434479&group_id=5470 Category: Python Library Group: Irreproducible Status: Closed Resolution: Works For Me Priority: 5 Submitted By: jeremy bornstein (ukekuma) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: os.listdir loses on linux w/NTFS vols Initial Comment: os.listdir() on a directory which is on an NTFS volume omits one entry from the directory listing. Example: planet {188}: grep ntfs /etc/fstab /dev/hda1 /lose ntfs uid=500,gid=500,umask=555 1 2 planet {189}: ls /lose Documents and Settings/ My Music/ Program Files/ PUTTY.RND $Secure unzipped/ WINNT/ planet {190}: python2.1 Python 2.1 (#1, Jun 19 2001, 00:32:28) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import os >>> os.listdir('/lose') ['$Secure', 'Documents and Settings', 'My Music', 'Program Files', 'PUTTY.RND', 'unzipped'] >>> planet {191}: (In the example, note that the directory 'WINNT' is not returned by os.listdir.) I have verified this bug with/1.5.2, 1.6.1, and 2.1 on Linux (RH7.1) only. I have only tested it on this one NTFS volume and this one computer. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-17 04:23 Message: Logged In: YES user_id=21627 I have a similar report that tab-completion in the shell (bash?) will sometimes refuse to return the last directory entry, on an NTFS. To find out what ls is doing, I recommend to use strace. I currently don't even have a system with Linux and NT installed simultaneously, so I cannot help much. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-11 18:14 Message: Logged In: YES user_id=3066 What's really strange is that Python & ls are returning different results. Python is just using opendir/readdir/closedir for Linux; I've not read the ls sources to know what that's doing (but it should be considered buggy if that's not what it's doing!). Now, if we could get Martin interested in working on the Linux NTFS driver again... ---------------------------------------------------------------------- Comment By: jeremy bornstein (ukekuma) Date: 2001-07-11 17:49 Message: Logged In: YES user_id=248973 I noticed that it was always the *final* directory entry which was not displayed. I don't think the problem has anything to do with the WINNT directory specifically, other than it the fact that it was the last one. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-11 11:33 Message: Logged In: YES user_id=3066 I was not able to reproduce this on my system (Mandrake 7.2, Linux 2.2.17). This may be a difference in configuration: I have an NTFS partition, but it's not the one that contains my \WINNT directory. If \WINNT is special in some way, I can't reproduce that. See also Martin's comment; he's likely to know exactly what he's talking about. I'm going to close this as irreproducible, acknowledging that it might really be a third-party bug. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 23:54 Message: Logged In: YES user_id=3066 Assigning this to me since I have a similar setup. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-23 12:45 Message: Logged In: YES user_id=21627 This is likely a bug in the NTFS driver, not in Python. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434479&group_id=5470 From noreply@sourceforge.net Tue Jul 17 12:28:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Jul 2001 04:28:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-430160 ] CGIHTTPServer.py POST bug using IE Message-ID: Bugs item #430160, was opened at 2001-06-04 17:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=430160&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kevin Altis (kasplat) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer.py POST bug using IE Initial Comment: >From the readme included in the zip: This set of files shows a bug that occurs when doing POST requests via the CGIHTTPServer.py module in Python 2.1 The testpost.html file when accessed via Internet Explorer 5.5 from webserver.py should show this bug. On short POST requests IE will end up doing a second POST and then displaying an error message while longer POSTs will be followed by a second POST and then a GET. The problem appears to be specific to the interaction of IE and the handling of windows sockets in Python in the CGIHTTPServer.py module which relies on BaseHTTPServer.py, SocketServer.py... posttestwebserver.py is currently setup to use C:\tmp\testpost as the document root, so either move the "testpost" folder to C:\tmp or change the directory to wherever the testpost folder is located. Start the server using the .bat file and bring up .html page with something like: http://localhost/testpost.html The bug should occur when you try: Test short CGI response with POST or Test long CGI response with POST The other requests should work fine. The bug will occur regardless of whether IE is set to use HTTP/1.0 or HTTP/1.1. The bug doesn't appear to occur when going through a simple proxy. You can also get the bug to occur using a remote IE client (either on a LAN or over the Net). In addition, it doesn't appear to matter whether running with unbuffered binary pipes (python -u) or not. I also tested against my modified CGIHTTPServer.py See the bug I posted at: http://sourceforge.net/tracker/? func=detail&atid=105470&aid=427345&group_id=5470 My configuration: Windows 2000 Pro, SP2 AMD 1.2GHz 256MB RAM ActiveStatet Python 2.1 (build 210) Internet Explorer 5.5 (5.50.4522.1800) ka --- Mark Lutz said: "FWIW, I noticed today (in between lecturing a class) that on Windows, Python actually uses a special Python- coded socket.py library module, not the standard C- coded socket extension module. socket.py lives in the library directory; it does unique things for closes and deletes that may not make sense in all cases (e.g., the makefile call generates a class instance, not a true file object). It may also be trying to close the underlying socket twice. I don't have" ---------------------------------------------------------------------- Comment By: Steve Holden (holdenweb) Date: 2001-07-17 04:28 Message: Logged In: YES user_id=88157 Please note that I have observed this behavior on Windows 98 using Python 2.0 (#8, Mar 7 2001, 16:04:37) [MSC 32 bit (Intel)] using the same build of IE, so it is not a Win2k- specific problem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=430160&group_id=5470 From noreply@sourceforge.net Tue Jul 17 12:49:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Jul 2001 04:49:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-432621 ] httplib: multiple Set-Cookie headers Message-ID: Bugs item #432621, was opened at 2001-06-12 19:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432621&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: httplib: multiple Set-Cookie headers Initial Comment: httplib does not support multiple headers of the same name, because the headers are stored in a dictionary. This causes a problem because an HTTP response can contain multiple "Set-Cookie". It is stated in RFC2109 - HTTP State Management Mechanism that "An origin server may include multiple Set-Cookie headers in a response. " With the current python implementation, only the last "Set-Cookie" header is included in the headers dictionary, effectively meaning that the other cookies were lost. ---------------------------------------------------------------------- Comment By: Steve Holden (holdenweb) Date: 2001-07-17 04:49 Message: Logged In: YES user_id=88157 RFC 822-compliant mail messages frequently contain several "Received-By:" headers. I cannot remember anything in the standard which speaks to the general case. There may well be headers whose semantics require enforcement of the "There can be only one" variety, but equally some others must be treated the same as "Received-By:". In so far as RFC 2616 [HTTP/1.1] says "Unrecognized header fields SHOULD be ignored by the recipient and MUST be forwarded by transparent proxies." (section 7.1: Entity header fields) this is an argument for being able to handle many unknown headers of the same type in the general case. For correct processing it is therefore necessary to hold headers as lists, or in some other way which allows multiple headers of the same type. Fortunately there appears to be no need to emit headers in the same order they were seen in the original to preserve meaning. ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2001-07-14 18:20 Message: Logged In: YES user_id=139865 I'm willing to fix this, but I could use some clarification of the relevant RFCs (822 and 2045). Do either of these allow multiple headers with the same field names? I get the impression from looking around in Google that reusing a field is discouraged, but necessary for things like HTTP's Set-Cookie header. If one or both of the standards allow the above, I'll add an optional argument (defaulting to the current behaviour) that controls the handling of duplicate field names. If the flag is passed, any field name having more than one value will return the duplicate values in a list. For example: foo: yes bar: false bar: true will be returned as {foo: yes, bar: [false, true]} as opposed to the old return value {foo: yes, bar: true} HTTPResponse will always use this new behaviour, which may break some programs that rely on the old behaviour. Does anyone have comments before I code up this solution? While I am concerned about breaking compatibility, it seems like a correctness issue that headers aren't handled properly. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 23:01 Message: Logged In: YES user_id=3066 Categorized as a feature request. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432621&group_id=5470 From noreply@sourceforge.net Tue Jul 17 15:29:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Jul 2001 07:29:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-441172 ] Tree Widget does not cancell entry Message-ID: Bugs item #441172, was opened at 2001-07-13 13:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441172&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Guido van Rossum (gvanrossum) Summary: Tree Widget does not cancell entry Initial Comment: Tree Widget in Idle does not cancell properly. Pressing escape validates the entry even though the proper funciton is called. I'm running it on both Red Hat, and OpenBSD. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-17 07:29 Message: Logged In: YES user_id=6380 I appreciate your bug report. I don't have time to fix this; if you find a fix, please submit a patch! ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-13 15:26 Message: Logged In: NO Apparently I have forgotten a few things. I've tried it both with Python2.0 and 2.1. Idle 0.6 I am writing my own code that extends the Tree Widget but the easiest way to reproduce the error is to: import TreeWidget TreeWidget.test2() Try to change the name of one of the files and press 'escape' to get out of it. The name still gets changed. (the widget still calls edit_cancel but it doesn't get the previous entry??) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-13 13:42 Message: Logged In: YES user_id=6380 Please provide more information. Are you writing code that uses the tree widget, or are you simply using IDLE? If the former, please show us your code. If the latter, which window did you have open? In either case, please tell us in more detail what you did, what you expected, and what happened instead. Also, please let us know what Pythin version and what IDLE version. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441172&group_id=5470 From noreply@sourceforge.net Tue Jul 17 15:30:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Jul 2001 07:30:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn Message-ID: Bugs item #417845, was opened at 2001-04-21 08:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470 Category: Python Library Group: None >Status: Open Resolution: Fixed >Priority: 3 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: Python 2.1: SocketServer.ThreadingMixIn Initial Comment: SocketServer.ThreadingMixIn does not work properly since it tries to close the socket of a request two times. Workaround for using SocketServer.ThreadingMixIn under Python 2.1: class MyThreadingHTTPServer( SocketServer.ThreadingMixIn, MyHTTPServer ): def close_request(self, request): pass ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-17 07:30 Message: Logged In: YES user_id=6380 I have absolutely no time to review this right now. This won't be fixed in 2.1.x; I'll look into making that change for 2.2 at some point. ---------------------------------------------------------------------- Comment By: Stian Soiland (stain) Date: 2001-07-13 14:51 Message: Logged In: YES user_id=25921 I don't think it's a good idea to let closing the request be the handler's responsibility. It's better to let the ThreadingMixIn do it: stain@zoidberg:~$ diff -u SocketServer-cvs-1.24.2.1.py SocketServer.py --- SocketServer-cvs-1.24.2.1.py Fri Jul 13 23:20:26 2001 +++ SocketServer.py Fri Jul 13 23:34:02 2001 @@ -451,8 +451,10 @@ def process_request(self, request, client_address): """Start a new thread to process the request.""" import threading - t = threading.Thread(target = self.finish_request, - args = (request, client_address)) + # Call the BaseServers process_request to close the + # socket after finally_request. + t = threading.Thread(target = BaseServer.process_request, + args = (self, request, client_address)) t.start() In my eyes this is the best, making the overriden process_request behaving like the original process_request. This would make the difference between Threading-servers and other servers smaller. If it looks bad with BaseServer-references inside ThreadingMixIn, what about a method of ThreadingMixIn named __process_request with the same code as BaseServer.process_request? -- Stian Soiland ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-07-11 14:45 Message: Logged In: YES user_id=7887 Ohh, I'm sorry. I've read comments the other way around. The last comment seemed to be the one at bottom (as usual), then it looked like it was not definetly fixed. I'll checkout the fix from cvs. Thanks! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 14:22 Message: Logged In: YES user_id=6380 Gustavo, yes it's fixed in CVS (just read on and you;ll see my announcement). We're going to release a bugfix update release for Python 2.1, Python 2.1.1 soon, and it will be in that release too. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-07-11 14:19 Message: Logged In: YES user_id=7887 Just wondering, is this bug fixed somewhere (cvs, etc)?? Python 2.1 + SOAP.py seem to have this problem, when using the ThreadingTCPServer. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 06:59 Message: Logged In: YES user_id=6380 Yes, the thread is responsible for calling self.close_request() in self.finish_request(). (Although if you just rely on reference counting, it should go away all by itself too.) I don't read the newsgroup frequently, but you can try email if you have more problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-10 05:47 Message: Logged In: NO I tried the fix and it seems to work. I'm wondering if the thread is responsible for calling self.close_request() in self.finish_request? Note: Can we discuss it in news:comp.lang.python? I hate that web interface with Cookies! That's the reason why I was too lazy to login when submitting this bug report. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 04:59 Message: Logged In: YES user_id=6380 I've developed a proper fix for this, I hope. Check out the latest SocketServer.py from the CVS tree. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-07-02 09:05 Message: Logged In: YES user_id=198402 There is still a problem with your solution, Mr glchapman: you make a copy to ensure that the server won't close the copy of the socket that is used in the child thread. Right. But WHO will close this very copy then? The thread still has to close it if one wants to be "clean". So as long as the child thread must close its copy in the threading case, why not make it a thumb rule? Why should we bother about closing anything in the main thread? I still think the solution that I provide is best: make the request handler always responsible for closing the socket from which the request comes. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2001-06-29 08:49 Message: Logged In: YES user_id=86307 Since the request socket object is only a lightweight wrapper around the real socket, why not simply pass request.dup() to the new thread? Then the server's call to close_request affects only its copy of request, not the copy being used in the thread. For example, the following change to ThreadingMixIn fixed this bug for me in a (very simple) test program: def process_request(self, request, client_address): """Start a new thread to process the request.""" import threading t = threading.Thread(target = self.finish_request, args = (request.dup(), client_address)) t.start() ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-28 05:20 Message: Logged In: YES user_id=198402 I have now started a project here concerning a SOCKS proxy written in python (PySocks). It is aimed mostly at people who use a windows box to share their internet connection and uses the threading server from the SocketServer module. So it becomes VERY important to me to know of what will be done about this bug, in the next release/patch of Python library. Could Mr Guido Vanrossum tell us about it? As for now I am forced to provide my patched version of SocketServer.py with my releases, what is not quite satisfactory. SocketServer is provided in the python distribution, so I'd rather tell "there is a patch for python..." Well... In fact I forgot to put it in my first release, but I'll correct this this evening :) ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-20 12:06 Message: Logged In: YES user_id=198402 Well I was wrong. We do need a "try" block to ensure the request is always correctly closed: def finish_request(self, request, client_address): """Finish one request by instantiating RequestHandlerClass.""" try: self.RequestHandlerClass(request, client_address, self) finally: self.close_request(request) This works better. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-13 09:09 Message: Logged In: YES user_id=198402 I forgot to tell: I can not test if it does not break the forking server. I only have a windows platform available for now, and forking doesn't work in the python/win32 environment for now as far as I know. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-13 08:51 Message: Logged In: YES user_id=198402 What I propose can be applied without any compatibility issue. I have tried something that seems to work, at least under windows (but it does need to be more fully tested though). Only 2 small modifications are required: -1- In BaseServer, modification of the last line of handle_request: 
    def handle_request(self):
        """Handle one request, possibly blocking."""
        #import time
        try:
            request, client_address = self.get_request()
        except socket.error:
            return
        if self.verify_request(request, client_address):
            try:
                print 'handle 1'
                self.process_request(request, 
client_address)
                print 'handle 2'
            except:
                self.handle_error(request, client_address)
                self.close_request(request)
Note that only the indentation of the last has been modified so that the close_request is executed only if an exception occur. Still we need to close the request after it had been processed, so here comes the second modification: -2- Still in BaseServer: 
    def finish_request(self, request, client_address):
        """Finish one request by instantiating 
RequestHandlerClass."""
        self.RequestHandlerClass(request, client_address, 
self)
        self.close_request(request)
There is already a try/except block in handle_request, so I thought it was not mandatory here to ensure the request was always closed. Oh... I don't know how <PRE> tags are supported by the bugtracking system of sourceforge, so the samples I give may not appear as I want. This is quite a problem with python :/ ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-12 15:46 Message: Logged In: YES user_id=80200 hi there mr xlagraula, yes, it would be a lot simpler... _if_ it wasn't for the fact that this code is likely to already be quite extensively used. a possible 'upgrade' path could be done by providing a... RequestHandler2 class, or some-such. it would be neater to do this, or similar: for t in self.thread_list: t.join(timeout=0.1) which would join all threads, or you do if stopped(), close_request. i looked into threads a bit more: join has a timeout, and there is a stopped-detection function. easy :) ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-12 14:18 Message: Logged In: YES user_id=198402 Another solution could be to modify the behaviour of the server so that it would be the responsibility of the "child" thread/process to close the socket (except for the forking/threading error cases). Wouldn't it be simplier than child process tracking and thread tracking? ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-04 04:17 Message: Logged In: YES user_id=80200 okay. the forkingmixin code does a fork, records how many children there are, and waits for one of them to exit, before proceeding - in particular, before proceeding to close the request, etc. ... so why is not something similar done in ThreadingMixIn? this kinda- tells me that thread-tracking is really needed, in a similar way to that in forkingmixin. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2001-05-03 16:26 Message: Logged In: YES user_id=413 Just a note of another casualty of this bug: I had to add the mentioned dummy close_request method hack to our own ThreadingMixIn class in mojo nation (in the sourceforge mojonation project's evil module, see the common/MojoNationHTTPServer.py file). Without it, python 2.1 would always raise an exception in the request handler as soon as it tried to call self.connection.makefile() because self.connection had apparently already been closed! (its fd was always -1) ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-02 01:41 Message: Logged In: YES user_id=80200 hi there mr jrielh, thank you very much for the details. what i am having a little difficulty with is, what's the difference between this and python 2.0 SocketServer.py? more specifically, i'm looking at python 2.0 SocketServer.py and, whilst i'm not a Threads expert, i see a t.start() but no t.join(). i've been looking at the Queue example code in the test method of threads.py, and start() is called on every thread, followed by join() on every thread. join waits for the thread to finish, yes? so... if that's the case, then python 2.0 SocketServer.py should suffer from exactly the same behaviour, yes? unless python behaves ever-so-slightly differently (timing issues?) when you have an extra base class like this, with the consequence that close_request() is more likely to be called before ThreadingMixIn.process_request(). ? ---------------------------------------------------------------------- Comment By: Jon Riehl (jriehl) Date: 2001-05-01 14:20 Message: Logged In: YES user_id=22448 This is related to bug #419873. The problem is not specifically in the ThreadingMixin specifically, but where BaseServer calls close_request() after calling process_request(). In the threading mixin, process_request() spins the thread and returns, causing the request socket to be invalidated while the thread is still running. The fix given above will keep the socket valid while the thread is running, but may cause the socket to not close properly (my threads generally close the socket when they are done anyway.) ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-04-26 05:41 Message: Logged In: YES user_id=80200 follow-up. i took a look at the differences between SocketServer.py in 2.0 and 2.1. there is one small change by guido to the ThreadingMixIn.process_request() function that calls self.server_close() instead of explicitly calling self.socket.close(), where TCPServer.server_close() calls self.socket.close(). if mr anonymous (hi!) has over-ridden server_close() and explicitly closes the *request* socket, then of course the socket will get closed twice. the rest of the code-mods is a straightforward code-shuffle moving code from TCPServer into BaseServer: from examining the diff, i really don't see how bypassing close_request(), as shown above with the Workaround in the original bug-report, will help: that will in fact cause the request _never_ to be closed! the rest of this report is part of an email exchange with guido, quoted here: "the bug-report doesn't state whether python 2.0 worked and 2.1 didn't: it also doesn't give enough info. for all we know, he's calling close_request() himself or request.close() directly somewhere in his code, and hasn't told anybody, which is why he has to over-ride close_request() and tell it to do nothing. or he's closing the socket in the HandlerClass, in finish(), or something. we just don't know. either that, or his HandlerClass creates a socket once and only once, with the result that close_request() closes the one socket, and he's _completely_ stuffed, then :)" ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-04-26 04:11 Message: Logged In: YES user_id=80200 hi there, i'm the person who wrote the BaseServer class. guido contacted me about it: could you please send me or post here a working test example that demonstrates the problem. i assume, but you do not state, that you have tested your MyHTTPServer with python 2.0, please let us know, here, if that is a correct assumption. thanks! luke ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470 From noreply@sourceforge.net Tue Jul 17 16:22:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Jul 2001 08:22:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-416901 ] 2.1 on OpenBSD 2.8: lots of bugs @ build Message-ID: Bugs item #416901, was opened at 2001-04-17 17:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416901&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brad Allen (valaulmo) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: 2.1 on OpenBSD 2.8: lots of bugs @ build Initial Comment: I am doing a survey of current distributed information systems, to see if they are close to what they should be (I figured out what they should be in 1984), and am forced to find a Python which Mojo Nation is compatible with. I will probably go back to Python 2.0, but since the latest released version (released today!) was 2.1, I just started there (since the stable one for OpenBSD 2.8 was way back at Python 1.6 and I figured anything past that was experimenting anyway). --- Python 2.1 on OpenBSD 2.8 with Pentium I: I'm getting these warnings while compiling Python 2.1 on OpenBSD 2.8: cc -o python \ Modules/python.o \ libpython2.1.a -lc_r -lutil -L/usr/local/lib -lz -lm ./Modules/posixmodule.c:2995: warning: this program uses setreuid(), which is deprecated. ./Modules/posixmodule.c:3014: warning: this program uses setregid(), which is deprecated. ./Modules/posixmodule.c:4147: warning: tempnam() possibly used unsafely; consider using mkstemp() ./Modules/posixmodule.c:4193: warning: tmpnam() possibly used unsafely; consider using mkstemp() ld: libpython2.1.a(fileobject.o): RRS text relocation at 0x31168 for "_flockfile" ld: libpython2.1.a(fileobject.o): RRS text relocation at 0x311af for "_funlockfile" PYTHONPATH= ./python ./setup.py build running build Please consider fixing those things. --- *** HUNG test_bufio.py When running tests as "MAKE=gmake gmake test", it hung under test_bufio. It required a SIGKILL to stop. I tried two things: * Running test as README says manually with "python ...". python ./Lib/test/test_bufio.py This worked OK and produced no output that I was aware of (unless it was hidden). * Tried defining DONT_USE_FGETS_IN_GETLINE in the file where it was looked at (./Objects/fileobject.c). This did not help; it still hung. Running the test manually again at this point worked also. So, I had to find a way to skip that test (hid it in a subdirectory called HIDE). *** HUNG test_complex.py The same thing happened with test_complex.py: it hung during "...make test", but ran OK manually; then I hid it to skip. For test_dl, I got slightly different results; after the usual hanging, I then manually ran it and got: *** HUNG test_dl.py* Q:/usr/local/src/python/Python-2.1:2148$ python Lib/test/test_dl.py Traceback (most recent call last): File "Lib/test/test_dl.py", line 6, in ? import dl ImportError: No module named dl Q:/usr/local/src/python/Python-2.1:2149$ In each case, lots of CPU by the "python" process was used as its "hung" state. I waited approximately three minutes of CPU. A 133Megahertz Pentium with a CPU cache on a Dell computer is extremely fast, and ought to finish any test within two minutes. Tell me if I just failed to wait long enough for an increadibly inefficiently programmed test to complete, and I'll retry it. The fact that it did not respond to signals except KILL also indicates to me that it was comotose. (This discussion reminds me of a date where the person told me that the commands in Unix are very violent sounding and the names of the principles used by programmers are very anti-social. I'm glad someone thinks that way, since English itself is far, far worse, according to http://www.islandnet.com/~edonon/decoding.htm, and I said to myself "how can anybody use this language?" in disgust. Someday we'll fix that, too (and not just for historical politeness; for pureness of utility and efficiency -- snowballed efficiency!).) --- *** MEMORY FAULT test_fork1.py While the tests were running "test_fork1", I got a Memory Fault. Rerunning it manually worked, though, and I hid it also. (I did not test rerunning it.) While waiting for all these tests to hang, I got tired of it and now I want to request that you have all the tests run in parallel. That way, it is easier to weed out all the hanging ones in one shot. This is easy, right? *** HUNG test_compile.py Next to hang was this one: $ python ./Lib/test/test_compile.py Running tests on argument handling testing complex args 1 2 1 2 3 4 1 2 3 1 2 3 2 3 4 $ As you can see, it ran OK manually, and this time I had some output to look at. While looking at it I realized that I do not know if those are the expected results, and in the house I'm in, I have to listen to too much hollaring to be able to learn Python in a few minutes like I am usually able to do in proper environments. *** HUNG test_doctest.py test_doctest.py passed manually but automatically hung, too. It had too much output to include it all, but the last line said the test passed. *** HUNG & SEGFAULT test_threadedtempfile.py For test_threadedtempfile, I got a bad error: $ python Lib/test/test_threadedtempfile.py Creating Starting Reaping Segmentation fault (core dumped) $ rm *core $ python Lib/test/test_threadedtempfile.py Creating Starting Reaping ^C^C^C^Z ^Z^X^C Killed $ $ jobs [1]- Stopped less README [2]+ Stopped MAKE=gmake gmake test $ sync $ rm Lib/test/test_threadedt So far, a few tests ran better the second time than the first. Is the compiling working better than the interpreting? --- Brad Allen * ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-17 08:22 Message: Logged In: YES user_id=3066 I'm looking into getting access to an OpenBSD machine to test on. The last comment in the bug report makes me wonder a bit, however: did you wait for long to see if the tests terminated? Many of the tests will appear to run faster during the second phase of the test since the test modules will have already been byte-compiled, but the byte-code used to execute the tests will be the same during both phases. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-11 11:29 Message: Logged In: YES user_id=3066 The warnings are irrelevant -- any package that wraps those functions to make them available to applications will cause those warnings on OpenBSD, even if they are never used. The other issues require more attention than I can spare this week, so I'll leave this open. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416901&group_id=5470 From noreply@sourceforge.net Tue Jul 17 20:11:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Jul 2001 12:11:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-435026 ] SGI cores on 1.0 / 0 Message-ID: Bugs item #435026, was opened at 2001-06-20 23:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=435026&group_id=5470 Category: Python Interpreter Core Group: 3rd Party Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Drew Whitehouse (drw900) Assigned to: Tim Peters (tim_one) Summary: SGI cores on 1.0 / 0 Initial Comment: python21 cores evaluating 1.0 / 0 on SGI. MIPSpro Compilers: Version 7.3.1.1m SGI_ABI = -n32 ---------------------------------------------------------------------- Comment By: Robert Minsk (rminsk) Date: 2001-07-17 12:11 Message: Logged In: YES user_id=132786 Can you please look at the patch I submited on this bug. I do not think SGI users should suffer because of a compiler bug when a simple workaround exists. ---------------------------------------------------------------------- Comment By: Robert Minsk (rminsk) Date: 2001-06-25 13:23 Message: Logged In: YES user_id=132786 I think we should we change the status of this bug. There is something we can do to keep the same speed on other platforms and work on the SGI. We can make condition code on the sgi by using #ifdef __sgi Please see bug/patch 436193 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-06-22 20:00 Message: Logged In: YES user_id=31435 Nice work, Robert! Now we have a problem: when an optimizer is doing something wrong, then typically (a) there are any number of changes you could make that mask the problem under a specific release of the compiler, but (b) they're accidents, so it will just break again under some other release of the compiler. The PyFloat_AS_DOUBLE () is deliberately under the protection of an "if" test that ensures its legality, so the compiler is insane (not following the rules) in generating code that ignores this: how do you out-think an insane algorithm? You can fool it at random, but since it's not playing by the rules there's nothing *reliable* you can do. For that reason, I'm changing this to "3rd Party" and closing with "Won't Fix" -- it's not our doing, and there's nothing principled we can do about it short of slowing the code on all platforms (by, e.g., using an external function form of PyFloat_AS_DOUBLE, thus inhibiting the bad code generation). By the way, ask SGI to add Python to their standard compiler regression suite: *something* is always broken on SGI boxes, and disabling optimization always fixes it. ---------------------------------------------------------------------- Comment By: Robert Minsk (rminsk) Date: 2001-06-22 17:48 Message: Logged In: YES user_id=132786 After some more investigation it seems to be a CPU pipelining bug in the optimizer. #define CONVERT_TO_DOUBLE(obj, dbl) \ if (PyFloat_Check(obj)) \ dbl = PyFloat_AS_DOUBLE(obj); \ else if (convert_to_double(&(obj), &(dbl)) < 0) \ return obj; PyFloat_Check is a macro as well is PyFloat_AS_DOUBLE. Due to the CPU pipelining PyFloat_AS_DOUBLE (a cast to a double) is always being called. What happens is non-float objects that are not 8-byte aligned are being cast to a double. I am trying to figure out if I can reorder the code to not cause this pipelining issue. I will also see if I can somehow force a nop after PyFloat_Check. I will also open a bug with SGI. ---------------------------------------------------------------------- Comment By: Robert Minsk (rminsk) Date: 2001-06-21 20:42 Message: Logged In: YES user_id=132786 Thank you tim_one for the hint... I still trying to track it down but changing Include/intobject.h PyIntObject to include memory alignment pragmas seem to be the trick. On the SGI I've changed it to #pragma pack(8) typedef struct { PyObject_HEAD long ob_ival; } PyIntObject; #pragma pack(0) This is only a hack until I find a way to get the proper alignment. I'm begining to wonder if anywhere in the float code something is trying to cast a int object to a float object. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-06-21 19:52 Message: Logged In: YES user_id=31435 Robert, let us know if you find it! There's always *some* optimization bug on SGI boxes, but this one is particularly noxious. Someone on c.l.py suggested it may be a problem with Python accessing a double at an unaligned (for the platform) memory address. They didn't follow up, so I don't know whether that's the case, but if it is we would consider it a bug in Python (we try to stick to std C, so if there's an unaligned access it's a bug in our coding -- but I don't see anything like that by eyeball). ---------------------------------------------------------------------- Comment By: Robert Minsk (rminsk) Date: 2001-06-21 19:41 Message: Logged In: YES user_id=132786 Python 2.1 core dumps on any using the 7.3.1.2m compilers with -O2 or greater. If the file Objects/floatobject.c is compiled with -O1 everything seems fine. It is core dumping in the macro CONVERT_TO_DOUBLE. It seems the call stack gets corrupted. I'm trying to find a workaround besides -O1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=435026&group_id=5470 From noreply@sourceforge.net Tue Jul 17 21:28:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Jul 2001 13:28:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-442142 ] DLL base assignments need update Message-ID: Bugs item #442142, was opened at 2001-07-17 13:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442142&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Mark Hammond (mhammond) Summary: DLL base assignments need update Initial Comment: >From c.l.py. The core DLL has grown quite a bit since these addresses were first assigned, and it systematically collides with, e.g. the bsddb and zip DLLs now too. pythonw.exe is also assigned the same base address as the tkinter DLL, which is "a bug". Since any change here has ripple effects into your (Mark's) Win32 extension assignments, I'm assigning this to you for pondering. Heck, you can even feel free to fix it . """ From: Robin Becker Sent: Tuesday, July 17, 2001 9:21 AM To: python-list@python.org Subject: python2.1 pythonw.exe base address I don't know how much this is of real interest, but using the latest proc explorer from http://www.sysinternals.com/ I notice that pythonw.exe has a base address of 0x1e190000, but that python21.dll wants to reside at 0x1e100000 and has a length of 0xAF000, the result is that python21.dll gets relocated. Redefining the base address of pythonw to be something non-controversial that didn't overlap would be a zero cost win for tk apps. as an aside it seems that tcl83.dll and _tkinter.pyd are also relocated, but I don't know the desired base address. """ ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442142&group_id=5470 From noreply@sourceforge.net Wed Jul 18 06:57:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Jul 2001 22:57:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-442142 ] DLL base assignments need update Message-ID: Bugs item #442142, was opened at 2001-07-17 13:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442142&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Mark Hammond (mhammond) Summary: DLL base assignments need update Initial Comment: >From c.l.py. The core DLL has grown quite a bit since these addresses were first assigned, and it systematically collides with, e.g. the bsddb and zip DLLs now too. pythonw.exe is also assigned the same base address as the tkinter DLL, which is "a bug". Since any change here has ripple effects into your (Mark's) Win32 extension assignments, I'm assigning this to you for pondering. Heck, you can even feel free to fix it . """ From: Robin Becker Sent: Tuesday, July 17, 2001 9:21 AM To: python-list@python.org Subject: python2.1 pythonw.exe base address I don't know how much this is of real interest, but using the latest proc explorer from http://www.sysinternals.com/ I notice that pythonw.exe has a base address of 0x1e190000, but that python21.dll wants to reside at 0x1e100000 and has a length of 0xAF000, the result is that python21.dll gets relocated. Redefining the base address of pythonw to be something non-controversial that didn't overlap would be a zero cost win for tk apps. as an aside it seems that tcl83.dll and _tkinter.pyd are also relocated, but I don't know the desired base address. """ ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2001-07-17 22:57 Message: Logged In: YES user_id=14198 [From a followup on the newsgroup] Yes; "link /dump /headers" shows the same thing. Why isn't pythonw.exe based at 00400000 like most well- behaved executables? Rebasing to 1E190000 unnecessarily fragments linear space. --- tcl83.dll is at the default base of 10000000. _tkinter.pyd is set to 1E190000, same as pythonw.exe. I have to believe the pythonw.exe base address is a bug. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442142&group_id=5470 From noreply@sourceforge.net Wed Jul 18 12:13:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 04:13:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-231207 ] Fatal Python Error during program shutdown Message-ID: Bugs item #231207, was opened at 2001-02-05 18:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231207&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Doug Henderson (djhender) Assigned to: Fredrik Lundh (effbot) Summary: Fatal Python Error during program shutdown Initial Comment: The windows builds of versions 2.0 and 2.1a2 contain an intermittent bug which often appears when a script using Tkinter stops by calling self.tk.quit() and sometimes (less often) appears following a event or call to a ?.destory() function. Under Windows 98SE, this results in a GPF. Under Windows 2000, a message to the console window shows "Fatal Python Error", "PyEval_RestoreThread NULL tstate". The following script demonstrates the problem: --------------------- # BugDemo.py from Tkinter import * class BugDemo(Frame): def __init__(self, parent): Frame.__init__(self, parent) Button(self, text='Hi', command=self.hi).pack() Button(self, text='Quit', command=self.tk.quit).pack() def hi(self): print "hi" bd = BugDemo(Tk()) bd.pack() bd.mainloop() ---------------------- Execute in console window: "c:> python BugDemo.py" Test this by 1) clicking Quit button 2) clicking Hi button, then Quit button. Test 1: The script runs successfully most of the time. I found I had to minimize and restore its window to make it fail regularly. Test 2: I need to click Hi button before clicking the Quit button. Then it failed about half the time. The problem appears to occur after the script has completed, during some kind of cleanup perhaps. The more useful error message on the Win2k machine may help to locate the problem. Problem also manifests using the PythonWare 2.0 release on Win98. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-18 04:13 Message: Logged In: NO i won't to be a hacker ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-05-29 00:30 Message: Logged In: NO Note: I am running Windows98 ActivePython 2.1 Even with console apps in python this same error appears I tried using another Distribution of Python for win32, PythonWare20 So this leads me to believe that some lib is missing on win98. Because at work I use Win95, and Installed ActivePython 2.1, and it works fine and dandy ---------------------------------------------------------------------- Comment By: Joel Gould (joelgould) Date: 2001-03-24 08:52 Message: Logged In: YES user_id=20954 I also see a GPF on shutdown under Windows 98 using Tkinter. I tested this using the PythonWare 2.0 release as well. I have attached a very simple Tkinter program. When I run this on my Windows 98 SE machine, a crash occurs when the program exits. Without the MainDialog class it works OK. Without the Pmw initialization call it works OK. But as written it will crash around 75% of the time. (1) run the program (2) press the Test Button (3) click Cancel in the file open dialog (you do not need to select a file) (4) click the close button in the upper right corner --> Boom -------------------- import Tkinter import tkFileDialog import Pmw def action(): tkFileDialog.askopenfilename(filetypes=[('All','*')]) class MainDialog: def __init__(self,parent): Tkinter.Button(parent,text='Test Button',command=action).pack() root = Pmw.initialise() dialog = MainDialog(root) root.mainloop() ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-02-09 15:34 Message: Assigned to /F, under the theory he can confirm that "this kind of thing" is still a general problem with Tk we can't do anything about. ---------------------------------------------------------------------- Comment By: Doug Henderson (djhender) Date: 2001-02-05 21:30 Message: See also #116289 (and my comment to it) which describes what often happened to my 'real' programs which lead to developing the above BugDemo script. My 'real' programs were developed over the last two years or so, and worked in Jan 2000 with 1.5.2. I upgraded the Python version recently, and then started working on these programs again. It was "WTF is wrong with my code", until I found the same problem showing up in the small test cases. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231207&group_id=5470 From noreply@sourceforge.net Wed Jul 18 12:24:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 04:24:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-442374 ] Modulefinder registry support broken Message-ID: Bugs item #442374, was opened at 2001-07-18 04:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442374&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Modulefinder registry support broken Initial Comment: The Modulefinder registry support is broken. It uses _winreg.QueryValueEx() instead of winreg.QueryValue(). The attached diff fixes this, and also adds support to query the registry via win32api if _winreg could not be imported. This way modulefinder is compatible with Python 1.5.2 up to 2.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442374&group_id=5470 From noreply@sourceforge.net Wed Jul 18 12:26:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 04:26:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-442374 ] Modulefinder registry support broken Message-ID: Bugs item #442374, was opened at 2001-07-18 04:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442374&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) >Assigned to: Mark Hammond (mhammond) Summary: Modulefinder registry support broken Initial Comment: The Modulefinder registry support is broken. It uses _winreg.QueryValueEx() instead of winreg.QueryValue(). The attached diff fixes this, and also adds support to query the registry via win32api if _winreg could not be imported. This way modulefinder is compatible with Python 1.5.2 up to 2.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442374&group_id=5470 From noreply@sourceforge.net Wed Jul 18 14:36:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 06:36:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn Message-ID: Bugs item #417845, was opened at 2001-04-21 08:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470 Category: Python Library Group: None Status: Open Resolution: Fixed Priority: 3 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: Python 2.1: SocketServer.ThreadingMixIn Initial Comment: SocketServer.ThreadingMixIn does not work properly since it tries to close the socket of a request two times. Workaround for using SocketServer.ThreadingMixIn under Python 2.1: class MyThreadingHTTPServer( SocketServer.ThreadingMixIn, MyHTTPServer ): def close_request(self, request): pass ---------------------------------------------------------------------- Comment By: Stian Soiland (stain) Date: 2001-07-18 06:36 Message: Logged In: YES user_id=25921 By waiting for 2.2 for this simple patch even more future code would break. The programmer would need to write seperate code for 2.0, 2.1 and 2.2. Why should we want that? It should not take much time reviewing these 6 lines of change. Anyone else care to comment? (This message quoted in posting on comp.lang.python) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-17 07:30 Message: Logged In: YES user_id=6380 I have absolutely no time to review this right now. This won't be fixed in 2.1.x; I'll look into making that change for 2.2 at some point. ---------------------------------------------------------------------- Comment By: Stian Soiland (stain) Date: 2001-07-13 14:51 Message: Logged In: YES user_id=25921 I don't think it's a good idea to let closing the request be the handler's responsibility. It's better to let the ThreadingMixIn do it: stain@zoidberg:~$ diff -u SocketServer-cvs-1.24.2.1.py SocketServer.py --- SocketServer-cvs-1.24.2.1.py Fri Jul 13 23:20:26 2001 +++ SocketServer.py Fri Jul 13 23:34:02 2001 @@ -451,8 +451,10 @@ def process_request(self, request, client_address): """Start a new thread to process the request.""" import threading - t = threading.Thread(target = self.finish_request, - args = (request, client_address)) + # Call the BaseServers process_request to close the + # socket after finally_request. + t = threading.Thread(target = BaseServer.process_request, + args = (self, request, client_address)) t.start() In my eyes this is the best, making the overriden process_request behaving like the original process_request. This would make the difference between Threading-servers and other servers smaller. If it looks bad with BaseServer-references inside ThreadingMixIn, what about a method of ThreadingMixIn named __process_request with the same code as BaseServer.process_request? -- Stian Soiland ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-07-11 14:45 Message: Logged In: YES user_id=7887 Ohh, I'm sorry. I've read comments the other way around. The last comment seemed to be the one at bottom (as usual), then it looked like it was not definetly fixed. I'll checkout the fix from cvs. Thanks! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 14:22 Message: Logged In: YES user_id=6380 Gustavo, yes it's fixed in CVS (just read on and you;ll see my announcement). We're going to release a bugfix update release for Python 2.1, Python 2.1.1 soon, and it will be in that release too. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-07-11 14:19 Message: Logged In: YES user_id=7887 Just wondering, is this bug fixed somewhere (cvs, etc)?? Python 2.1 + SOAP.py seem to have this problem, when using the ThreadingTCPServer. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 06:59 Message: Logged In: YES user_id=6380 Yes, the thread is responsible for calling self.close_request() in self.finish_request(). (Although if you just rely on reference counting, it should go away all by itself too.) I don't read the newsgroup frequently, but you can try email if you have more problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-10 05:47 Message: Logged In: NO I tried the fix and it seems to work. I'm wondering if the thread is responsible for calling self.close_request() in self.finish_request? Note: Can we discuss it in news:comp.lang.python? I hate that web interface with Cookies! That's the reason why I was too lazy to login when submitting this bug report. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 04:59 Message: Logged In: YES user_id=6380 I've developed a proper fix for this, I hope. Check out the latest SocketServer.py from the CVS tree. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-07-02 09:05 Message: Logged In: YES user_id=198402 There is still a problem with your solution, Mr glchapman: you make a copy to ensure that the server won't close the copy of the socket that is used in the child thread. Right. But WHO will close this very copy then? The thread still has to close it if one wants to be "clean". So as long as the child thread must close its copy in the threading case, why not make it a thumb rule? Why should we bother about closing anything in the main thread? I still think the solution that I provide is best: make the request handler always responsible for closing the socket from which the request comes. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2001-06-29 08:49 Message: Logged In: YES user_id=86307 Since the request socket object is only a lightweight wrapper around the real socket, why not simply pass request.dup() to the new thread? Then the server's call to close_request affects only its copy of request, not the copy being used in the thread. For example, the following change to ThreadingMixIn fixed this bug for me in a (very simple) test program: def process_request(self, request, client_address): """Start a new thread to process the request.""" import threading t = threading.Thread(target = self.finish_request, args = (request.dup(), client_address)) t.start() ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-28 05:20 Message: Logged In: YES user_id=198402 I have now started a project here concerning a SOCKS proxy written in python (PySocks). It is aimed mostly at people who use a windows box to share their internet connection and uses the threading server from the SocketServer module. So it becomes VERY important to me to know of what will be done about this bug, in the next release/patch of Python library. Could Mr Guido Vanrossum tell us about it? As for now I am forced to provide my patched version of SocketServer.py with my releases, what is not quite satisfactory. SocketServer is provided in the python distribution, so I'd rather tell "there is a patch for python..." Well... In fact I forgot to put it in my first release, but I'll correct this this evening :) ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-20 12:06 Message: Logged In: YES user_id=198402 Well I was wrong. We do need a "try" block to ensure the request is always correctly closed: def finish_request(self, request, client_address): """Finish one request by instantiating RequestHandlerClass.""" try: self.RequestHandlerClass(request, client_address, self) finally: self.close_request(request) This works better. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-13 09:09 Message: Logged In: YES user_id=198402 I forgot to tell: I can not test if it does not break the forking server. I only have a windows platform available for now, and forking doesn't work in the python/win32 environment for now as far as I know. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-13 08:51 Message: Logged In: YES user_id=198402 What I propose can be applied without any compatibility issue. I have tried something that seems to work, at least under windows (but it does need to be more fully tested though). Only 2 small modifications are required: -1- In BaseServer, modification of the last line of handle_request: 
    def handle_request(self):
        """Handle one request, possibly blocking."""
        #import time
        try:
            request, client_address = self.get_request()
        except socket.error:
            return
        if self.verify_request(request, client_address):
            try:
                print 'handle 1'
                self.process_request(request, 
client_address)
                print 'handle 2'
            except:
                self.handle_error(request, client_address)
                self.close_request(request)
Note that only the indentation of the last has been modified so that the close_request is executed only if an exception occur. Still we need to close the request after it had been processed, so here comes the second modification: -2- Still in BaseServer: 
    def finish_request(self, request, client_address):
        """Finish one request by instantiating 
RequestHandlerClass."""
        self.RequestHandlerClass(request, client_address, 
self)
        self.close_request(request)
There is already a try/except block in handle_request, so I thought it was not mandatory here to ensure the request was always closed. Oh... I don't know how <PRE> tags are supported by the bugtracking system of sourceforge, so the samples I give may not appear as I want. This is quite a problem with python :/ ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-12 15:46 Message: Logged In: YES user_id=80200 hi there mr xlagraula, yes, it would be a lot simpler... _if_ it wasn't for the fact that this code is likely to already be quite extensively used. a possible 'upgrade' path could be done by providing a... RequestHandler2 class, or some-such. it would be neater to do this, or similar: for t in self.thread_list: t.join(timeout=0.1) which would join all threads, or you do if stopped(), close_request. i looked into threads a bit more: join has a timeout, and there is a stopped-detection function. easy :) ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-12 14:18 Message: Logged In: YES user_id=198402 Another solution could be to modify the behaviour of the server so that it would be the responsibility of the "child" thread/process to close the socket (except for the forking/threading error cases). Wouldn't it be simplier than child process tracking and thread tracking? ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-04 04:17 Message: Logged In: YES user_id=80200 okay. the forkingmixin code does a fork, records how many children there are, and waits for one of them to exit, before proceeding - in particular, before proceeding to close the request, etc. ... so why is not something similar done in ThreadingMixIn? this kinda- tells me that thread-tracking is really needed, in a similar way to that in forkingmixin. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2001-05-03 16:26 Message: Logged In: YES user_id=413 Just a note of another casualty of this bug: I had to add the mentioned dummy close_request method hack to our own ThreadingMixIn class in mojo nation (in the sourceforge mojonation project's evil module, see the common/MojoNationHTTPServer.py file). Without it, python 2.1 would always raise an exception in the request handler as soon as it tried to call self.connection.makefile() because self.connection had apparently already been closed! (its fd was always -1) ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-02 01:41 Message: Logged In: YES user_id=80200 hi there mr jrielh, thank you very much for the details. what i am having a little difficulty with is, what's the difference between this and python 2.0 SocketServer.py? more specifically, i'm looking at python 2.0 SocketServer.py and, whilst i'm not a Threads expert, i see a t.start() but no t.join(). i've been looking at the Queue example code in the test method of threads.py, and start() is called on every thread, followed by join() on every thread. join waits for the thread to finish, yes? so... if that's the case, then python 2.0 SocketServer.py should suffer from exactly the same behaviour, yes? unless python behaves ever-so-slightly differently (timing issues?) when you have an extra base class like this, with the consequence that close_request() is more likely to be called before ThreadingMixIn.process_request(). ? ---------------------------------------------------------------------- Comment By: Jon Riehl (jriehl) Date: 2001-05-01 14:20 Message: Logged In: YES user_id=22448 This is related to bug #419873. The problem is not specifically in the ThreadingMixin specifically, but where BaseServer calls close_request() after calling process_request(). In the threading mixin, process_request() spins the thread and returns, causing the request socket to be invalidated while the thread is still running. The fix given above will keep the socket valid while the thread is running, but may cause the socket to not close properly (my threads generally close the socket when they are done anyway.) ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-04-26 05:41 Message: Logged In: YES user_id=80200 follow-up. i took a look at the differences between SocketServer.py in 2.0 and 2.1. there is one small change by guido to the ThreadingMixIn.process_request() function that calls self.server_close() instead of explicitly calling self.socket.close(), where TCPServer.server_close() calls self.socket.close(). if mr anonymous (hi!) has over-ridden server_close() and explicitly closes the *request* socket, then of course the socket will get closed twice. the rest of the code-mods is a straightforward code-shuffle moving code from TCPServer into BaseServer: from examining the diff, i really don't see how bypassing close_request(), as shown above with the Workaround in the original bug-report, will help: that will in fact cause the request _never_ to be closed! the rest of this report is part of an email exchange with guido, quoted here: "the bug-report doesn't state whether python 2.0 worked and 2.1 didn't: it also doesn't give enough info. for all we know, he's calling close_request() himself or request.close() directly somewhere in his code, and hasn't told anybody, which is why he has to over-ride close_request() and tell it to do nothing. or he's closing the socket in the HandlerClass, in finish(), or something. we just don't know. either that, or his HandlerClass creates a socket once and only once, with the result that close_request() closes the one socket, and he's _completely_ stuffed, then :)" ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-04-26 04:11 Message: Logged In: YES user_id=80200 hi there, i'm the person who wrote the BaseServer class. guido contacted me about it: could you please send me or post here a working test example that demonstrates the problem. i assume, but you do not state, that you have tested your MyHTTPServer with python 2.0, please let us know, here, if that is a correct assumption. thanks! luke ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470 From noreply@sourceforge.net Wed Jul 18 14:56:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 06:56:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn Message-ID: Bugs item #417845, was opened at 2001-04-21 08:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470 Category: Python Library Group: None Status: Open Resolution: Fixed Priority: 3 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: Python 2.1: SocketServer.ThreadingMixIn Initial Comment: SocketServer.ThreadingMixIn does not work properly since it tries to close the socket of a request two times. Workaround for using SocketServer.ThreadingMixIn under Python 2.1: class MyThreadingHTTPServer( SocketServer.ThreadingMixIn, MyHTTPServer ): def close_request(self, request): pass ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-18 06:56 Message: Logged In: YES user_id=6380 You can close a socket more than once, so it's easy to write code that works under either assumption. Since calling a different method is a feature change, we really can't make this change in 2.1.1. ---------------------------------------------------------------------- Comment By: Stian Soiland (stain) Date: 2001-07-18 06:36 Message: Logged In: YES user_id=25921 By waiting for 2.2 for this simple patch even more future code would break. The programmer would need to write seperate code for 2.0, 2.1 and 2.2. Why should we want that? It should not take much time reviewing these 6 lines of change. Anyone else care to comment? (This message quoted in posting on comp.lang.python) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-17 07:30 Message: Logged In: YES user_id=6380 I have absolutely no time to review this right now. This won't be fixed in 2.1.x; I'll look into making that change for 2.2 at some point. ---------------------------------------------------------------------- Comment By: Stian Soiland (stain) Date: 2001-07-13 14:51 Message: Logged In: YES user_id=25921 I don't think it's a good idea to let closing the request be the handler's responsibility. It's better to let the ThreadingMixIn do it: stain@zoidberg:~$ diff -u SocketServer-cvs-1.24.2.1.py SocketServer.py --- SocketServer-cvs-1.24.2.1.py Fri Jul 13 23:20:26 2001 +++ SocketServer.py Fri Jul 13 23:34:02 2001 @@ -451,8 +451,10 @@ def process_request(self, request, client_address): """Start a new thread to process the request.""" import threading - t = threading.Thread(target = self.finish_request, - args = (request, client_address)) + # Call the BaseServers process_request to close the + # socket after finally_request. + t = threading.Thread(target = BaseServer.process_request, + args = (self, request, client_address)) t.start() In my eyes this is the best, making the overriden process_request behaving like the original process_request. This would make the difference between Threading-servers and other servers smaller. If it looks bad with BaseServer-references inside ThreadingMixIn, what about a method of ThreadingMixIn named __process_request with the same code as BaseServer.process_request? -- Stian Soiland ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-07-11 14:45 Message: Logged In: YES user_id=7887 Ohh, I'm sorry. I've read comments the other way around. The last comment seemed to be the one at bottom (as usual), then it looked like it was not definetly fixed. I'll checkout the fix from cvs. Thanks! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-11 14:22 Message: Logged In: YES user_id=6380 Gustavo, yes it's fixed in CVS (just read on and you;ll see my announcement). We're going to release a bugfix update release for Python 2.1, Python 2.1.1 soon, and it will be in that release too. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2001-07-11 14:19 Message: Logged In: YES user_id=7887 Just wondering, is this bug fixed somewhere (cvs, etc)?? Python 2.1 + SOAP.py seem to have this problem, when using the ThreadingTCPServer. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 06:59 Message: Logged In: YES user_id=6380 Yes, the thread is responsible for calling self.close_request() in self.finish_request(). (Although if you just rely on reference counting, it should go away all by itself too.) I don't read the newsgroup frequently, but you can try email if you have more problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-10 05:47 Message: Logged In: NO I tried the fix and it seems to work. I'm wondering if the thread is responsible for calling self.close_request() in self.finish_request? Note: Can we discuss it in news:comp.lang.python? I hate that web interface with Cookies! That's the reason why I was too lazy to login when submitting this bug report. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-10 04:59 Message: Logged In: YES user_id=6380 I've developed a proper fix for this, I hope. Check out the latest SocketServer.py from the CVS tree. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-07-02 09:05 Message: Logged In: YES user_id=198402 There is still a problem with your solution, Mr glchapman: you make a copy to ensure that the server won't close the copy of the socket that is used in the child thread. Right. But WHO will close this very copy then? The thread still has to close it if one wants to be "clean". So as long as the child thread must close its copy in the threading case, why not make it a thumb rule? Why should we bother about closing anything in the main thread? I still think the solution that I provide is best: make the request handler always responsible for closing the socket from which the request comes. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2001-06-29 08:49 Message: Logged In: YES user_id=86307 Since the request socket object is only a lightweight wrapper around the real socket, why not simply pass request.dup() to the new thread? Then the server's call to close_request affects only its copy of request, not the copy being used in the thread. For example, the following change to ThreadingMixIn fixed this bug for me in a (very simple) test program: def process_request(self, request, client_address): """Start a new thread to process the request.""" import threading t = threading.Thread(target = self.finish_request, args = (request.dup(), client_address)) t.start() ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-28 05:20 Message: Logged In: YES user_id=198402 I have now started a project here concerning a SOCKS proxy written in python (PySocks). It is aimed mostly at people who use a windows box to share their internet connection and uses the threading server from the SocketServer module. So it becomes VERY important to me to know of what will be done about this bug, in the next release/patch of Python library. Could Mr Guido Vanrossum tell us about it? As for now I am forced to provide my patched version of SocketServer.py with my releases, what is not quite satisfactory. SocketServer is provided in the python distribution, so I'd rather tell "there is a patch for python..." Well... In fact I forgot to put it in my first release, but I'll correct this this evening :) ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-20 12:06 Message: Logged In: YES user_id=198402 Well I was wrong. We do need a "try" block to ensure the request is always correctly closed: def finish_request(self, request, client_address): """Finish one request by instantiating RequestHandlerClass.""" try: self.RequestHandlerClass(request, client_address, self) finally: self.close_request(request) This works better. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-13 09:09 Message: Logged In: YES user_id=198402 I forgot to tell: I can not test if it does not break the forking server. I only have a windows platform available for now, and forking doesn't work in the python/win32 environment for now as far as I know. ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-13 08:51 Message: Logged In: YES user_id=198402 What I propose can be applied without any compatibility issue. I have tried something that seems to work, at least under windows (but it does need to be more fully tested though). Only 2 small modifications are required: -1- In BaseServer, modification of the last line of handle_request: 
    def handle_request(self):
        """Handle one request, possibly blocking."""
        #import time
        try:
            request, client_address = self.get_request()
        except socket.error:
            return
        if self.verify_request(request, client_address):
            try:
                print 'handle 1'
                self.process_request(request, 
client_address)
                print 'handle 2'
            except:
                self.handle_error(request, client_address)
                self.close_request(request)
Note that only the indentation of the last has been modified so that the close_request is executed only if an exception occur. Still we need to close the request after it had been processed, so here comes the second modification: -2- Still in BaseServer: 
    def finish_request(self, request, client_address):
        """Finish one request by instantiating 
RequestHandlerClass."""
        self.RequestHandlerClass(request, client_address, 
self)
        self.close_request(request)
There is already a try/except block in handle_request, so I thought it was not mandatory here to ensure the request was always closed. Oh... I don't know how <PRE> tags are supported by the bugtracking system of sourceforge, so the samples I give may not appear as I want. This is quite a problem with python :/ ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-12 15:46 Message: Logged In: YES user_id=80200 hi there mr xlagraula, yes, it would be a lot simpler... _if_ it wasn't for the fact that this code is likely to already be quite extensively used. a possible 'upgrade' path could be done by providing a... RequestHandler2 class, or some-such. it would be neater to do this, or similar: for t in self.thread_list: t.join(timeout=0.1) which would join all threads, or you do if stopped(), close_request. i looked into threads a bit more: join has a timeout, and there is a stopped-detection function. easy :) ---------------------------------------------------------------------- Comment By: Xavier Lagraula (xlagraula) Date: 2001-05-12 14:18 Message: Logged In: YES user_id=198402 Another solution could be to modify the behaviour of the server so that it would be the responsibility of the "child" thread/process to close the socket (except for the forking/threading error cases). Wouldn't it be simplier than child process tracking and thread tracking? ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-04 04:17 Message: Logged In: YES user_id=80200 okay. the forkingmixin code does a fork, records how many children there are, and waits for one of them to exit, before proceeding - in particular, before proceeding to close the request, etc. ... so why is not something similar done in ThreadingMixIn? this kinda- tells me that thread-tracking is really needed, in a similar way to that in forkingmixin. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2001-05-03 16:26 Message: Logged In: YES user_id=413 Just a note of another casualty of this bug: I had to add the mentioned dummy close_request method hack to our own ThreadingMixIn class in mojo nation (in the sourceforge mojonation project's evil module, see the common/MojoNationHTTPServer.py file). Without it, python 2.1 would always raise an exception in the request handler as soon as it tried to call self.connection.makefile() because self.connection had apparently already been closed! (its fd was always -1) ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-05-02 01:41 Message: Logged In: YES user_id=80200 hi there mr jrielh, thank you very much for the details. what i am having a little difficulty with is, what's the difference between this and python 2.0 SocketServer.py? more specifically, i'm looking at python 2.0 SocketServer.py and, whilst i'm not a Threads expert, i see a t.start() but no t.join(). i've been looking at the Queue example code in the test method of threads.py, and start() is called on every thread, followed by join() on every thread. join waits for the thread to finish, yes? so... if that's the case, then python 2.0 SocketServer.py should suffer from exactly the same behaviour, yes? unless python behaves ever-so-slightly differently (timing issues?) when you have an extra base class like this, with the consequence that close_request() is more likely to be called before ThreadingMixIn.process_request(). ? ---------------------------------------------------------------------- Comment By: Jon Riehl (jriehl) Date: 2001-05-01 14:20 Message: Logged In: YES user_id=22448 This is related to bug #419873. The problem is not specifically in the ThreadingMixin specifically, but where BaseServer calls close_request() after calling process_request(). In the threading mixin, process_request() spins the thread and returns, causing the request socket to be invalidated while the thread is still running. The fix given above will keep the socket valid while the thread is running, but may cause the socket to not close properly (my threads generally close the socket when they are done anyway.) ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-04-26 05:41 Message: Logged In: YES user_id=80200 follow-up. i took a look at the differences between SocketServer.py in 2.0 and 2.1. there is one small change by guido to the ThreadingMixIn.process_request() function that calls self.server_close() instead of explicitly calling self.socket.close(), where TCPServer.server_close() calls self.socket.close(). if mr anonymous (hi!) has over-ridden server_close() and explicitly closes the *request* socket, then of course the socket will get closed twice. the rest of the code-mods is a straightforward code-shuffle moving code from TCPServer into BaseServer: from examining the diff, i really don't see how bypassing close_request(), as shown above with the Workaround in the original bug-report, will help: that will in fact cause the request _never_ to be closed! the rest of this report is part of an email exchange with guido, quoted here: "the bug-report doesn't state whether python 2.0 worked and 2.1 didn't: it also doesn't give enough info. for all we know, he's calling close_request() himself or request.close() directly somewhere in his code, and hasn't told anybody, which is why he has to over-ride close_request() and tell it to do nothing. or he's closing the socket in the HandlerClass, in finish(), or something. we just don't know. either that, or his HandlerClass creates a socket once and only once, with the result that close_request() closes the one socket, and he's _completely_ stuffed, then :)" ---------------------------------------------------------------------- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2001-04-26 04:11 Message: Logged In: YES user_id=80200 hi there, i'm the person who wrote the BaseServer class. guido contacted me about it: could you please send me or post here a working test example that demonstrates the problem. i assume, but you do not state, that you have tested your MyHTTPServer with python 2.0, please let us know, here, if that is a correct assumption. thanks! luke ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470 From noreply@sourceforge.net Wed Jul 18 17:24:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 09:24:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-440486 ] IPv6-related definitions always present Message-ID: Bugs item #440486, was opened at 2001-07-11 12:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440486&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Martin v. Löwis (loewis) Summary: IPv6-related definitions always present Initial Comment: Compiling Python today, I noticed that there are two new -D options: gcc -c -g -O3 -Wall -Wstrict-prototypes -Dss_family=__ss_family -Dss_len=__ss_len ... configure.in seems to always add them to OPT; is this necessary? Should they only be added if --enable-ipv6 is supplied, or moved into an appropriate .h file? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-18 09:24 Message: Logged In: YES user_id=21627 Fixed in configure.in 1.229. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440486&group_id=5470 From noreply@sourceforge.net Wed Jul 18 19:04:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 11:04:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-442501 ] class.__module__ in 2.2 Message-ID: Bugs item #442501, was opened at 2001-07-18 11:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442501&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: class.__module__ in 2.2 Initial Comment: The following little test script for Python 2.2 ---- class foo: pass class bar(object): pass print foo.__module__ print bar.__module__ ---- prints __main__ __builtin__ IMHO it should print __main__ twice. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442501&group_id=5470 From noreply@sourceforge.net Wed Jul 18 19:21:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 11:21:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-442501 ] class.__module__ in 2.2 Message-ID: Bugs item #442501, was opened at 2001-07-18 11:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442501&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Guido van Rossum (gvanrossum) Summary: class.__module__ in 2.2 Initial Comment: The following little test script for Python 2.2 ---- class foo: pass class bar(object): pass print foo.__module__ print bar.__module__ ---- prints __main__ __builtin__ IMHO it should print __main__ twice. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-18 11:21 Message: Logged In: YES user_id=6380 Yes, you're right. I need to figure out a way to set the __module__ property properly. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442501&group_id=5470 From noreply@sourceforge.net Wed Jul 18 19:21:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 11:21:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-442501 ] class.__module__ in 2.2 Message-ID: Bugs item #442501, was opened at 2001-07-18 11:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442501&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: class.__module__ in 2.2 Initial Comment: The following little test script for Python 2.2 ---- class foo: pass class bar(object): pass print foo.__module__ print bar.__module__ ---- prints __main__ __builtin__ IMHO it should print __main__ twice. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-18 11:21 Message: Logged In: YES user_id=6380 Yes, you're right. I need to figure out a way to set the __module__ property properly. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442501&group_id=5470 From noreply@sourceforge.net Wed Jul 18 19:25:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 11:25:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-442501 ] class.__module__ in 2.2 Message-ID: Bugs item #442501, was opened at 2001-07-18 11:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442501&group_id=5470 >Category: type/class unification >Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: class.__module__ in 2.2 Initial Comment: The following little test script for Python 2.2 ---- class foo: pass class bar(object): pass print foo.__module__ print bar.__module__ ---- prints __main__ __builtin__ IMHO it should print __main__ twice. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-18 11:21 Message: Logged In: YES user_id=6380 Yes, you're right. I need to figure out a way to set the __module__ property properly. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442501&group_id=5470 From noreply@sourceforge.net Wed Jul 18 19:39:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 11:39:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-442520 ] test_struct fails on SPARC Message-ID: Bugs item #442520, was opened at 2001-07-18 11:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442520&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Tim Peters (tim_one) Summary: test_struct fails on SPARC Initial Comment: With structmodule.c 2.48, test_struct fails on SPARC Solaris with a SIGSEGV. This is caused by the assignment * (LONG_LONG *)p = x; in np_longlong, where p is 0x1ac684, i.e. this is an unaligned access. The Python caller is struct.pack("q", 5) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442520&group_id=5470 From noreply@sourceforge.net Wed Jul 18 19:44:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 11:44:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-442526 ] lang ref: Unicode literals undocumented Message-ID: Bugs item #442526, was opened at 2001-07-18 11:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442526&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 6 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: lang ref: Unicode literals undocumented Initial Comment: I'm not really sure who *should* be writing the section on Unicode literals, but it needs to be done sooner rather than later. This is section 2.4.3 in the language reference, "Unicode literals," in Doc/ref/ref2.tex. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442526&group_id=5470 From noreply@sourceforge.net Wed Jul 18 20:11:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 12:11:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-442520 ] test_struct fails on SPARC Message-ID: Bugs item #442520, was opened at 2001-07-18 11:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442520&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Martin v. Löwis (loewis) Assigned to: Tim Peters (tim_one) Summary: test_struct fails on SPARC Initial Comment: With structmodule.c 2.48, test_struct fails on SPARC Solaris with a SIGSEGV. This is caused by the assignment * (LONG_LONG *)p = x; in np_longlong, where p is 0x1ac684, i.e. this is an unaligned access. The Python caller is struct.pack("q", 5) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-18 12:11 Message: Logged In: YES user_id=31435 Yuck. I believe it. Boosted priority. We ultimately get *p via the ob_sval member of a PyStringObject, obtained by struct_pack via PyString_FromStringAndSize. The malloc in the latter is only going to guarantee to align the start of ob_sval to what the preceding stringobject members force it to be. I suppose struck_pack has to overallocate string space in this case, and compute an appropriately aligned offset *into* ob_sval at which to begin packing, and then shift the string "left" in memory again after packing. Got a better idea? BTW, I'm sure struct.unpack is going to have an isomorphic problem on this platform. Eww -- that sucks. Possibly better to read/write a byte at a time, and out-think the endianness problem ... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442520&group_id=5470 From noreply@sourceforge.net Wed Jul 18 20:15:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 12:15:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-442520 ] test_struct fails on SPARC Message-ID: Bugs item #442520, was opened at 2001-07-18 11:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442520&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 6 Submitted By: Martin v. Löwis (loewis) Assigned to: Tim Peters (tim_one) Summary: test_struct fails on SPARC Initial Comment: With structmodule.c 2.48, test_struct fails on SPARC Solaris with a SIGSEGV. This is caused by the assignment * (LONG_LONG *)p = x; in np_longlong, where p is 0x1ac684, i.e. this is an unaligned access. The Python caller is struct.pack("q", 5) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-18 12:15 Message: Logged In: YES user_id=6380 Why not use memcpy()? E.g. memcpy(p, (char *)&x, sizeof x). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-18 12:11 Message: Logged In: YES user_id=31435 Yuck. I believe it. Boosted priority. We ultimately get *p via the ob_sval member of a PyStringObject, obtained by struct_pack via PyString_FromStringAndSize. The malloc in the latter is only going to guarantee to align the start of ob_sval to what the preceding stringobject members force it to be. I suppose struck_pack has to overallocate string space in this case, and compute an appropriately aligned offset *into* ob_sval at which to begin packing, and then shift the string "left" in memory again after packing. Got a better idea? BTW, I'm sure struct.unpack is going to have an isomorphic problem on this platform. Eww -- that sucks. Possibly better to read/write a byte at a time, and out-think the endianness problem ... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442520&group_id=5470 From noreply@sourceforge.net Wed Jul 18 20:30:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 12:30:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-442520 ] test_struct fails on SPARC Message-ID: Bugs item #442520, was opened at 2001-07-18 11:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442520&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 6 Submitted By: Martin v. Löwis (loewis) Assigned to: Tim Peters (tim_one) Summary: test_struct fails on SPARC Initial Comment: With structmodule.c 2.48, test_struct fails on SPARC Solaris with a SIGSEGV. This is caused by the assignment * (LONG_LONG *)p = x; in np_longlong, where p is 0x1ac684, i.e. this is an unaligned access. The Python caller is struct.pack("q", 5) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-18 12:30 Message: Logged In: YES user_id=31435 Good idea! Thank you. I'm going to take a nap now (I obviously need one!). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-18 12:15 Message: Logged In: YES user_id=6380 Why not use memcpy()? E.g. memcpy(p, (char *)&x, sizeof x). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-18 12:11 Message: Logged In: YES user_id=31435 Yuck. I believe it. Boosted priority. We ultimately get *p via the ob_sval member of a PyStringObject, obtained by struct_pack via PyString_FromStringAndSize. The malloc in the latter is only going to guarantee to align the start of ob_sval to what the preceding stringobject members force it to be. I suppose struck_pack has to overallocate string space in this case, and compute an appropriately aligned offset *into* ob_sval at which to begin packing, and then shift the string "left" in memory again after packing. Got a better idea? BTW, I'm sure struct.unpack is going to have an isomorphic problem on this platform. Eww -- that sucks. Possibly better to read/write a byte at a time, and out-think the endianness problem ... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442520&group_id=5470 From noreply@sourceforge.net Wed Jul 18 21:14:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 13:14:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-434143 ] calendar module broken for 1900 Message-ID: Bugs item #434143, was opened at 2001-06-18 04:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434143&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Alexandre Fayolle (afayolle) Assigned to: Skip Montanaro (montanaro) Summary: calendar module broken for 1900 Initial Comment: Hi there, this is a 'feature' I met on both 1.5.2 and 2.1. >>> import calendar >>> calendar.prcal(1865) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/calendar.py", line 160, in prcal print calendar(year, w, l, c), File "/usr/lib/python2.1/calendar.py", line 179, in calendar cal = monthcalendar(year, amonth) File "/usr/lib/python2.1/calendar.py", line 85, in monthcalendar day1, ndays = monthrange(year, month) File "/usr/lib/python2.1/calendar.py", line 78, in monthrange day1 = weekday(year, month, 1) File "/usr/lib/python2.1/calendar.py", line 69, in weekday secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0)) ValueError: year out of range (00-99, 1900-*) (note that the documentation only refers to 1970 as a possible limit, and does not mention how dates in 00-99 range are processed) Now if I try to get the calendar for year 1900 (which is supposed to work according to the message hereabove), I get >>> calendar.prcal(1900) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/calendar.py", line 160, in prcal print calendar(year, w, l, c), File "/usr/lib/python2.1/calendar.py", line 179, in calendar cal = monthcalendar(year, amonth) File "/usr/lib/python2.1/calendar.py", line 85, in monthcalendar day1, ndays = monthrange(year, month) File "/usr/lib/python2.1/calendar.py", line 78, in monthrange day1 = weekday(year, month, 1) File "/usr/lib/python2.1/calendar.py", line 69, in weekday secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0)) OverflowError: mktime argument out of range I guess this is low priority. Cheers Alexandre Fayolle ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2001-07-18 13:14 Message: Logged In: YES user_id=44345 I propose sidestepping this issue by fiddling with the documentation. See the attached file time.diff. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-07-06 11:40 Message: Logged In: YES user_id=44345 calendar.py is a *very* old module. Version 1.1 has a date of 13-Oct-90. The message about the ranges almost certainly comes from the days when Guido and his pals at CWI were developing Python on Macs. I just tried: time.mktime((1900,1,1,0,0,0,0,0,0)) on my iMac and it works. If the year is 1899 it generates the traceback. A year of 1 is currently interpreted as 2001. I'm not sure this is worth fixing, other than to document the limitations better. If you want to display calendars perhaps you should look at Marc-Andre Lemburg's mx.DateTime module, which supports a much wider range of dates. Skip ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434143&group_id=5470 From noreply@sourceforge.net Wed Jul 18 21:48:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 13:48:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-442520 ] test_struct fails on SPARC Message-ID: Bugs item #442520, was opened at 2001-07-18 11:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442520&group_id=5470 Category: Extension Modules >Group: Platform-specific Status: Open >Resolution: Fixed Priority: 6 Submitted By: Martin v. Löwis (loewis) >Assigned to: Martin v. Löwis (loewis) Summary: test_struct fails on SPARC Initial Comment: With structmodule.c 2.48, test_struct fails on SPARC Solaris with a SIGSEGV. This is caused by the assignment * (LONG_LONG *)p = x; in np_longlong, where p is 0x1ac684, i.e. this is an unaligned access. The Python caller is struct.pack("q", 5) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-18 13:48 Message: Logged In: YES user_id=31435 Please give current CVS a try. If it works, just close this bug report, else assign it back to me. Modules/structmodule.c, new revision 2.49. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-18 12:30 Message: Logged In: YES user_id=31435 Good idea! Thank you. I'm going to take a nap now (I obviously need one!). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-18 12:15 Message: Logged In: YES user_id=6380 Why not use memcpy()? E.g. memcpy(p, (char *)&x, sizeof x). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-18 12:11 Message: Logged In: YES user_id=31435 Yuck. I believe it. Boosted priority. We ultimately get *p via the ob_sval member of a PyStringObject, obtained by struct_pack via PyString_FromStringAndSize. The malloc in the latter is only going to guarantee to align the start of ob_sval to what the preceding stringobject members force it to be. I suppose struck_pack has to overallocate string space in this case, and compute an appropriately aligned offset *into* ob_sval at which to begin packing, and then shift the string "left" in memory again after packing. Got a better idea? BTW, I'm sure struct.unpack is going to have an isomorphic problem on this platform. Eww -- that sucks. Possibly better to read/write a byte at a time, and out-think the endianness problem ... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442520&group_id=5470 From noreply@sourceforge.net Thu Jul 19 01:48:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 17:48:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-442627 ] Makefile Fails on "unset" Under OpenBSD Message-ID: Bugs item #442627, was opened at 2001-07-18 17:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442627&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Justin D. Pettit (jpettit) Assigned to: Nobody/Anonymous (nobody) Summary: Makefile Fails on "unset" Under OpenBSD Initial Comment: When I attempt to build Python 2.2a1 under OpenBSD 2.9, it fails with the following message: unset PYTHONPATH PYTHONHOME PYTHONSTARTUP; ./python ./setup.py build *** Error code 1 If I remove unset command, but leave the statement after the semicolon, it builds fine. I've successfully built this release under Linux and Solaris. I noticed that this command was not used in previous releases of Python. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442627&group_id=5470 From noreply@sourceforge.net Thu Jul 19 03:18:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Jul 2001 19:18:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-442647 ] 2.2alpha1: from __future__ import Message-ID: Bugs item #442647, was opened at 2001-07-18 19:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442647&group_id=5470 Category: Parser/Compiler Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Häring (ghaering) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2alpha1: from __future__ import Initial Comment: I noticed that from __future__ import nested_scopes, generators doesn't enable the yield keyword, while the reverse order of importing from __future__ does. I think that the order of imports shouldn't matter. Code showing this behaviour attached. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442647&group_id=5470 From noreply@sourceforge.net Thu Jul 19 08:09:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 00:09:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-434143 ] calendar module broken for 1900 Message-ID: Bugs item #434143, was opened at 2001-06-18 04:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434143&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Alexandre Fayolle (afayolle) Assigned to: Skip Montanaro (montanaro) Summary: calendar module broken for 1900 Initial Comment: Hi there, this is a 'feature' I met on both 1.5.2 and 2.1. >>> import calendar >>> calendar.prcal(1865) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/calendar.py", line 160, in prcal print calendar(year, w, l, c), File "/usr/lib/python2.1/calendar.py", line 179, in calendar cal = monthcalendar(year, amonth) File "/usr/lib/python2.1/calendar.py", line 85, in monthcalendar day1, ndays = monthrange(year, month) File "/usr/lib/python2.1/calendar.py", line 78, in monthrange day1 = weekday(year, month, 1) File "/usr/lib/python2.1/calendar.py", line 69, in weekday secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0)) ValueError: year out of range (00-99, 1900-*) (note that the documentation only refers to 1970 as a possible limit, and does not mention how dates in 00-99 range are processed) Now if I try to get the calendar for year 1900 (which is supposed to work according to the message hereabove), I get >>> calendar.prcal(1900) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/calendar.py", line 160, in prcal print calendar(year, w, l, c), File "/usr/lib/python2.1/calendar.py", line 179, in calendar cal = monthcalendar(year, amonth) File "/usr/lib/python2.1/calendar.py", line 85, in monthcalendar day1, ndays = monthrange(year, month) File "/usr/lib/python2.1/calendar.py", line 78, in monthrange day1 = weekday(year, month, 1) File "/usr/lib/python2.1/calendar.py", line 69, in weekday secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0)) OverflowError: mktime argument out of range I guess this is low priority. Cheers Alexandre Fayolle ---------------------------------------------------------------------- >Comment By: Alexandre Fayolle (afayolle) Date: 2001-07-19 00:09 Message: Logged In: YES user_id=116727 sounds good to me. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-07-18 13:14 Message: Logged In: YES user_id=44345 I propose sidestepping this issue by fiddling with the documentation. See the attached file time.diff. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-07-06 11:40 Message: Logged In: YES user_id=44345 calendar.py is a *very* old module. Version 1.1 has a date of 13-Oct-90. The message about the ranges almost certainly comes from the days when Guido and his pals at CWI were developing Python on Macs. I just tried: time.mktime((1900,1,1,0,0,0,0,0,0)) on my iMac and it works. If the year is 1899 it generates the traceback. A year of 1 is currently interpreted as 2001. I'm not sure this is worth fixing, other than to document the limitations better. If you want to display calendars perhaps you should look at Marc-Andre Lemburg's mx.DateTime module, which supports a much wider range of dates. Skip ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434143&group_id=5470 From noreply@sourceforge.net Thu Jul 19 10:25:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 02:25:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-441580 ] can't import readline in 2.1.1c1 Message-ID: Bugs item #441580, was opened at 2001-07-15 21:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441580&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Neil Schemenauer (nascheme) Summary: can't import readline in 2.1.1c1 Initial Comment: I get the following error for 2.1.1c1 built on SuSE Linux 7.1 , gcc 2.95.2 : >>> import readline Traceback (most recent call last): File "", line 1, in ? ImportError: undefined symbol: BC Needless to say, this makes the interactive session interesting as readline is not imported on startup. Temporary fix for me is to use readline.so from 2.0 - it seems to work fine in 2.1.1c1. Chuck ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-19 02:25 Message: Logged In: YES user_id=34209 I'm sorry, I'm not going to fix this one for 2.1.1... I need some feedback and more than a little testing on other platforms before I'll check in a patch that adds -lncurses to the library list for readline. We can fix it for 2.1.2, if necessary, and 2.2, but someone with setup.py clue needs to look at this... Neil has shown such before, so assigning to him :) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-16 17:27 Message: Logged In: NO Ok, I looked at the Setup file for 2.0 from SuSE. They had readline readline.c -lreadline -lncurses #-ltermcap whereas 2.1.1c1 had readline readline.c -lreadline -ltermcap I made the change, recompiled, and everything is dandy. Chuck ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-16 08:11 Message: Logged In: YES user_id=34209 Did this work in Python 2.1(.0) ? Nothing readline-specific changed in 2.1.1c1... It looks like setup.py is using the wrong libraries to link with. When you enable readline.so in 2.0's Setup file, do you edit the list of include/library paths or libraries linked with ? I don't have a SuSe installation to test with, unfortunately. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441580&group_id=5470 From noreply@sourceforge.net Thu Jul 19 10:35:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 02:35:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-442627 ] Makefile Fails on "unset" Under OpenBSD Message-ID: Bugs item #442627, was opened at 2001-07-18 17:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442627&group_id=5470 Category: Build Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Justin D. Pettit (jpettit) >Assigned to: Thomas Wouters (twouters) >Summary: Makefile Fails on "unset" Under OpenBSD Initial Comment: When I attempt to build Python 2.2a1 under OpenBSD 2.9, it fails with the following message: unset PYTHONPATH PYTHONHOME PYTHONSTARTUP; ./python ./setup.py build *** Error code 1 If I remove unset command, but leave the statement after the semicolon, it builds fine. I've successfully built this release under Linux and Solaris. I noticed that this command was not used in previous releases of Python. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-19 02:35 Message: Logged In: YES user_id=34209 Oh, portability, how I hate thee.... Thanx, fixed in 1.41 and 1.35.2.1 of Makefile.pre.in. This would have been a very embarrasing bug in 2.1.1-final! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442627&group_id=5470 From noreply@sourceforge.net Thu Jul 19 10:53:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 02:53:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-442520 ] test_struct fails on SPARC Message-ID: Bugs item #442520, was opened at 2001-07-18 11:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442520&group_id=5470 Category: Extension Modules Group: Platform-specific >Status: Closed Resolution: Fixed Priority: 6 Submitted By: Martin v. Löwis (loewis) Assigned to: Martin v. Löwis (loewis) Summary: test_struct fails on SPARC Initial Comment: With structmodule.c 2.48, test_struct fails on SPARC Solaris with a SIGSEGV. This is caused by the assignment * (LONG_LONG *)p = x; in np_longlong, where p is 0x1ac684, i.e. this is an unaligned access. The Python caller is struct.pack("q", 5) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-19 02:53 Message: Logged In: YES user_id=21627 The test passes now successfully on Solaris. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-18 13:48 Message: Logged In: YES user_id=31435 Please give current CVS a try. If it works, just close this bug report, else assign it back to me. Modules/structmodule.c, new revision 2.49. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-18 12:30 Message: Logged In: YES user_id=31435 Good idea! Thank you. I'm going to take a nap now (I obviously need one!). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-18 12:15 Message: Logged In: YES user_id=6380 Why not use memcpy()? E.g. memcpy(p, (char *)&x, sizeof x). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-18 12:11 Message: Logged In: YES user_id=31435 Yuck. I believe it. Boosted priority. We ultimately get *p via the ob_sval member of a PyStringObject, obtained by struct_pack via PyString_FromStringAndSize. The malloc in the latter is only going to guarantee to align the start of ob_sval to what the preceding stringobject members force it to be. I suppose struck_pack has to overallocate string space in this case, and compute an appropriately aligned offset *into* ob_sval at which to begin packing, and then shift the string "left" in memory again after packing. Got a better idea? BTW, I'm sure struct.unpack is going to have an isomorphic problem on this platform. Eww -- that sucks. Possibly better to read/write a byte at a time, and out-think the endianness problem ... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442520&group_id=5470 From noreply@sourceforge.net Thu Jul 19 10:54:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 02:54:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-440725 ] setup.py does not properly build bsddb Message-ID: Bugs item #440725, was opened at 2001-07-12 09:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440725&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: setup.py does not properly build bsddb Initial Comment: On my Mandrake system, if the db2-devel RPM is installed it will compile and link bsddb.o and bsddb.so, but importing bsddb fails because the .so wasn't linked with -ldb2, so the dbopen symbol isn't defined. The attached context diff solves the problem for me. Note that it's possible that any or all of libdb3, libdb2, or libdb1 are installed. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-19 02:54 Message: Logged In: YES user_id=34209 I'm wary of submitting this without a release candidate before-hand... Consider it postponed for 2.1-maint, unless we have another release candidate. It's still a good idea for 2.2, IMHO, though. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440725&group_id=5470 From noreply@sourceforge.net Thu Jul 19 10:59:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 02:59:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-438786 ] CVS 2.1.1c1 broken on osf1V4 Message-ID: Bugs item #438786, was opened at 2001-07-05 07:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Nobody/Anonymous (nobody) Summary: CVS 2.1.1c1 broken on osf1V4 Initial Comment: As of right now, the CVS branch for the 2.1 bugfix release cannot import the math module on my Digital Unix platform. ImportError: Unresolved symbol in /tmp_mnt/home/gball/usr/src/python/dist/src/build/lib.osf1-V4.0-alpha-2.1/math.so: __eprintf uname is OSF1 surya V4.0 878 alpha ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-19 02:59 Message: Logged In: YES user_id=34209 Gregory, did you get a chance to test the patch attached to bug #437487, or the 2.1.1 CVS tree ? I'd like to know if this is fixed in 2.1.1. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-16 08:56 Message: Logged In: YES user_id=34209 Ah, yes, that sounds very plausible. The fix for that problem, which was checked in on the trunk, will be in Python 2.1.1-final as well. The Solaris bugreport has a patch attached to it; could you test it to see if it solves your 2.1.1c1 problem ? ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-09 08:48 Message: Logged In: YES user_id=11365 The problem goes away if I clear $CC instead of having it set to gcc. There's a similar problem on Solaris reported recently. I think the configure script should try to spot this sort of thing, but I suppose that's an Autoconf feature request, not a python bug... Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-08 14:06 Message: Logged In: YES user_id=21627 This sounds like a bug in your compiler installation. __eprintf is typically defined in libgcc.a; make sure you use a consistent compiler capable of building binaries for your system throughout the build process. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 From noreply@sourceforge.net Thu Jul 19 11:31:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 03:31:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-442705 ] 2.2a1: Overwriting list.__setslice__ Message-ID: Bugs item #442705, was opened at 2001-07-19 03:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442705&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Jack Jansen (jackjansen) Summary: 2.2a1: Overwriting list.__setslice__ Initial Comment: Overwriting list.__setslice__ in derived classes doesn't seem to work in 2.2a1: ---- class C(list): def __setslice__(*args): list.__setslice__(*args) c = list((1,2,3,4)) c[1:3] = [5, 6] print c c = C((1,2,3,4)) c[1:3] = [5, 6] print c ---- Output: [1, 5, 6, 4] Traceback (most recent call last): File "test.py", line 10, in ? c[1:3] = [5, 6] TypeError: function takes exactly 2 arguments (3 given) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442705&group_id=5470 From noreply@sourceforge.net Thu Jul 19 11:31:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 03:31:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-442705 ] 2.2a1: Overwriting list.__setslice__ Message-ID: Bugs item #442705, was opened at 2001-07-19 03:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442705&group_id=5470 >Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Jack Jansen (jackjansen) Summary: 2.2a1: Overwriting list.__setslice__ Initial Comment: Overwriting list.__setslice__ in derived classes doesn't seem to work in 2.2a1: ---- class C(list): def __setslice__(*args): list.__setslice__(*args) c = list((1,2,3,4)) c[1:3] = [5, 6] print c c = C((1,2,3,4)) c[1:3] = [5, 6] print c ---- Output: [1, 5, 6, 4] Traceback (most recent call last): File "test.py", line 10, in ? c[1:3] = [5, 6] TypeError: function takes exactly 2 arguments (3 given) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442705&group_id=5470 From noreply@sourceforge.net Thu Jul 19 11:41:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 03:41:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-442705 ] 2.2a1: Overwriting list.__setslice__ Message-ID: Bugs item #442705, was opened at 2001-07-19 03:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442705&group_id=5470 >Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Jack Jansen (jackjansen) Summary: 2.2a1: Overwriting list.__setslice__ Initial Comment: Overwriting list.__setslice__ in derived classes doesn't seem to work in 2.2a1: ---- class C(list): def __setslice__(*args): list.__setslice__(*args) c = list((1,2,3,4)) c[1:3] = [5, 6] print c c = C((1,2,3,4)) c[1:3] = [5, 6] print c ---- Output: [1, 5, 6, 4] Traceback (most recent call last): File "test.py", line 10, in ? c[1:3] = [5, 6] TypeError: function takes exactly 2 arguments (3 given) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442705&group_id=5470 From noreply@sourceforge.net Thu Jul 19 11:41:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 03:41:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-442705 ] 2.2a1: Overwriting list.__setslice__ Message-ID: Bugs item #442705, was opened at 2001-07-19 03:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442705&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Guido van Rossum (gvanrossum) Summary: 2.2a1: Overwriting list.__setslice__ Initial Comment: Overwriting list.__setslice__ in derived classes doesn't seem to work in 2.2a1: ---- class C(list): def __setslice__(*args): list.__setslice__(*args) c = list((1,2,3,4)) c[1:3] = [5, 6] print c c = C((1,2,3,4)) c[1:3] = [5, 6] print c ---- Output: [1, 5, 6, 4] Traceback (most recent call last): File "test.py", line 10, in ? c[1:3] = [5, 6] TypeError: function takes exactly 2 arguments (3 given) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442705&group_id=5470 From noreply@sourceforge.net Thu Jul 19 12:05:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 04:05:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-442712 ] os.path.expanduser problem w/o HOME set Message-ID: Bugs item #442712, was opened at 2001-07-19 04:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442712&group_id=5470 Category: Windows Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: os.path.expanduser problem w/o HOME set Initial Comment: If I do a os.path.expanduser("~") I get '\Documents and Settings\kwg' - the C: drive is not mentioned. I traced this to the call to join (and onwards to the isabs call in the code for the join function. Simple remedy is to use userhome = drive + os.environ['HOMEPATH'] instead of userhome = join(drive, os.environ['HOMEPATH'] My sys.version value is '2.1 (#15, Apr 16 2001, 18:24:49) [MSC 32 bit (Intel]' ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442712&group_id=5470 From noreply@sourceforge.net Thu Jul 19 13:21:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 05:21:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-442647 ] 2.2alpha1: from __future__ import Message-ID: Bugs item #442647, was opened at 2001-07-18 19:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442647&group_id=5470 Category: Parser/Compiler Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Häring (ghaering) >Assigned to: Greg Ward (gward) Summary: 2.2alpha1: from __future__ import Initial Comment: I noticed that from __future__ import nested_scopes, generators doesn't enable the yield keyword, while the reverse order of importing from __future__ does. I think that the order of imports shouldn't matter. Code showing this behaviour attached. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 05:21 Message: Logged In: YES user_id=6380 You're right. I'll see if I can fix this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442647&group_id=5470 From noreply@sourceforge.net Thu Jul 19 13:29:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 05:29:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-442724 ] Setting PYTHONHOME= breaks setup.py Message-ID: Bugs item #442724, was opened at 2001-07-19 05:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442724&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Thomas Wouters (twouters) Summary: Setting PYTHONHOME= breaks setup.py Initial Comment: On UnixWare, the Makefile now invokes PYTHONPATH= PYTHONHOME= PYTHONSTARTUP= ./python setup.py build This gives the error 'import site' failed; use -v for traceback Traceback (most recent call last): File "setup.py", line 6, in ? import sys, os, getopt ImportError: No module named os The problem is that it only looks in . and lib/python2.2/*, not in Lib. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442724&group_id=5470 From noreply@sourceforge.net Thu Jul 19 13:43:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 05:43:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-442705 ] 2.2a1: Overriding __setslice__ Message-ID: Bugs item #442705, was opened at 2001-07-19 03:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442705&group_id=5470 >Category: type/class unification >Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) >Summary: 2.2a1: Overriding __setslice__ Initial Comment: Overwriting list.__setslice__ in derived classes doesn't seem to work in 2.2a1: ---- class C(list): def __setslice__(*args): list.__setslice__(*args) c = list((1,2,3,4)) c[1:3] = [5, 6] print c c = C((1,2,3,4)) c[1:3] = [5, 6] print c ---- Output: [1, 5, 6, 4] Traceback (most recent call last): File "test.py", line 10, in ? c[1:3] = [5, 6] TypeError: function takes exactly 2 arguments (3 given) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 05:43 Message: Logged In: YES user_id=6380 You're right! To fix: in file typeobject.c, function slot_sq_ass_slice(), change "__setitem__" to "__setslice__". Then all will be fine. Fixed in CVS, typeobject.c:2.16.8.68. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442705&group_id=5470 From noreply@sourceforge.net Thu Jul 19 13:45:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 05:45:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-442712 ] os.path.expanduser problem w/o HOME set Message-ID: Bugs item #442712, was opened at 2001-07-19 04:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442712&group_id=5470 Category: Windows Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: os.path.expanduser problem w/o HOME set Initial Comment: If I do a os.path.expanduser("~") I get '\Documents and Settings\kwg' - the C: drive is not mentioned. I traced this to the call to join (and onwards to the isabs call in the code for the join function. Simple remedy is to use userhome = drive + os.environ['HOMEPATH'] instead of userhome = join(drive, os.environ['HOMEPATH'] My sys.version value is '2.1 (#15, Apr 16 2001, 18:24:49) [MSC 32 bit (Intel]' ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 05:45 Message: Logged In: YES user_id=6380 Hm, but why doesn't the join() work? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442712&group_id=5470 From noreply@sourceforge.net Thu Jul 19 13:53:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 05:53:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-417491 ] UnixWare BUILD *STILL* uses ld -G Message-ID: Bugs item #417491, was opened at 2001-04-19 16:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417491&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Larry Rosenman (ler) Assigned to: Martin v. Löwis (loewis) Summary: UnixWare BUILD *STILL* uses ld -G Initial Comment: bug 231439 is BACK in the 2.1 final release. It still uses ld -G. ALL shared objects, ESPECIALLY those using threads, should be compiled *AND* linked using cc -G. I'm very disappointed in that the bug was closed but the QA process dropped the fix(es). ALSO, when doing the initial build using Shared Objects, you need to set -R and/or set LD_LIBRARY_PATH to suit. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-19 05:53 Message: Logged In: YES user_id=21627 Fixed in configure.in 1.230. libpython is now build as a static library again, until a patch is implemented that builds libpython.so in a portable way as a configuration option. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-12 16:01 Message: Logged In: YES user_id=3066 Assigning to Martin since I'm about to approve his patch, and he'll need to close this one. Regarding the QA issue: we have no way to test on most of the platforms we support, so it's pretty hard to know which changes break where. We appreciate the effort to which you've gone to let us know what needs to be fixed to support your platform. ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-04-21 19:55 Message: Logged In: YES user_id=36452 Oh, and I'm VERY willing to test RC's. I didn't realize it was close to release..... ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-04-21 19:35 Message: Logged In: YES user_id=36452 Ok. Sorry for the screaming, but the CVS sources are STILL broken. Can someone look at the patch I generated, and see if it can be integrated into current CVS? I've built 2.1 with it on UnixWare 7 7.1.1 with the UDK FS 7.1.1b compiler. It works. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-04-21 19:30 Message: Logged In: YES user_id=31435 LARRY, there's REALLY no need to SCREAM on *EACH* word in THREE . You're not impressed by QA -- join the club. Testing is done by volunteers, and if there are no volunteers *trying* the release candidates on a new platform, we have no way to know whether they work. Linux and Windows and Mac Classic are pretty well covered by volunteers, but that's about it. If UnixWare is important enough to you, volunteer to test release candidates there yourself, or even pay someone to do it. But don't go honking on Martin! That's out of line. About your "The last comments on this patch are telling.", the last comments on that patch were made *after* the release. Before the release, Guido checked in the patch that the UnixWare user said was needed. He can't guess whether a patch actually works on a platform he doesn't use. The last patch comment by a UnixWare user *before* the release reads """Every thing looks fine (as far as I can tell).""" WRT "why the H*LL didn't the release .tar get RE-ROLLED?", it's because nobody said anything was broken until after the release shipped (your bug report here was 2 days after the release). ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-04-21 17:34 Message: Logged In: YES user_id=36452 OK, here is a patch I wrote to configure.in to fix this. regen configure and config.h.in Let me know if this is acceptable. THis is against the 2.1-RELEASE version. Larry ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-04-21 15:45 Message: Logged In: YES user_id=36452 Oh, and 1.215 is *BROKE*, as it spec's ld -G, not CC -G, around line 615 or so. PLEASE fix. PLEASE generate a FIX RELEASE for the 2.1 RELEASE. This is *NOT* a good sign that a broken PORT didn't stop the release process. ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-04-21 15:23 Message: Logged In: YES user_id=36452 OK, why the H*LL didn't the release .tar get RE-ROLLED? The last comments on this patch are telling. I'm *NOT* impressed, and the bug reported here is mentioned in that stream, so why wasn't the RELEASE held for this? the port is PROMINENTLY mentioned in the release notes, but it's BROKE in the RELEASE. How can I get a new tarball from y'all? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-21 05:55 Message: Logged In: YES user_id=21627 I agree this is very unfortunate. Please have a look at patch 413011, which was committed as 1.215 of configure.in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417491&group_id=5470 From noreply@sourceforge.net Thu Jul 19 13:54:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 05:54:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-417491 ] UnixWare BUILD *STILL* uses ld -G Message-ID: Bugs item #417491, was opened at 2001-04-19 16:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417491&group_id=5470 Category: Build Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Larry Rosenman (ler) Assigned to: Martin v. Löwis (loewis) Summary: UnixWare BUILD *STILL* uses ld -G Initial Comment: bug 231439 is BACK in the 2.1 final release. It still uses ld -G. ALL shared objects, ESPECIALLY those using threads, should be compiled *AND* linked using cc -G. I'm very disappointed in that the bug was closed but the QA process dropped the fix(es). ALSO, when doing the initial build using Shared Objects, you need to set -R and/or set LD_LIBRARY_PATH to suit. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-19 05:53 Message: Logged In: YES user_id=21627 Fixed in configure.in 1.230. libpython is now build as a static library again, until a patch is implemented that builds libpython.so in a portable way as a configuration option. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-12 16:01 Message: Logged In: YES user_id=3066 Assigning to Martin since I'm about to approve his patch, and he'll need to close this one. Regarding the QA issue: we have no way to test on most of the platforms we support, so it's pretty hard to know which changes break where. We appreciate the effort to which you've gone to let us know what needs to be fixed to support your platform. ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-04-21 19:55 Message: Logged In: YES user_id=36452 Oh, and I'm VERY willing to test RC's. I didn't realize it was close to release..... ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-04-21 19:35 Message: Logged In: YES user_id=36452 Ok. Sorry for the screaming, but the CVS sources are STILL broken. Can someone look at the patch I generated, and see if it can be integrated into current CVS? I've built 2.1 with it on UnixWare 7 7.1.1 with the UDK FS 7.1.1b compiler. It works. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-04-21 19:30 Message: Logged In: YES user_id=31435 LARRY, there's REALLY no need to SCREAM on *EACH* word in THREE . You're not impressed by QA -- join the club. Testing is done by volunteers, and if there are no volunteers *trying* the release candidates on a new platform, we have no way to know whether they work. Linux and Windows and Mac Classic are pretty well covered by volunteers, but that's about it. If UnixWare is important enough to you, volunteer to test release candidates there yourself, or even pay someone to do it. But don't go honking on Martin! That's out of line. About your "The last comments on this patch are telling.", the last comments on that patch were made *after* the release. Before the release, Guido checked in the patch that the UnixWare user said was needed. He can't guess whether a patch actually works on a platform he doesn't use. The last patch comment by a UnixWare user *before* the release reads """Every thing looks fine (as far as I can tell).""" WRT "why the H*LL didn't the release .tar get RE-ROLLED?", it's because nobody said anything was broken until after the release shipped (your bug report here was 2 days after the release). ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-04-21 17:34 Message: Logged In: YES user_id=36452 OK, here is a patch I wrote to configure.in to fix this. regen configure and config.h.in Let me know if this is acceptable. THis is against the 2.1-RELEASE version. Larry ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-04-21 15:45 Message: Logged In: YES user_id=36452 Oh, and 1.215 is *BROKE*, as it spec's ld -G, not CC -G, around line 615 or so. PLEASE fix. PLEASE generate a FIX RELEASE for the 2.1 RELEASE. This is *NOT* a good sign that a broken PORT didn't stop the release process. ---------------------------------------------------------------------- Comment By: Larry Rosenman (ler) Date: 2001-04-21 15:23 Message: Logged In: YES user_id=36452 OK, why the H*LL didn't the release .tar get RE-ROLLED? The last comments on this patch are telling. I'm *NOT* impressed, and the bug reported here is mentioned in that stream, so why wasn't the RELEASE held for this? the port is PROMINENTLY mentioned in the release notes, but it's BROKE in the RELEASE. How can I get a new tarball from y'all? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-21 05:55 Message: Logged In: YES user_id=21627 I agree this is very unfortunate. Please have a look at patch 413011, which was committed as 1.215 of configure.in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417491&group_id=5470 From noreply@sourceforge.net Thu Jul 19 13:57:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 05:57:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-442734 ] 2.2a1: New style classes and pydoc Message-ID: Bugs item #442734, was opened at 2001-07-19 05:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442734&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2a1: New style classes and pydoc Initial Comment: pydoc (and the new builtin function help) don't find new style classes in modules: File test.py: ---- class foo: pass class bar(object): pass ---- Interactive session: >>> import test >>> help(test) Help on module test: NAME test FILE /data/home/walter/test.py CLASSES foo class foo DATA __file__ = 'test.py' __name__ = 'test' ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442734&group_id=5470 From noreply@sourceforge.net Thu Jul 19 14:06:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 06:06:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-442734 ] 2.2a1: New style classes and pydoc Message-ID: Bugs item #442734, was opened at 2001-07-19 05:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442734&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Guido van Rossum (gvanrossum) Summary: 2.2a1: New style classes and pydoc Initial Comment: pydoc (and the new builtin function help) don't find new style classes in modules: File test.py: ---- class foo: pass class bar(object): pass ---- Interactive session: >>> import test >>> help(test) Help on module test: NAME test FILE /data/home/walter/test.py CLASSES foo class foo DATA __file__ = 'test.py' __name__ = 'test' ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 06:06 Message: Logged In: YES user_id=6380 Yup, inspect needs to be taught a lesson. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442734&group_id=5470 From noreply@sourceforge.net Thu Jul 19 14:11:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 06:11:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-442712 ] os.path.expanduser problem w/o HOME set Message-ID: Bugs item #442712, was opened at 2001-07-19 04:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442712&group_id=5470 Category: Windows Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: os.path.expanduser problem w/o HOME set Initial Comment: If I do a os.path.expanduser("~") I get '\Documents and Settings\kwg' - the C: drive is not mentioned. I traced this to the call to join (and onwards to the isabs call in the code for the join function. Simple remedy is to use userhome = drive + os.environ['HOMEPATH'] instead of userhome = join(drive, os.environ['HOMEPATH'] My sys.version value is '2.1 (#15, Apr 16 2001, 18:24:49) [MSC 32 bit (Intel]' ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-19 06:11 Message: Logged In: NO I think the reason why join doesn't work is to do with isabs returning true when "\foo" is entered as a parameter under NT - surely the name of the drive must be included if the parameter doesn't look like a UNC filename? Inother words, on NT \foo should fail //ferrari\foo should not fail c:\foo should not fail I've also noticed that os.path.isabs("\foo") returns 0, os.path.isabs("/foo") returns 1 on Windows 2000. Surely this should be the other way round? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 05:45 Message: Logged In: YES user_id=6380 Hm, but why doesn't the join() work? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442712&group_id=5470 From noreply@sourceforge.net Thu Jul 19 14:15:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 06:15:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-442724 ] Setting PYTHONHOME= breaks setup.py Message-ID: Bugs item #442724, was opened at 2001-07-19 05:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442724&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Neil Schemenauer (nascheme) Summary: Setting PYTHONHOME= breaks setup.py Initial Comment: On UnixWare, the Makefile now invokes PYTHONPATH= PYTHONHOME= PYTHONSTARTUP= ./python setup.py build This gives the error 'import site' failed; use -v for traceback Traceback (most recent call last): File "setup.py", line 6, in ? import sys, os, getopt ImportError: No module named os The problem is that it only looks in . and lib/python2.2/*, not in Lib. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-19 06:15 Message: Logged In: YES user_id=34209 Unsetting PYTHONHOME was not my idea :) But I do agree that doing this in 2.1.1 is not a good idea. Reverting the patch there, and reassigning the bug to Neil, whose idea it seems to have been. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442724&group_id=5470 From noreply@sourceforge.net Thu Jul 19 15:08:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 07:08:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-442712 ] os.path.expanduser problem w/o HOME set Message-ID: Bugs item #442712, was opened at 2001-07-19 04:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442712&group_id=5470 Category: Windows Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: os.path.expanduser problem w/o HOME set Initial Comment: If I do a os.path.expanduser("~") I get '\Documents and Settings\kwg' - the C: drive is not mentioned. I traced this to the call to join (and onwards to the isabs call in the code for the join function. Simple remedy is to use userhome = drive + os.environ['HOMEPATH'] instead of userhome = join(drive, os.environ['HOMEPATH'] My sys.version value is '2.1 (#15, Apr 16 2001, 18:24:49) [MSC 32 bit (Intel]' ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 07:08 Message: Logged In: YES user_id=6380 Well, I think join should be made smarter! os.path.isabs("\foo") returns 0 because \f is interpreted by the interpreter as '\x0c'. Try "\foo" or r"\foo" instead. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-19 06:11 Message: Logged In: NO I think the reason why join doesn't work is to do with isabs returning true when "\foo" is entered as a parameter under NT - surely the name of the drive must be included if the parameter doesn't look like a UNC filename? Inother words, on NT \foo should fail //ferrari\foo should not fail c:\foo should not fail I've also noticed that os.path.isabs("\foo") returns 0, os.path.isabs("/foo") returns 1 on Windows 2000. Surely this should be the other way round? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 05:45 Message: Logged In: YES user_id=6380 Hm, but why doesn't the join() work? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442712&group_id=5470 From noreply@sourceforge.net Thu Jul 19 15:22:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 07:22:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-233084 ] nis.match('username', 'aliases') does not work under Linux Message-ID: Bugs item #233084, was opened at 2001-02-19 07:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=233084&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: nis.match('username', 'aliases') does not work under Linux Initial Comment: The exception 'nis.error: No such key in map' is thrown when issuing >>> nis.match('username', 'aliases') under SuSE-Linux 6.4 and 7.0 with both Python 2.0 and Python 2.1a2, even if 'username' is valid and $ ypmatch username aliases works. Fix: Apply the following patch to Modules/nismodule.c --- nismodule.c.sv Mon Feb 19 16:12:10 2001 +++ nismodule.c Mon Feb 19 16:15:28 2001 @@ -43,7 +43,7 @@ {"hosts", "hosts.byname", 0}, {"protocols", "protocols.bynumber", 0}, {"services", "services.byname", 0}, - {"aliases", "mail.aliases", 1}, /* created with 'makedbm -a' */ + {"aliases", "mail.aliases", 0}, /* created with 'makedbm -a' */ {"ethers", "ethers.byname", 0}, {0L, 0L, 0} }; ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-19 07:22 Message: Logged In: YES user_id=3066 After soliciting information from python-dev, it appears that there's no clear fix -- fixing this properly may not be possible, as it has a lot to do with the server configuration. See the "NIS on Linux, others?" thread that starts at: http://mail.python.org/pipermail/python-dev/2001-June/015633.html Closing this as "Won't Fix". If there is a portable and reliable way to fix this, please submit a patch. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-29 05:39 Message: Logged In: NO The fix (or the Python 1.5.2 behavior) is correct for such platforms as RedHat Linux 6.2 (NIS server BSDI 2.1) and an unknown FreeBSD version. The need for the "fix" flag is likely dependent on the server, not the client, and may very well need to be guessed at runtime. A related bug causes a segmentation violation in memcpy() for 'nis.cat("aliases")' when a zero-length key or value appears in the map, because (unsigned)-1 is passed as the length argument. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-02-23 11:52 Message: You are all going down on this one ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-02-19 13:33 Message: Can anyone confirm this bug for other platforms? How about the fix? I don't have any access a network that uses NIS these days. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=233084&group_id=5470 From noreply@sourceforge.net Thu Jul 19 15:24:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 07:24:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-213797 ] Build problems on Reliant Unix Message-ID: Bugs item #213797, was opened at 2000-09-07 07:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=213797&group_id=5470 Category: Build Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Daniel Dittmar (ddittmar) Assigned to: Martin v. Löwis (loewis) Summary: Build problems on Reliant Unix Initial Comment: - the linker requires the options '-W1 -Blargedynsym', otherwise, Python's global functions and variables are not visible to external modules - when building --with-threads, the linker requires the option -Kpthread - mmapmodule.o requires a special library Python version: 2.0b1 compiler version:CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000 CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-19 07:24 Message: Logged In: YES user_id=21627 With the fix in configure.in 1.231, a -Kpthread binary can be build on ReliantUnix 5.45 B0032, on RM600 4/512. Unfortunately, when trying to build the extension modules, the resulting Python crashes with internal error in pthread_mutex_unlock I have not investigated this further; if the cause of the problem or a patch is known, please submit an additional bug report. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-12 16:04 Message: Logged In: YES user_id=3066 Marin, you should be able to close this when you check in your UnixWare/ReliantUNIX patch. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-10-12 09:28 Message: I'm recording here part of the needed patch for threads; this is needed in configure.in to get the -Kpthread option passed to the compiler and linker in all the appropriate places. There are still problems in the code. (It won't look right in a browser, but it provides all the needed information.) *************** *** 752,757 **** --- 752,761 ---- if test ! -z "$withval" -a -d "$withval" then LDFLAGS="$LDFLAGS -L$withval" fi + case "$ac_sys_system" in + ReliantUNIX*) LDFLAGS="$LDFLAGS -Kpthread"; + OPT="$OPT -Kpthread";; + esac AC_DEFINE(_REENTRANT) AC_CHECK_HEADER(mach/cthreads.h, [AC_DEFINE(WITH_THREAD) AC_DEFINE(C_THREADS) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-10-05 19:00 Message: This won't be resolved for Python 2.0. There's enough that would be effected by revising the thread identification code that we don't want to destabilize the sources at this point. We should be able to resolve this for Python 2.1. I've added a comment about this to the platform notes section of the README file (revision 1.102) to alert the reader to this situation. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-10-03 09:22 Message: I've sent a note to Daniel asking for the config.h and config.log files generated by configure. There's a real problem with the way we're creating thread identifiers; casting to a long just isn't sufficient. It might be good to know what kind of processor is on the machine. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-10-03 09:16 Message: Daniel Dittmar's response: - the configure script works, except that the correct option is '-Kpthread' (you mistyped '-Lpthread' - there's a compilation error in thread_pthread.h:181: the expression '(long) threadid' is not valid. The definition of pthread_t is typedef struct PTHREAD_HANDLE_T { void *field1; short int field2; short int field3; } pthread_handle_t; typedef pthread_handle_t pthread_t; so I doubt that the alternative return (long) *(long *) &threadid is valid. I could compile it with this version, but I doubt it's returning a meaningful thread id. Is there a test for the thread module? I'm away for the rest of the week, so I couldn't test anything for the Wednesday date. - for your information, I'm including the results of 'make test', at least the failed ones: test test_fork1 crashed -- exceptions.OSError: [Errno 4] Interrupted system call test test_popen2 crashed -- exceptions.IOError: [Errno 4] Interrupted system call test_signal Trace/Breakpoint Trap - core dumped make: *** Error code 133 (ignored) make: *** Error code 133 (bu21) (ignored) These test leave a few python processes around. I'll probably look into this when I return. Daniel ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-10-02 08:30 Message: Sent another version of the configure script to Daniel Dittmar for testing the thread support. I think this is the last remaining problem listed in this bug report. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-10-01 10:51 Message: mmap patch checked in as Modules/mmapmodule.c revision 2.24. ---------------------------------------------------------------------- Comment By: Daniel Dittmar (ddittmar) Date: 2000-10-01 09:34 Message: The patch for the mmap module works on 2.0b2 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-09-28 10:36 Message: I've sent a patch for the mmap module to Daniel to test on Reliant UNIX; the patch should remove the need to link to libucb on that platform (the only platform that needed that as far as we know). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-09-25 08:10 Message: Fix to make sure the public API properly exposed to extensions checked in as configure.in revision 1.155. The rest of these issues can be dealt with in 2.0 final. ---------------------------------------------------------------------- Comment By: Daniel Dittmar (ddittmar) Date: 2000-09-24 05:46 Message: - configure --without-threads works with the configure patch Revision 1.158 - mmapmodule would work if it includes the lines #include static int getpagesize (void) { return sysconf (_SC_PAGESIZE); } This would be the preferred way as using the BSD compatibility with -lucb is discouraged. It requires chages to configure (has_pagesize, has_sysconf_sc_pagesize) - configure --with-threads doesn't build yet, keeping contact with fdrake ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-09-21 08:46 Message: Received message from Daniel indicating he should get a chace to test the changes this weekend, so it should be available for 2.0b2. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-09-21 08:17 Message: Sent query to Daniel Dittmar asking if he's had a chance to test the revised configure script I sent. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-09-15 13:37 Message: I'm sending a modified version of the configure script to Daniel Dittmar to test for the first two points in this bug report. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-09-15 11:57 Message: For the mmap issue, I've added a comment to Modules/Setup.in to let installers know that -lucb may be needed. In revision 1.110. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-09-12 21:59 Message: Received the following response from Daniel Dittmar : > We need to know the output of "uname -s" and "uname -r" > for this system. (If "uname -r" reports an error, please > try "uname -v".) uname -s ReliantUNIX-N uname -r 5.45 > Are you willing to test a modified configure script on > this platform? sure. > What additional library is required for the mmap module? The man page states -lucb. This didn't work on my machine as the BSD compatibility layer is not active. I tell you more as soon as I know how to activate it. *********** Another problem: to detect pthreads, the compiler must be called with -Kpthread. Otherwise, pthread.h goes into a branch where it tries to include a non existent header, fails, and configure reports 'no pthreads'. Daniel ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-09-08 13:45 Message: We need to know the output of "uname -s" and "uname -r" for this system. (If "uname -r" reports an error, please try "uname -v".) Are you willing to test a modified configure script on this platform? What additional library is required for the mmap module? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2000-09-07 15:05 Message: Please do triage on this bug. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=213797&group_id=5470 From noreply@sourceforge.net Thu Jul 19 15:27:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 07:27:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-442724 ] Setting PYTHONHOME= breaks setup.py Message-ID: Bugs item #442724, was opened at 2001-07-19 05:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442724&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Thomas Wouters (twouters) Summary: Setting PYTHONHOME= breaks setup.py Initial Comment: On UnixWare, the Makefile now invokes PYTHONPATH= PYTHONHOME= PYTHONSTARTUP= ./python setup.py build This gives the error 'import site' failed; use -v for traceback Traceback (most recent call last): File "setup.py", line 6, in ? import sys, os, getopt ImportError: No module named os The problem is that it only looks in . and lib/python2.2/*, not in Lib. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-07-19 07:27 Message: Logged In: YES user_id=35752 I still think unsetting PYTHONHOME is the right thing to do. Setting PYTHONHOME to "" is a bad idea. "PYTHONHOME=" and "unset PYTHONHOME" are not equivalent. The line in the makefile should be: unset PYTHONPATH PYTHONHOME PYTHONSTARTUP; ./$(PYTHON) $(srcdir)/setup.py build ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-19 06:15 Message: Logged In: YES user_id=34209 Unsetting PYTHONHOME was not my idea :) But I do agree that doing this in 2.1.1 is not a good idea. Reverting the patch there, and reassigning the bug to Neil, whose idea it seems to have been. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442724&group_id=5470 From noreply@sourceforge.net Thu Jul 19 15:28:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 07:28:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-230075 ] dbmmodule build fails on Debian GNU/Linux unstable (Sid) Message-ID: Bugs item #230075, was opened at 2001-01-25 12:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=230075&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: Wont Fix Priority: 5 Submitted By: Kalle Svensson (krftkndl) Assigned to: Thomas Wouters (twouters) Summary: dbmmodule build fails on Debian GNU/Linux unstable (Sid) Initial Comment: When building on Debian GNU/Linux unstable, the build fails with: /home/kalle/src/python/dist/src/Modules/dbmmodule.c:24: #error "No ndbm.h available!" error: command 'gcc' failed with exit status 1 make: *** [sharedmods] Error 1 The *dbm.h files available are /usr/include/dbm.h /usr/include/gdbm.h /usr/include/gdbm-ndbm.h All are part of the package libgdbmg1-dev. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-07-19 07:28 Message: Logged In: YES user_id=35752 Have you fixed this one in 2.1.1 Thomas? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-07-19 07:28 Message: Logged In: YES user_id=35752 Have you fixed this one in 2.1.1 Thomas? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-03-17 08:36 Message: Logged In: YES user_id=11375 What does the patch look like? You can probably go ahead and check it in. I'd be leery of removing the 'not in "cygwin"' check; ask Jason Tishler if it's still needed, since he's the Cygwin guru. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-03-03 22:26 Message: Logged In: YES user_id=35752 db1/ndbm.h from libc6_2.2.2-1 still includes db.h instead of db1/db.h. I think I understand the reason now. If you want to use db1 or gdbm as a dbm compatible database you have to link with the approprate library. Therefore, if you should add both -ldb1 and -Idb1. I've created a patch to setup.py which does this. Andrew? BTW, I'm not sure if the "if platform not in ['cygwin']" is needed anymore. I bet it could be removed. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-03-03 21:50 Message: Logged In: YES user_id=35752 Python is looking for gdbm/ndbm.h. I could add more logic to look for gdbm-ndbm.h but I don't think its worth it. libc6 includes db1 which can be used by dbmmodule. configure is not finding db1/ndbm.h because ndbm.h includes db.h. I think it should include db1/db.h instead. So, it looks like a Debian unstable bug. I'm downloading Debian libc6_2.2.2-1 right now. Perhaps the bug has been fixed. ---------------------------------------------------------------------- Comment By: Kalle Svensson (krftkndl) Date: 2001-01-25 12:21 Message: Forgot to say that it's Python out of CVS, updated Thu Jan 25 21:23:52 CET 2001. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=230075&group_id=5470 From noreply@sourceforge.net Thu Jul 19 15:28:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 07:28:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-230075 ] dbmmodule build fails on Debian GNU/Linux unstable (Sid) Message-ID: Bugs item #230075, was opened at 2001-01-25 12:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=230075&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: Wont Fix Priority: 5 Submitted By: Kalle Svensson (krftkndl) >Assigned to: Thomas Wouters (twouters) Summary: dbmmodule build fails on Debian GNU/Linux unstable (Sid) Initial Comment: When building on Debian GNU/Linux unstable, the build fails with: /home/kalle/src/python/dist/src/Modules/dbmmodule.c:24: #error "No ndbm.h available!" error: command 'gcc' failed with exit status 1 make: *** [sharedmods] Error 1 The *dbm.h files available are /usr/include/dbm.h /usr/include/gdbm.h /usr/include/gdbm-ndbm.h All are part of the package libgdbmg1-dev. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-07-19 07:28 Message: Logged In: YES user_id=35752 Have you fixed this one in 2.1.1 Thomas? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-03-17 08:36 Message: Logged In: YES user_id=11375 What does the patch look like? You can probably go ahead and check it in. I'd be leery of removing the 'not in "cygwin"' check; ask Jason Tishler if it's still needed, since he's the Cygwin guru. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-03-03 22:26 Message: Logged In: YES user_id=35752 db1/ndbm.h from libc6_2.2.2-1 still includes db.h instead of db1/db.h. I think I understand the reason now. If you want to use db1 or gdbm as a dbm compatible database you have to link with the approprate library. Therefore, if you should add both -ldb1 and -Idb1. I've created a patch to setup.py which does this. Andrew? BTW, I'm not sure if the "if platform not in ['cygwin']" is needed anymore. I bet it could be removed. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-03-03 21:50 Message: Logged In: YES user_id=35752 Python is looking for gdbm/ndbm.h. I could add more logic to look for gdbm-ndbm.h but I don't think its worth it. libc6 includes db1 which can be used by dbmmodule. configure is not finding db1/ndbm.h because ndbm.h includes db.h. I think it should include db1/db.h instead. So, it looks like a Debian unstable bug. I'm downloading Debian libc6_2.2.2-1 right now. Perhaps the bug has been fixed. ---------------------------------------------------------------------- Comment By: Kalle Svensson (krftkndl) Date: 2001-01-25 12:21 Message: Forgot to say that it's Python out of CVS, updated Thu Jan 25 21:23:52 CET 2001. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=230075&group_id=5470 From noreply@sourceforge.net Thu Jul 19 15:29:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 07:29:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-442758 ] 2.2a1: New style classes and __cmp__ Message-ID: Bugs item #442758, was opened at 2001-07-19 07:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442758&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2a1: New style classes and __cmp__ Initial Comment: Implementing __cmp__ in a new style class doesn't seem to have an effect: ---- class Foo: def __cmp__(self, other): print "foo", other return 0 class Bar(object): def __cmp__(self, other): print "bar", other return 0 Foo() == 42 Bar() == 42 ---- This only prints: foo 42 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442758&group_id=5470 From noreply@sourceforge.net Thu Jul 19 15:33:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 07:33:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-441580 ] can't import readline in 2.1.1c1 Message-ID: Bugs item #441580, was opened at 2001-07-15 21:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441580&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: A.M. Kuchling (akuchling) Summary: can't import readline in 2.1.1c1 Initial Comment: I get the following error for 2.1.1c1 built on SuSE Linux 7.1 , gcc 2.95.2 : >>> import readline Traceback (most recent call last): File "", line 1, in ? ImportError: undefined symbol: BC Needless to say, this makes the interactive session interesting as readline is not imported on startup. Temporary fix for me is to use readline.so from 2.0 - it seems to work fine in 2.1.1c1. Chuck ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-07-19 07:33 Message: Logged In: YES user_id=35752 I believe that linking with ncurses is the right thing to do if ncurses is available. However, there are probably systems out there that don't have ncurses but have termcap. setup.py could decide what to link readline with based on the HAVE_NCURSES_H define. Andrew is better at wrangling setup.py so I'm assigning to him. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-19 02:25 Message: Logged In: YES user_id=34209 I'm sorry, I'm not going to fix this one for 2.1.1... I need some feedback and more than a little testing on other platforms before I'll check in a patch that adds -lncurses to the library list for readline. We can fix it for 2.1.2, if necessary, and 2.2, but someone with setup.py clue needs to look at this... Neil has shown such before, so assigning to him :) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-16 17:27 Message: Logged In: NO Ok, I looked at the Setup file for 2.0 from SuSE. They had readline readline.c -lreadline -lncurses #-ltermcap whereas 2.1.1c1 had readline readline.c -lreadline -ltermcap I made the change, recompiled, and everything is dandy. Chuck ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-16 08:11 Message: Logged In: YES user_id=34209 Did this work in Python 2.1(.0) ? Nothing readline-specific changed in 2.1.1c1... It looks like setup.py is using the wrong libraries to link with. When you enable readline.so in 2.0's Setup file, do you edit the list of include/library paths or libraries linked with ? I don't have a SuSe installation to test with, unfortunately. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441580&group_id=5470 From noreply@sourceforge.net Thu Jul 19 15:36:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 07:36:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-441279 ] ConfigParser.options return default opts Message-ID: Bugs item #441279, was opened at 2001-07-14 04:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441279&group_id=5470 >Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: eXom (jkuan) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ConfigParser.options return default opts Initial Comment: I have a config file which has the following sections ------------------ [DEFAULT] logLevel = 9 port = 17870 [SECURITY] user = hello ------------------- On python, if I do the followings: Python 2.0 (#1, Oct 16 2000, 18:10:03) [GCC 2.95.2 19991024 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from ConfigParser import * >>> f = open('/tmp/testrc', 'r') >>> a = ConfigParser() >>> a.defaults() {} >>> a.readfp(f) >>> a.defaults() {'port': '17870', 'loglevel': '9'} >>> a.options("SECURITY") ['port', 'user', 'loglevel'] <<<<<<<>> I thought a.options("SECURITY") will only return ['user'], however it returns everything including the default options. I am a bit confused. Thanks Joe ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-19 07:36 Message: Logged In: YES user_id=3066 This is an accident of the implementation; had your DEFAULT section been named anything else (such as DEFAULT-OPTIONS), you would not have been bitten by this. It should not be hard to rearrange the implementation to make the acquistion of information from the set of default values less prone to accidental interactions. Assigning to myself. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441279&group_id=5470 From noreply@sourceforge.net Thu Jul 19 15:37:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 07:37:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-442758 ] 2.2a1: New style classes and __cmp__ Message-ID: Bugs item #442758, was opened at 2001-07-19 07:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442758&group_id=5470 Category: None Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Guido van Rossum (gvanrossum) Summary: 2.2a1: New style classes and __cmp__ Initial Comment: Implementing __cmp__ in a new style class doesn't seem to have an effect: ---- class Foo: def __cmp__(self, other): print "foo", other return 0 class Bar(object): def __cmp__(self, other): print "bar", other return 0 Foo() == 42 Bar() == 42 ---- This only prints: foo 42 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442758&group_id=5470 From noreply@sourceforge.net Thu Jul 19 15:49:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 07:49:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-442724 ] Setting PYTHONHOME= breaks setup.py Message-ID: Bugs item #442724, was opened at 2001-07-19 05:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442724&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Thomas Wouters (twouters) Summary: Setting PYTHONHOME= breaks setup.py Initial Comment: On UnixWare, the Makefile now invokes PYTHONPATH= PYTHONHOME= PYTHONSTARTUP= ./python setup.py build This gives the error 'import site' failed; use -v for traceback Traceback (most recent call last): File "setup.py", line 6, in ? import sys, os, getopt ImportError: No module named os The problem is that it only looks in . and lib/python2.2/*, not in Lib. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-07-19 07:49 Message: Logged In: YES user_id=34209 No, it should not: unset does not *exist* on FreeBSD and other BSDish platforms, so it can hardly be the right thing :) I'm with Guido on this one, though: there should just be a command-line option 'ignore all PYTHON* env vars' in Python. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-07-19 07:27 Message: Logged In: YES user_id=35752 I still think unsetting PYTHONHOME is the right thing to do. Setting PYTHONHOME to "" is a bad idea. "PYTHONHOME=" and "unset PYTHONHOME" are not equivalent. The line in the makefile should be: unset PYTHONPATH PYTHONHOME PYTHONSTARTUP; ./$(PYTHON) $(srcdir)/setup.py build ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-19 06:15 Message: Logged In: YES user_id=34209 Unsetting PYTHONHOME was not my idea :) But I do agree that doing this in 2.1.1 is not a good idea. Reverting the patch there, and reassigning the bug to Neil, whose idea it seems to have been. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442724&group_id=5470 From noreply@sourceforge.net Thu Jul 19 15:50:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 07:50:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-442758 ] 2.2a1: New style classes and __cmp__ Message-ID: Bugs item #442758, was opened at 2001-07-19 07:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442758&group_id=5470 >Category: type/class unification >Group: Python 2.2 Status: Open Resolution: None Priority: 6 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: 2.2a1: New style classes and __cmp__ Initial Comment: Implementing __cmp__ in a new style class doesn't seem to have an effect: ---- class Foo: def __cmp__(self, other): print "foo", other return 0 class Bar(object): def __cmp__(self, other): print "bar", other return 0 Foo() == 42 Bar() == 42 ---- This only prints: foo 42 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 07:50 Message: Logged In: YES user_id=6380 Since __cmp__ is being phased out in favor of rich comparisons, I would consider this a feature. Do you agree? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442758&group_id=5470 From noreply@sourceforge.net Thu Jul 19 15:57:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 07:57:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-442758 ] 2.2a1: New style classes and __cmp__ Message-ID: Bugs item #442758, was opened at 2001-07-19 07:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442758&group_id=5470 Category: type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 6 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: 2.2a1: New style classes and __cmp__ Initial Comment: Implementing __cmp__ in a new style class doesn't seem to have an effect: ---- class Foo: def __cmp__(self, other): print "foo", other return 0 class Bar(object): def __cmp__(self, other): print "bar", other return 0 Foo() == 42 Bar() == 42 ---- This only prints: foo 42 ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2001-07-19 07:57 Message: Logged In: YES user_id=89016 But then some kind of warning should be issued. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 07:50 Message: Logged In: YES user_id=6380 Since __cmp__ is being phased out in favor of rich comparisons, I would consider this a feature. Do you agree? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442758&group_id=5470 From noreply@sourceforge.net Thu Jul 19 16:00:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 08:00:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-442758 ] 2.2a1: New style classes and __cmp__ Message-ID: Bugs item #442758, was opened at 2001-07-19 07:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442758&group_id=5470 Category: type/class unification Group: Python 2.2 Status: Open Resolution: None >Priority: 3 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: 2.2a1: New style classes and __cmp__ Initial Comment: Implementing __cmp__ in a new style class doesn't seem to have an effect: ---- class Foo: def __cmp__(self, other): print "foo", other return 0 class Bar(object): def __cmp__(self, other): print "bar", other return 0 Foo() == 42 Bar() == 42 ---- This only prints: foo 42 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 08:00 Message: Logged In: YES user_id=6380 Really? We don't warn if you define __foo__ either. Now, a tool to aid in converting classes to the new style might want to treat __cmp__ special. But I don't think that the new style implementation itself ought to warn about __cmp__. Of course, the documentation should list all the special methods that *are* supported -- you'll find more differences, e.g. __getattr__ and __setattr__ work differently, and __del__ isn't supported (yet). ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-07-19 07:57 Message: Logged In: YES user_id=89016 But then some kind of warning should be issued. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 07:50 Message: Logged In: YES user_id=6380 Since __cmp__ is being phased out in favor of rich comparisons, I would consider this a feature. Do you agree? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442758&group_id=5470 From noreply@sourceforge.net Thu Jul 19 16:00:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 08:00:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-442647 ] 2.2alpha1: from __future__ import Message-ID: Bugs item #442647, was opened at 2001-07-18 19:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442647&group_id=5470 Category: Parser/Compiler Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Häring (ghaering) >Assigned to: Guido van Rossum (gvanrossum) Summary: 2.2alpha1: from __future__ import Initial Comment: I noticed that from __future__ import nested_scopes, generators doesn't enable the yield keyword, while the reverse order of importing from __future__ does. I think that the order of imports shouldn't matter. Code showing this behaviour attached. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 05:21 Message: Logged In: YES user_id=6380 You're right. I'll see if I can fix this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442647&group_id=5470 From noreply@sourceforge.net Thu Jul 19 16:28:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 08:28:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-442647 ] 2.2alpha1: from __future__ import Message-ID: Bugs item #442647, was opened at 2001-07-18 19:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442647&group_id=5470 Category: Parser/Compiler Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gerhard Häring (ghaering) Assigned to: Guido van Rossum (gvanrossum) Summary: 2.2alpha1: from __future__ import Initial Comment: I noticed that from __future__ import nested_scopes, generators doesn't enable the yield keyword, while the reverse order of importing from __future__ does. I think that the order of imports shouldn't matter. Code showing this behaviour attached. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 08:28 Message: Logged In: YES user_id=6380 Fixed in parser.c 2.20 (will find its way into descr-branch soon). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 05:21 Message: Logged In: YES user_id=6380 You're right. I'll see if I can fix this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442647&group_id=5470 From noreply@sourceforge.net Thu Jul 19 16:29:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 08:29:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-442758 ] 2.2a1: New style classes and __cmp__ Message-ID: Bugs item #442758, was opened at 2001-07-19 07:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442758&group_id=5470 Category: type/class unification Group: Python 2.2 >Status: Closed >Resolution: Wont Fix Priority: 3 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: 2.2a1: New style classes and __cmp__ Initial Comment: Implementing __cmp__ in a new style class doesn't seem to have an effect: ---- class Foo: def __cmp__(self, other): print "foo", other return 0 class Bar(object): def __cmp__(self, other): print "bar", other return 0 Foo() == 42 Bar() == 42 ---- This only prints: foo 42 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 08:00 Message: Logged In: YES user_id=6380 Really? We don't warn if you define __foo__ either. Now, a tool to aid in converting classes to the new style might want to treat __cmp__ special. But I don't think that the new style implementation itself ought to warn about __cmp__. Of course, the documentation should list all the special methods that *are* supported -- you'll find more differences, e.g. __getattr__ and __setattr__ work differently, and __del__ isn't supported (yet). ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-07-19 07:57 Message: Logged In: YES user_id=89016 But then some kind of warning should be issued. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 07:50 Message: Logged In: YES user_id=6380 Since __cmp__ is being phased out in favor of rich comparisons, I would consider this a feature. Do you agree? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442758&group_id=5470 From noreply@sourceforge.net Thu Jul 19 16:31:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 08:31:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-442758 ] 2.2a1: New style classes and __cmp__ Message-ID: Bugs item #442758, was opened at 2001-07-19 07:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442758&group_id=5470 Category: type/class unification Group: Python 2.2 >Status: Open Resolution: Wont Fix Priority: 3 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: 2.2a1: New style classes and __cmp__ Initial Comment: Implementing __cmp__ in a new style class doesn't seem to have an effect: ---- class Foo: def __cmp__(self, other): print "foo", other return 0 class Bar(object): def __cmp__(self, other): print "bar", other return 0 Foo() == 42 Bar() == 42 ---- This only prints: foo 42 ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2001-07-19 08:31 Message: Logged In: YES user_id=89016 OK, you're right, but I think at least the documentation should should mention it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 08:00 Message: Logged In: YES user_id=6380 Really? We don't warn if you define __foo__ either. Now, a tool to aid in converting classes to the new style might want to treat __cmp__ special. But I don't think that the new style implementation itself ought to warn about __cmp__. Of course, the documentation should list all the special methods that *are* supported -- you'll find more differences, e.g. __getattr__ and __setattr__ work differently, and __del__ isn't supported (yet). ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-07-19 07:57 Message: Logged In: YES user_id=89016 But then some kind of warning should be issued. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 07:50 Message: Logged In: YES user_id=6380 Since __cmp__ is being phased out in favor of rich comparisons, I would consider this a feature. Do you agree? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442758&group_id=5470 From noreply@sourceforge.net Thu Jul 19 16:44:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 08:44:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-442791 ] 2.2a1: New style classes and __delitem__ Message-ID: Bugs item #442791, was opened at 2001-07-19 08:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442791&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2a1: New style classes and __delitem__ Initial Comment: And another one: New style class don't seem to support __delitem__: ---- class Foo(object): def __delitem__(self, key): print "__delitem__" del Foo()[42] ---- This results in: Traceback (most recent call last): File "test.py", line 5, in ? del Foo()[42] TypeError: object doesn't support item deletion ---- Changing the base class to dictionary results in: ---- Traceback (most recent call last): File "test.py", line 5, in ? del Foo()[42] KeyError: 42 ---- but Foo.__delitem__ doesn't seem to be called. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442791&group_id=5470 From noreply@sourceforge.net Thu Jul 19 17:11:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 09:11:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-440351 ] saxutils.escape needs to escape "quotes" Message-ID: Bugs item #440351, was opened at 2001-07-11 03:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440351&group_id=5470 Category: XML Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Andrew Dalke (dalke) >Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: saxutils.escape needs to escape "quotes" Initial Comment: XML attributes containing a value with a double quote are not properly escaped. Consider from xml.sax import saxutils gen = saxutils.XMLGenerator() gen.startDocument() gen.startElement('spam', {'width': '12"'}) This produces That second line should more likely be or perhaps use the hex escape, which I think is ''. But I'm not an XML guru so don't trust me on either one! Andrew Dalke dalke@acm.org ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-19 09:11 Message: Logged In: YES user_id=3066 Fixed, but not in the way requested. ;-) I've added a new function to the saxutils module, quoteattr(). It prepares an attribute value for inclusion as part of markup by doing "just enough" escaping of quote characters, and supplies the proper quote characters for the escaping it actually did. The addition was checked in as Lib/xml/sax/saxutils.py revision 1.15, with corresponding documentation and test updates. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440351&group_id=5470 From noreply@sourceforge.net Thu Jul 19 17:16:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 09:16:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-442796 ] No descrobject in CVS Makefile.pre.in Message-ID: Bugs item #442796, was opened at 2001-07-19 09:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442796&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Justin D. Pettit (jpettit) Assigned to: Nobody/Anonymous (nobody) Summary: No descrobject in CVS Makefile.pre.in Initial Comment: I grabbed the newest version of the Makefile from CVS, since I was having problems with unset in the old one. When I tried to build, it failed during the link stage due to missing references to "PyDescr_" functions. When I add descrobject.o to the OBJECT_OBJS definition and "descrobject.h to the PYTHON_HEADERS definition, the build works fine. I assume these definitions disappeared during one of the merges, because Python-2.2.a1 has them. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442796&group_id=5470 From noreply@sourceforge.net Thu Jul 19 17:17:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 09:17:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-442724 ] Setting PYTHONHOME= breaks setup.py Message-ID: Bugs item #442724, was opened at 2001-07-19 05:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442724&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Thomas Wouters (twouters) Summary: Setting PYTHONHOME= breaks setup.py Initial Comment: On UnixWare, the Makefile now invokes PYTHONPATH= PYTHONHOME= PYTHONSTARTUP= ./python setup.py build This gives the error 'import site' failed; use -v for traceback Traceback (most recent call last): File "setup.py", line 6, in ? import sys, os, getopt ImportError: No module named os The problem is that it only looks in . and lib/python2.2/*, not in Lib. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-19 09:17 Message: Logged In: YES user_id=21627 Fixed in Makefile.pre.in 1.43. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-19 07:49 Message: Logged In: YES user_id=34209 No, it should not: unset does not *exist* on FreeBSD and other BSDish platforms, so it can hardly be the right thing :) I'm with Guido on this one, though: there should just be a command-line option 'ignore all PYTHON* env vars' in Python. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-07-19 07:27 Message: Logged In: YES user_id=35752 I still think unsetting PYTHONHOME is the right thing to do. Setting PYTHONHOME to "" is a bad idea. "PYTHONHOME=" and "unset PYTHONHOME" are not equivalent. The line in the makefile should be: unset PYTHONPATH PYTHONHOME PYTHONSTARTUP; ./$(PYTHON) $(srcdir)/setup.py build ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-19 06:15 Message: Logged In: YES user_id=34209 Unsetting PYTHONHOME was not my idea :) But I do agree that doing this in 2.1.1 is not a good idea. Reverting the patch there, and reassigning the bug to Neil, whose idea it seems to have been. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442724&group_id=5470 From noreply@sourceforge.net Thu Jul 19 17:22:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 09:22:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-428289 ] Integrates log4p Message-ID: Bugs item #428289, was opened at 2001-05-29 05:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428289&group_id=5470 Category: Python Interpreter Core Group: Feature Request >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: eXom (jkuan) Assigned to: Nobody/Anonymous (nobody) Summary: Integrates log4p Initial Comment: I have read about log4j which is great for developers. Also notice that has been ported to python, log4p, log4p.sourceforge.net. I personally think this will be one of the great tools if it integrates into python core. At least more open source python developer will definitely want to use it, rather than they have to maintain their own log4p. Now python has a module that provides auto test framework, I deeply think the next thing should be logging. Thanks Joe ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-19 09:22 Message: Logged In: YES user_id=3066 It is not clear that additional logging facilities are needed, nor that a common implementation for logging really makes sense. Experience says a single implementation typically does not make sense, and different applications have widely varying requirements of a logging facility. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-05 23:58 Message: Logged In: YES user_id=21627 I hope this won't integrated into Python. Mirroring the Java package structure is not a good idea (from java.text import DateFormat???) Instead, it seems that all the underlying support libraries are already there: you have the syslog module on Unix, and the win32evtlog on Windows. It might be that some universal wrapper is desirable - but log4p currently does not look like material for the Python core. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428289&group_id=5470 From noreply@sourceforge.net Thu Jul 19 17:23:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 09:23:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-442791 ] 2.2a1: New style classes and __delitem__ Message-ID: Bugs item #442791, was opened at 2001-07-19 08:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442791&group_id=5470 >Category: type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Guido van Rossum (gvanrossum) Summary: 2.2a1: New style classes and __delitem__ Initial Comment: And another one: New style class don't seem to support __delitem__: ---- class Foo(object): def __delitem__(self, key): print "__delitem__" del Foo()[42] ---- This results in: Traceback (most recent call last): File "test.py", line 5, in ? del Foo()[42] TypeError: object doesn't support item deletion ---- Changing the base class to dictionary results in: ---- Traceback (most recent call last): File "test.py", line 5, in ? del Foo()[42] KeyError: 42 ---- but Foo.__delitem__ doesn't seem to be called. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442791&group_id=5470 From noreply@sourceforge.net Thu Jul 19 17:24:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 09:24:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-442796 ] No descrobject in CVS Makefile.pre.in Message-ID: Bugs item #442796, was opened at 2001-07-19 09:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442796&group_id=5470 >Category: type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Justin D. Pettit (jpettit) >Assigned to: Tim Peters (tim_one) Summary: No descrobject in CVS Makefile.pre.in Initial Comment: I grabbed the newest version of the Makefile from CVS, since I was having problems with unset in the old one. When I tried to build, it failed during the link stage due to missing references to "PyDescr_" functions. When I add descrobject.o to the OBJECT_OBJS definition and "descrobject.h to the PYTHON_HEADERS definition, the build works fine. I assume these definitions disappeared during one of the merges, because Python-2.2.a1 has them. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442796&group_id=5470 From noreply@sourceforge.net Thu Jul 19 17:24:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 09:24:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-442796 ] No descrobject in CVS Makefile.pre.in Message-ID: Bugs item #442796, was opened at 2001-07-19 09:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442796&group_id=5470 >Category: Build >Group: Not a Bug >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Justin D. Pettit (jpettit) >Assigned to: Nobody/Anonymous (nobody) Summary: No descrobject in CVS Makefile.pre.in Initial Comment: I grabbed the newest version of the Makefile from CVS, since I was having problems with unset in the old one. When I tried to build, it failed during the link stage due to missing references to "PyDescr_" functions. When I add descrobject.o to the OBJECT_OBJS definition and "descrobject.h to the PYTHON_HEADERS definition, the build works fine. I assume these definitions disappeared during one of the merges, because Python-2.2.a1 has them. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-19 09:24 Message: Logged In: YES user_id=21627 This is not a bug. The descrobject.c only exists in the descr-branch of the CVS, not in the mainline; 2.2a1 was not build from the mainline, but from the descr-branch - get the Makefile from the descr-branch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442796&group_id=5470 From noreply@sourceforge.net Thu Jul 19 17:29:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 09:29:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-415612 ] readline ext fails w/ new v4.2 Message-ID: Bugs item #415612, was opened at 2001-04-11 23:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=415612&group_id=5470 Category: Extension Modules Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 2 Submitted By: Gordon Sadler (gbsadler) Assigned to: Nobody/Anonymous (nobody) Summary: readline ext fails w/ new v4.2 Initial Comment: Top of my test.log from make test: PYTHONPATH= ./python ./setup.py build /home/gbsadler/cvs/python/dist/src/Modules/readline.c:34: conflicting types for `rl_read_init_file' /usr/include/readline/readline.h:304: previous declaration of `rl_read_init_file' /home/gbsadler/cvs/python/dist/src/Modules/readline.c:35: conflicting types for `rl_insert_text' /usr/include/readline/readline.h:364: previous declaration of `rl_insert_text' /home/gbsadler/cvs/python/dist/src/Modules/readline.c: In function `set_completer_delims': /home/gbsadler/cvs/python/dist/src/Modules/readline.c:231: warning: passing arg 1 of `free' discards qualifiers from poi nter target type /home/gbsadler/cvs/python/dist/src/Modules/readline.c: In function `flex_complete': /home/gbsadler/cvs/python/dist/src/Modules/readline.c:403: warning: implicit declaration of function `completion_matches ' /home/gbsadler/cvs/python/dist/src/Modules/readline.c:403: warning: return makes pointer from integer without a cast rl_read_init_file and rl_insert_text both now expect (const char*) as parameters. These are your choices for completion_matches: readline.h:extern char **rl_completion_matches __P((const char *, rl_compentry_func_t *)); readline.h:extern char **completion_matches __P((char *, rl_compentry_func_t *)); Here's the compile line from test.log: building 'readline' extension gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -I. -I/home/gbsadler/cvs/python/dist/src/./Include -I/usr/local/include -IInc lude/ -c /home/gbsadler/cvs/python/dist/src/Modules/readline.c -o build/temp.linux-i686-2.1/readline.o -g -O2 -Wall -Wst rict-prototypes -I. -I./Include -DHAVE_CONFIG_H WARNING: building of extension "readline" failed: command 'gcc' failed with exit status 1 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-19 09:29 Message: Logged In: YES user_id=3066 This was fixed a couple of weeks ago in CVS; the fix was included as part of Python 2.2 alpha 1. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-13 18:43 Message: Logged In: YES user_id=6380 Really old versions of readline don'y have rl_library_version, but most do (3.0 does). Can you cook up a patch for the configure script to take this into account? I won't have time for this before releasing 2.1 final, and I don't think it's a big enough deal to worry about much. ---------------------------------------------------------------------- Comment By: Gordon Sadler (gbsadler) Date: 2001-04-13 18:17 Message: Logged In: YES user_id=150968 Have a feeling the file attachment didn't take. In case here it is. #include #include int main () { printf ("version is %s \n",rl_library_version); return 0; } Real simple, but not sure what <4.2 will return/print. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-13 13:57 Message: Logged In: YES user_id=6380 I've changed the readline module so that it always just includes the readline.h and history.h header files; this takes care of the errors with readline 4.2. There are still a few warnings left; I can't get rid of those without breaking the build for readline 3.x. Leaving this issue open for now in case someone comes with a bright idea on how to detect readline versions at compile time. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=415612&group_id=5470 From noreply@sourceforge.net Thu Jul 19 17:34:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 09:34:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-442796 ] No descrobject in CVS Makefile.pre.in Message-ID: Bugs item #442796, was opened at 2001-07-19 09:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442796&group_id=5470 Category: Build Group: Not a Bug Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Justin D. Pettit (jpettit) Assigned to: Nobody/Anonymous (nobody) Summary: No descrobject in CVS Makefile.pre.in Initial Comment: I grabbed the newest version of the Makefile from CVS, since I was having problems with unset in the old one. When I tried to build, it failed during the link stage due to missing references to "PyDescr_" functions. When I add descrobject.o to the OBJECT_OBJS definition and "descrobject.h to the PYTHON_HEADERS definition, the build works fine. I assume these definitions disappeared during one of the merges, because Python-2.2.a1 has them. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-19 09:34 Message: Logged In: YES user_id=31435 Martin is correct, and perhaps we didn't publicize this enough. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-19 09:24 Message: Logged In: YES user_id=21627 This is not a bug. The descrobject.c only exists in the descr-branch of the CVS, not in the mainline; 2.2a1 was not build from the mainline, but from the descr-branch - get the Makefile from the descr-branch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442796&group_id=5470 From noreply@sourceforge.net Thu Jul 19 17:36:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 09:36:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-442791 ] 2.2a1: New style classes and __delitem__ Message-ID: Bugs item #442791, was opened at 2001-07-19 08:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442791&group_id=5470 Category: type/class unification >Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: 2.2a1: New style classes and __delitem__ Initial Comment: And another one: New style class don't seem to support __delitem__: ---- class Foo(object): def __delitem__(self, key): print "__delitem__" del Foo()[42] ---- This results in: Traceback (most recent call last): File "test.py", line 5, in ? del Foo()[42] TypeError: object doesn't support item deletion ---- Changing the base class to dictionary results in: ---- Traceback (most recent call last): File "test.py", line 5, in ? del Foo()[42] KeyError: 42 ---- but Foo.__delitem__ doesn't seem to be called. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 09:36 Message: Logged In: YES user_id=6380 Whoops, you found a whole slew of bugs in this area! I've fixed this now in the descr-branch of the CVS tree, in Object/typeobject.c:2.16.8.69. I've also added a bit to the test suite that checks these (and slices). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442791&group_id=5470 From noreply@sourceforge.net Thu Jul 19 17:37:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 09:37:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-442758 ] 2.2a1: New style classes and __cmp__ Message-ID: Bugs item #442758, was opened at 2001-07-19 07:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442758&group_id=5470 Category: type/class unification Group: Python 2.2 >Status: Closed Resolution: Wont Fix Priority: 3 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: 2.2a1: New style classes and __cmp__ Initial Comment: Implementing __cmp__ in a new style class doesn't seem to have an effect: ---- class Foo: def __cmp__(self, other): print "foo", other return 0 class Bar(object): def __cmp__(self, other): print "bar", other return 0 Foo() == 42 Bar() == 42 ---- This only prints: foo 42 ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-07-19 08:31 Message: Logged In: YES user_id=89016 OK, you're right, but I think at least the documentation should should mention it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 08:00 Message: Logged In: YES user_id=6380 Really? We don't warn if you define __foo__ either. Now, a tool to aid in converting classes to the new style might want to treat __cmp__ special. But I don't think that the new style implementation itself ought to warn about __cmp__. Of course, the documentation should list all the special methods that *are* supported -- you'll find more differences, e.g. __getattr__ and __setattr__ work differently, and __del__ isn't supported (yet). ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-07-19 07:57 Message: Logged In: YES user_id=89016 But then some kind of warning should be issued. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 07:50 Message: Logged In: YES user_id=6380 Since __cmp__ is being phased out in favor of rich comparisons, I would consider this a feature. Do you agree? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442758&group_id=5470 From noreply@sourceforge.net Thu Jul 19 17:37:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 09:37:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-442758 ] 2.2a1: New style classes and __cmp__ Message-ID: Bugs item #442758, was opened at 2001-07-19 07:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442758&group_id=5470 Category: type/class unification Group: Python 2.2 Status: Closed Resolution: Wont Fix Priority: 3 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: 2.2a1: New style classes and __cmp__ Initial Comment: Implementing __cmp__ in a new style class doesn't seem to have an effect: ---- class Foo: def __cmp__(self, other): print "foo", other return 0 class Bar(object): def __cmp__(self, other): print "bar", other return 0 Foo() == 42 Bar() == 42 ---- This only prints: foo 42 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 09:37 Message: Logged In: YES user_id=6380 What documentation? :-) Oh well, you're right. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-07-19 08:31 Message: Logged In: YES user_id=89016 OK, you're right, but I think at least the documentation should should mention it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 08:00 Message: Logged In: YES user_id=6380 Really? We don't warn if you define __foo__ either. Now, a tool to aid in converting classes to the new style might want to treat __cmp__ special. But I don't think that the new style implementation itself ought to warn about __cmp__. Of course, the documentation should list all the special methods that *are* supported -- you'll find more differences, e.g. __getattr__ and __setattr__ work differently, and __del__ isn't supported (yet). ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-07-19 07:57 Message: Logged In: YES user_id=89016 But then some kind of warning should be issued. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 07:50 Message: Logged In: YES user_id=6380 Since __cmp__ is being phased out in favor of rich comparisons, I would consider this a feature. Do you agree? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442758&group_id=5470 From noreply@sourceforge.net Thu Jul 19 18:31:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 10:31:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-442813 ] 2.2a1: list.__getitem__ and index<0 Message-ID: Bugs item #442813, was opened at 2001-07-19 10:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442813&group_id=5470 Category: type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: 2.2a1: list.__getitem__ and index<0 Initial Comment: list.__getitem__ doesn't handle negative indizes when called directly: >>> x = [1] >>> list.__getitem__(x, -1) Traceback (most recent call last): File "", line 1, in ? IndexError: list index out of range ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442813&group_id=5470 From noreply@sourceforge.net Thu Jul 19 18:21:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 10:21:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-442712 ] os.path.expanduser problem w/o HOME set Message-ID: Bugs item #442712, was opened at 2001-07-19 04:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442712&group_id=5470 Category: Windows Group: Python 2.1.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: os.path.expanduser problem w/o HOME set Initial Comment: If I do a os.path.expanduser("~") I get '\Documents and Settings\kwg' - the C: drive is not mentioned. I traced this to the call to join (and onwards to the isabs call in the code for the join function. Simple remedy is to use userhome = drive + os.environ['HOMEPATH'] instead of userhome = join(drive, os.environ['HOMEPATH'] My sys.version value is '2.1 (#15, Apr 16 2001, 18:24:49) [MSC 32 bit (Intel]' ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-19 10:21 Message: Logged In: YES user_id=31435 Agree with Guido that ntpath.join was too stupid. Fixed in Lib/ntpath.py, rev 1.37. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 07:08 Message: Logged In: YES user_id=6380 Well, I think join should be made smarter! os.path.isabs("\foo") returns 0 because \f is interpreted by the interpreter as '\x0c'. Try "\foo" or r"\foo" instead. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-19 06:11 Message: Logged In: NO I think the reason why join doesn't work is to do with isabs returning true when "\foo" is entered as a parameter under NT - surely the name of the drive must be included if the parameter doesn't look like a UNC filename? Inother words, on NT \foo should fail //ferrari\foo should not fail c:\foo should not fail I've also noticed that os.path.isabs("\foo") returns 0, os.path.isabs("/foo") returns 1 on Windows 2000. Surely this should be the other way round? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 05:45 Message: Logged In: YES user_id=6380 Hm, but why doesn't the join() work? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442712&group_id=5470 From noreply@sourceforge.net Thu Jul 19 19:29:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 11:29:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-442833 ] 2.2a1: __int__ and multiple inheritance Message-ID: Bugs item #442833, was opened at 2001-07-19 11:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442833&group_id=5470 Category: type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: 2.2a1: __int__ and multiple inheritance Initial Comment: The __int__ special method doesn't seem to be inherited correctly somehow when multiple inheritance is involved: ---- class Node(object): def __int__(self): return int(self.str()) def str(self): return "23" class Frag(Node, list): def str(self): return "42" print Node().__int__() print int(Node()) print Frag().__int__() print int(Frag()) ---- Output is: ---- 23 23 42 Traceback (most recent call last): File "xsc.py", line 14, in ? print int(Frag()) TypeError: object can't be converted to int ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442833&group_id=5470 From noreply@sourceforge.net Thu Jul 19 19:35:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 11:35:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-442712 ] os.path.expanduser problem w/o HOME set Message-ID: Bugs item #442712, was opened at 2001-07-19 04:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442712&group_id=5470 Category: Windows Group: Python 2.1.1 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: os.path.expanduser problem w/o HOME set Initial Comment: If I do a os.path.expanduser("~") I get '\Documents and Settings\kwg' - the C: drive is not mentioned. I traced this to the call to join (and onwards to the isabs call in the code for the join function. Simple remedy is to use userhome = drive + os.environ['HOMEPATH'] instead of userhome = join(drive, os.environ['HOMEPATH'] My sys.version value is '2.1 (#15, Apr 16 2001, 18:24:49) [MSC 32 bit (Intel]' ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 11:35 Message: Logged In: YES user_id=6380 Is there a test suite for ntpath that shows the various endcases? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-19 10:21 Message: Logged In: YES user_id=31435 Agree with Guido that ntpath.join was too stupid. Fixed in Lib/ntpath.py, rev 1.37. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 07:08 Message: Logged In: YES user_id=6380 Well, I think join should be made smarter! os.path.isabs("\foo") returns 0 because \f is interpreted by the interpreter as '\x0c'. Try "\foo" or r"\foo" instead. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-19 06:11 Message: Logged In: NO I think the reason why join doesn't work is to do with isabs returning true when "\foo" is entered as a parameter under NT - surely the name of the drive must be included if the parameter doesn't look like a UNC filename? Inother words, on NT \foo should fail //ferrari\foo should not fail c:\foo should not fail I've also noticed that os.path.isabs("\foo") returns 0, os.path.isabs("/foo") returns 1 on Windows 2000. Surely this should be the other way round? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 05:45 Message: Logged In: YES user_id=6380 Hm, but why doesn't the join() work? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442712&group_id=5470 From noreply@sourceforge.net Thu Jul 19 19:42:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 11:42:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-442833 ] 2.2a1: __int__ and multiple inheritance Message-ID: Bugs item #442833, was opened at 2001-07-19 11:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442833&group_id=5470 Category: type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: 2.2a1: __int__ and multiple inheritance Initial Comment: The __int__ special method doesn't seem to be inherited correctly somehow when multiple inheritance is involved: ---- class Node(object): def __int__(self): return int(self.str()) def str(self): return "23" class Frag(Node, list): def str(self): return "42" print Node().__int__() print int(Node()) print Frag().__int__() print int(Frag()) ---- Output is: ---- 23 23 42 Traceback (most recent call last): File "xsc.py", line 14, in ? print int(Frag()) TypeError: object can't be converted to int ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 11:42 Message: Logged In: YES user_id=6380 Right again. This will take some time to fix... I believe I currently only look in the "primary" base class for special slots, where the "primary" base class in your example is 'list'. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442833&group_id=5470 From noreply@sourceforge.net Thu Jul 19 19:44:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 11:44:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-442712 ] os.path.expanduser problem w/o HOME set Message-ID: Bugs item #442712, was opened at 2001-07-19 04:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442712&group_id=5470 Category: Windows Group: Python 2.1.1 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: os.path.expanduser problem w/o HOME set Initial Comment: If I do a os.path.expanduser("~") I get '\Documents and Settings\kwg' - the C: drive is not mentioned. I traced this to the call to join (and onwards to the isabs call in the code for the join function. Simple remedy is to use userhome = drive + os.environ['HOMEPATH'] instead of userhome = join(drive, os.environ['HOMEPATH'] My sys.version value is '2.1 (#15, Apr 16 2001, 18:24:49) [MSC 32 bit (Intel]' ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-19 11:44 Message: Logged In: YES user_id=31435 test_ntpath.py is a tiny test suite. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 11:35 Message: Logged In: YES user_id=6380 Is there a test suite for ntpath that shows the various endcases? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-19 10:21 Message: Logged In: YES user_id=31435 Agree with Guido that ntpath.join was too stupid. Fixed in Lib/ntpath.py, rev 1.37. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 07:08 Message: Logged In: YES user_id=6380 Well, I think join should be made smarter! os.path.isabs("\foo") returns 0 because \f is interpreted by the interpreter as '\x0c'. Try "\foo" or r"\foo" instead. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-19 06:11 Message: Logged In: NO I think the reason why join doesn't work is to do with isabs returning true when "\foo" is entered as a parameter under NT - surely the name of the drive must be included if the parameter doesn't look like a UNC filename? Inother words, on NT \foo should fail //ferrari\foo should not fail c:\foo should not fail I've also noticed that os.path.isabs("\foo") returns 0, os.path.isabs("/foo") returns 1 on Windows 2000. Surely this should be the other way round? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 05:45 Message: Logged In: YES user_id=6380 Hm, but why doesn't the join() work? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442712&group_id=5470 From noreply@sourceforge.net Thu Jul 19 20:12:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 12:12:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-438786 ] CVS 2.1.1c1 broken on osf1V4 Message-ID: Bugs item #438786, was opened at 2001-07-05 07:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Nobody/Anonymous (nobody) Summary: CVS 2.1.1c1 broken on osf1V4 Initial Comment: As of right now, the CVS branch for the 2.1 bugfix release cannot import the math module on my Digital Unix platform. ImportError: Unresolved symbol in /tmp_mnt/home/gball/usr/src/python/dist/src/build/lib.osf1-V4.0-alpha-2.1/math.so: __eprintf uname is OSF1 surya V4.0 878 alpha ---------------------------------------------------------------------- >Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-19 12:12 Message: Logged In: YES user_id=11365 I just checked out the 2.1.1 branch again and it still seems to be broken. After a fresh config with $CC set to gcc in the environment, the Makefile contains CC= cc OPT= -O -Olimit 1500 CCSHARED= so it looks like configure has decided to use cc and chosen flags for that compiler. Then, the actual build command lines look like gcc -I. -I/tmp_mnt/home/gball/usr/src/python/dist/src/./Include -I/usr/local/include -IInclude/ -c /tmp_mnt/home/gball/usr/src/python/dist/src/Modules/fpectlmodule.c -o build/temp.osf1-V4.0-alpha-2.1/fpectlmodule.o i.e. just "gcc" instead of "cc -O -Olimit 1500" so it looks like the environment variable gets pulled in only at the last moment and replaces $(CC), $(OPT) and possibly $(CCSHARED), thereby throwing away the work done by configure. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-19 02:59 Message: Logged In: YES user_id=34209 Gregory, did you get a chance to test the patch attached to bug #437487, or the 2.1.1 CVS tree ? I'd like to know if this is fixed in 2.1.1. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-16 08:56 Message: Logged In: YES user_id=34209 Ah, yes, that sounds very plausible. The fix for that problem, which was checked in on the trunk, will be in Python 2.1.1-final as well. The Solaris bugreport has a patch attached to it; could you test it to see if it solves your 2.1.1c1 problem ? ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-09 08:48 Message: Logged In: YES user_id=11365 The problem goes away if I clear $CC instead of having it set to gcc. There's a similar problem on Solaris reported recently. I think the configure script should try to spot this sort of thing, but I suppose that's an Autoconf feature request, not a python bug... Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-08 14:06 Message: Logged In: YES user_id=21627 This sounds like a bug in your compiler installation. __eprintf is typically defined in libgcc.a; make sure you use a consistent compiler capable of building binaries for your system throughout the build process. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 From noreply@sourceforge.net Thu Jul 19 20:38:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 12:38:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-438786 ] CVS 2.1.1c1 broken on osf1V4 Message-ID: Bugs item #438786, was opened at 2001-07-05 07:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) >Assigned to: Guido van Rossum (gvanrossum) Summary: CVS 2.1.1c1 broken on osf1V4 Initial Comment: As of right now, the CVS branch for the 2.1 bugfix release cannot import the math module on my Digital Unix platform. ImportError: Unresolved symbol in /tmp_mnt/home/gball/usr/src/python/dist/src/build/lib.osf1-V4.0-alpha-2.1/math.so: __eprintf uname is OSF1 surya V4.0 878 alpha ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-19 12:38 Message: Logged In: YES user_id=21627 This seems to originate fromt the fragment OSF1) CC=cc without_gcc=;; which was introduced in configure.in 1.23, with the comment on osf/1, never use gcc Therefore, I'm assigning it to Guido. My proposal is to close this as "won't fix" - if setting CC doesn't work, just don't do that. Alternatively, if nobody can remember why gcc should not be used on OSF/1, it might be reasonable to back-out this change. ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-19 12:12 Message: Logged In: YES user_id=11365 I just checked out the 2.1.1 branch again and it still seems to be broken. After a fresh config with $CC set to gcc in the environment, the Makefile contains CC= cc OPT= -O -Olimit 1500 CCSHARED= so it looks like configure has decided to use cc and chosen flags for that compiler. Then, the actual build command lines look like gcc -I. -I/tmp_mnt/home/gball/usr/src/python/dist/src/./Include -I/usr/local/include -IInclude/ -c /tmp_mnt/home/gball/usr/src/python/dist/src/Modules/fpectlmodule.c -o build/temp.osf1-V4.0-alpha-2.1/fpectlmodule.o i.e. just "gcc" instead of "cc -O -Olimit 1500" so it looks like the environment variable gets pulled in only at the last moment and replaces $(CC), $(OPT) and possibly $(CCSHARED), thereby throwing away the work done by configure. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-19 02:59 Message: Logged In: YES user_id=34209 Gregory, did you get a chance to test the patch attached to bug #437487, or the 2.1.1 CVS tree ? I'd like to know if this is fixed in 2.1.1. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-16 08:56 Message: Logged In: YES user_id=34209 Ah, yes, that sounds very plausible. The fix for that problem, which was checked in on the trunk, will be in Python 2.1.1-final as well. The Solaris bugreport has a patch attached to it; could you test it to see if it solves your 2.1.1c1 problem ? ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-09 08:48 Message: Logged In: YES user_id=11365 The problem goes away if I clear $CC instead of having it set to gcc. There's a similar problem on Solaris reported recently. I think the configure script should try to spot this sort of thing, but I suppose that's an Autoconf feature request, not a python bug... Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-08 14:06 Message: Logged In: YES user_id=21627 This sounds like a bug in your compiler installation. __eprintf is typically defined in libgcc.a; make sure you use a consistent compiler capable of building binaries for your system throughout the build process. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 From noreply@sourceforge.net Thu Jul 19 21:33:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 13:33:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-438786 ] CVS 2.1.1c1 broken on osf1V4 Message-ID: Bugs item #438786, was opened at 2001-07-05 07:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) >Assigned to: Martin v. Löwis (loewis) Summary: CVS 2.1.1c1 broken on osf1V4 Initial Comment: As of right now, the CVS branch for the 2.1 bugfix release cannot import the math module on my Digital Unix platform. ImportError: Unresolved symbol in /tmp_mnt/home/gball/usr/src/python/dist/src/build/lib.osf1-V4.0-alpha-2.1/math.so: __eprintf uname is OSF1 surya V4.0 878 alpha ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 13:33 Message: Logged In: YES user_id=6380 I don't recall why that was. It was 6 years ago! Quite possibly things have changed; the OSF in use now is probably quite different than the one then. So, Martin, try to back out the change and see if this doesn't break other things. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-19 12:38 Message: Logged In: YES user_id=21627 This seems to originate fromt the fragment OSF1) CC=cc without_gcc=;; which was introduced in configure.in 1.23, with the comment on osf/1, never use gcc Therefore, I'm assigning it to Guido. My proposal is to close this as "won't fix" - if setting CC doesn't work, just don't do that. Alternatively, if nobody can remember why gcc should not be used on OSF/1, it might be reasonable to back-out this change. ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-19 12:12 Message: Logged In: YES user_id=11365 I just checked out the 2.1.1 branch again and it still seems to be broken. After a fresh config with $CC set to gcc in the environment, the Makefile contains CC= cc OPT= -O -Olimit 1500 CCSHARED= so it looks like configure has decided to use cc and chosen flags for that compiler. Then, the actual build command lines look like gcc -I. -I/tmp_mnt/home/gball/usr/src/python/dist/src/./Include -I/usr/local/include -IInclude/ -c /tmp_mnt/home/gball/usr/src/python/dist/src/Modules/fpectlmodule.c -o build/temp.osf1-V4.0-alpha-2.1/fpectlmodule.o i.e. just "gcc" instead of "cc -O -Olimit 1500" so it looks like the environment variable gets pulled in only at the last moment and replaces $(CC), $(OPT) and possibly $(CCSHARED), thereby throwing away the work done by configure. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-19 02:59 Message: Logged In: YES user_id=34209 Gregory, did you get a chance to test the patch attached to bug #437487, or the 2.1.1 CVS tree ? I'd like to know if this is fixed in 2.1.1. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-16 08:56 Message: Logged In: YES user_id=34209 Ah, yes, that sounds very plausible. The fix for that problem, which was checked in on the trunk, will be in Python 2.1.1-final as well. The Solaris bugreport has a patch attached to it; could you test it to see if it solves your 2.1.1c1 problem ? ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-09 08:48 Message: Logged In: YES user_id=11365 The problem goes away if I clear $CC instead of having it set to gcc. There's a similar problem on Solaris reported recently. I think the configure script should try to spot this sort of thing, but I suppose that's an Autoconf feature request, not a python bug... Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-08 14:06 Message: Logged In: YES user_id=21627 This sounds like a bug in your compiler installation. __eprintf is typically defined in libgcc.a; make sure you use a consistent compiler capable of building binaries for your system throughout the build process. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 From noreply@sourceforge.net Thu Jul 19 22:30:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 14:30:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-442903 ] import Numeric fails on Linux Message-ID: Bugs item #442903, was opened at 2001-07-19 14:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442903&group_id=5470 Category: Extension Modules Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Greg Kochanski (gpk) Assigned to: Nobody/Anonymous (nobody) Summary: import Numeric fails on Linux Initial Comment: \h* python Python 2.1.1c1 (#1, Jul 19 2001, 14:43:40) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import Numeric BUG IN DYNAMIC LINKER ld.so: dynamic-link.h: 62: elf_get_dynamic_info: Assertion `! "bad dynamic tag"' failed! \h* ^D Python was compiled on a Debian Linux system, with 2.4.5 kernel. It runs there, but creates the above error when the same code is run on a Red Hat system with a 2.4.0 kernel. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442903&group_id=5470 From noreply@sourceforge.net Fri Jul 20 07:33:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Jul 2001 23:33:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-442983 ] site.py rev 1.28 broke addsitedir() Message-ID: Bugs item #442983, was opened at 2001-07-19 23:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442983&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: site.py rev 1.28 broke addsitedir() Initial Comment: addsitedir() was changed to refer to global dirs_in_sys_path, but that global got explictly del'ed on line 152 too, so it doesn't exist when addsitedir() is called. Report from c.l.py follows: """ From: David Konerding Sent: Friday, July 20, 2001 1:56 AM To: python-list@python.org Subject: python 2.1.1 trouble with addsitedir Hi, I am checking my application's compatibility wiht 2.1.1 and I've run into a snag. We use "site.addsitedir" to add a directory to the loading path. As an example, the following works just fine on Python- 2.1: [dek@tolkien dek]$ python Python 2.1 (#2, Jul 19 2001, 20:48:59) [GCC 2.95.3 20010315 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import site >>> site.addsitedir("/tmp") >>> but running it with 2.1.1 gives the following: [dek@tolkien Python-2.1.1c1] $ /var/tmp/python/bin/python Python 2.1.1c1 (#1, Jul 19 2001, 22:49:25) [GCC 2.95.3 20010315 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import site >>> site.addsitedir("/tmp") Traceback (most recent call last): File "", line 1, in ? File "/var/tmp/python/lib/python2.1/site.py", line 100, in addsitedir if not dirs_in_sys_path.has_key(sitedircase): NameError: global name 'dirs_in_sys_path' is not defined """ ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442983&group_id=5470 From noreply@sourceforge.net Fri Jul 20 09:09:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 01:09:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-442998 ] 2.2a1: compiler warnings Message-ID: Bugs item #442998, was opened at 2001-07-20 01:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442998&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2a1: compiler warnings Initial Comment: I've done a port to OpenVMS. Here are some compiler warnings: ----- }; ^ %CC-I-TRAILCOMMA, Trailing comma found in enumerator list. at line number 482 in file CEVAL.C ----- There are lots of warnings in TYPEOBJECT.C like: RICHCMP_WRAPPER(lt, Py_LT); ..........................^ %CC-I-EXTRASEMI, Extraneous semicolon. at line number 1707 in file TYPEOBJECT.C RICHCMP_WRAPPER(le, Py_LE); ..........................^ %CC-I-EXTRASEMI, Extraneous semicolon. at line number 1708 in file TYPEOBJECT.C and: SLOT1(sq_concat, add, PyObject *, O); ....................................^ %CC-I-EXTRASEMI, Extraneous semicolon. at line number 1956 in file TYPEOBJECT.C SLOT1(sq_repeat, mul, int, i); .............................^ %CC-I-EXTRASEMI, Extraneous semicolon. at line number 1957 in file TYPEOBJECT.C and: ADD(sq->sq_length, tab_len); ................^ %CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer value "sq->sq_length" is "function (pointer to struct _object) returning int", which is not compatible with "void". at line number 1842 in file TYPEOBJECT.C ADD(sq->sq_concat, tab_add); ................^ %CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer value "sq->sq_concat" is "function (pointer to struct _object, pointer to struct _object) returning pointer to struct _object", which is not compatible with "void". at line number 1843 in file TYPEOBJECT.C add_staticmethodwrappers(type, tab_new, type->tp_new); ....................................................... .^ %CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer value "type->tp_new" is "function (pointer to struct _typeobject, pointer to struct _object, pointer to struct _object) returning pointer to struct _object",which is not compatible with "void". at line number 1917 in file TYPEOBJECT.C There are 100+ warnings which I don't include all, OK? ----- 4 times messages like this in UNICODEOBJECT.C: *p++ = hexdigit[(ch >> 28) & 0xf]; .............................^ %CC-I-RIGHTSHIFTOVR, In this statement, the right shift count "28" is greater than or equal to the size of the unpromoted operand "ch". at line number 1448 in file UNICODEOBJECT.C ----- If you need specific values from my CONFIG.H, please let me know. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442998&group_id=5470 From noreply@sourceforge.net Fri Jul 20 09:48:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 01:48:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-443005 ] 2.2a1: crash via posix_do_stat Message-ID: Bugs item #443005, was opened at 2001-07-20 01:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443005&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Uwe Zessin (zessin_5) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2a1: crash via posix_do_stat Initial Comment: I've done a port to OpenVMS. I get a crash during Python initialization (import of SITE.PY). A work-around for me is to replace the format-string for posix_do_stat() of "et" with "s". Here is the traceback. I have removed the line numbers, because they apply to the compiler listings. $ python %SYSTEM-F-ACCVIO, access violation, ... %TRACE-F-TRACEBACK, symbolic stack dump follows image module routine PYTHON GETARGS convertsimple PYTHON GETARGS convertitem PYTHON GETARGS vgetargs1 PYTHON GETARGS PyArg_ParseTuple PYTHON POSIXMODULE posix_do_stat PYTHON POSIXMODULE posix_stat PYTHON CEVAL call_cfunction PYTHON CEVAL eval_frame PYTHON CEVAL PyEval_EvalCodeEx PYTHON CEVAL fast_function PYTHON CEVAL eval_frame PYTHON CEVAL PyEval_EvalCodeEx PYTHON CEVAL PyEval_EvalCode PYTHON IMPORT PyImport_ExecCodeModuleEx PYTHON IMPORT load_source_module PYTHON IMPORT load_module PYTHON IMPORT import_submodule PYTHON IMPORT load_next PYTHON IMPORT import_module_ex PYTHON IMPORT PyImport_ImportModuleEx PYTHON BLTINMODULE builtin___import__ PYTHON METHODOBJECT meth_call PYTHON ABSTRACT PyObject_Call PYTHON CEVAL PyEval_CallObjectWithKeywords PYTHON ABSTRACT PyObject_CallObject PYTHON ABSTRACT PyObject_CallFunction PYTHON IMPORT PyImport_Import PYTHON IMPORT PyImport_ImportModule PYTHON PYTHONRUN initsite PYTHON PYTHONRUN Py_Initialize PYTHON MAIN Py_Main PYTHON PYTHON main PYTHON PYTHON __main And here is the failing code in GETARGS.C: if ((int)strlen(PyString_AS_STRING(s)) != size) return converterr( "(encoded string without NULL b... arg, msgbuf); -> *buffer = PyMem_NEW(char, size + 1); if (*buffer == NULL) { Py_DECREF(s); return converterr("(memory error)", arg, msgbuf); } ----- I'm sorry, but I can't debug that any better. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443005&group_id=5470 From noreply@sourceforge.net Fri Jul 20 12:34:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 04:34:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-443042 ] unable to build posixmodule Message-ID: Bugs item #443042, was opened at 2001-07-20 04:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443042&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: unable to build posixmodule Initial Comment: gcc -g -O3 -Wall -Wstrict-prototypes -Dss_family=__ss_family -Dss_len=__ss_len -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function `posix_nice': ./Modules/posixmodule.c:1145: warning: implicit declaration of function `getpriority' ./Modules/posixmodule.c:1145: `PRIO_PROCESS' undeclared (first use in this function) ./Modules/posixmodule.c:1145: (Each undeclared identifier is reported only once ./Modules/posixmodule.c:1145: for each function it appears in.) make: *** [Modules/posixmodule.o] Fehler 1 160.490u 10.370s 3:09.17 90.3% 0+0k 0+0io 70442pf+0w yetix@/usr/home/ajung/new/Python-2.2a1(318)% make gcc -g -O3 -Wall -Wstrict-prototypes -Dss_family=__ss_family -Dss_len=__ss_len -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function `posix_nice': ./Modules/posixmodule.c:1145: warning: implicit declaration of function `getpriority' ./Modules/posixmodule.c:1145: `PRIO_PROCESS' undeclared (first use in this function) ./Modules/posixmodule.c:1145: (Each undeclared identifier is reported only once ./Modules/posixmodule.c:1145: for each function it appears in.) make: *** [Modules/posixmodule.o] Fehler 1 Env: gcc 2.95.3, Linux 2.4.5 i386 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443042&group_id=5470 From noreply@sourceforge.net Fri Jul 20 12:35:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 04:35:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-443042 ] 2.2.0a1: unable to build posixmodule (PRIO_PROCESS undeclard Message-ID: Bugs item #443042, was opened at 2001-07-20 04:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443042&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) >Summary: 2.2.0a1: unable to build posixmodule (PRIO_PROCESS undeclard Initial Comment: gcc -g -O3 -Wall -Wstrict-prototypes -Dss_family=__ss_family -Dss_len=__ss_len -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function `posix_nice': ./Modules/posixmodule.c:1145: warning: implicit declaration of function `getpriority' ./Modules/posixmodule.c:1145: `PRIO_PROCESS' undeclared (first use in this function) ./Modules/posixmodule.c:1145: (Each undeclared identifier is reported only once ./Modules/posixmodule.c:1145: for each function it appears in.) make: *** [Modules/posixmodule.o] Fehler 1 160.490u 10.370s 3:09.17 90.3% 0+0k 0+0io 70442pf+0w yetix@/usr/home/ajung/new/Python-2.2a1(318)% make gcc -g -O3 -Wall -Wstrict-prototypes -Dss_family=__ss_family -Dss_len=__ss_len -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function `posix_nice': ./Modules/posixmodule.c:1145: warning: implicit declaration of function `getpriority' ./Modules/posixmodule.c:1145: `PRIO_PROCESS' undeclared (first use in this function) ./Modules/posixmodule.c:1145: (Each undeclared identifier is reported only once ./Modules/posixmodule.c:1145: for each function it appears in.) make: *** [Modules/posixmodule.o] Fehler 1 Env: gcc 2.95.3, Linux 2.4.5 i386 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443042&group_id=5470 From noreply@sourceforge.net Fri Jul 20 15:20:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 07:20:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-443042 ] 2.2.0a1: unable to build posixmodule (PRIO_PROCESS undeclard Message-ID: Bugs item #443042, was opened at 2001-07-20 04:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443042&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) >Assigned to: A.M. Kuchling (akuchling) Summary: 2.2.0a1: unable to build posixmodule (PRIO_PROCESS undeclard Initial Comment: gcc -g -O3 -Wall -Wstrict-prototypes -Dss_family=__ss_family -Dss_len=__ss_len -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function `posix_nice': ./Modules/posixmodule.c:1145: warning: implicit declaration of function `getpriority' ./Modules/posixmodule.c:1145: `PRIO_PROCESS' undeclared (first use in this function) ./Modules/posixmodule.c:1145: (Each undeclared identifier is reported only once ./Modules/posixmodule.c:1145: for each function it appears in.) make: *** [Modules/posixmodule.o] Fehler 1 160.490u 10.370s 3:09.17 90.3% 0+0k 0+0io 70442pf+0w yetix@/usr/home/ajung/new/Python-2.2a1(318)% make gcc -g -O3 -Wall -Wstrict-prototypes -Dss_family=__ss_family -Dss_len=__ss_len -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function `posix_nice': ./Modules/posixmodule.c:1145: warning: implicit declaration of function `getpriority' ./Modules/posixmodule.c:1145: `PRIO_PROCESS' undeclared (first use in this function) ./Modules/posixmodule.c:1145: (Each undeclared identifier is reported only once ./Modules/posixmodule.c:1145: for each function it appears in.) make: *** [Modules/posixmodule.o] Fehler 1 Env: gcc 2.95.3, Linux 2.4.5 i386 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443042&group_id=5470 From noreply@sourceforge.net Fri Jul 20 15:33:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 07:33:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-443042 ] 2.2.0a1: unable to build posixmodule (PRIO_PROCESS undeclard Message-ID: Bugs item #443042, was opened at 2001-07-20 04:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443042&group_id=5470 >Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) >Assigned to: Thomas Wouters (twouters) Summary: 2.2.0a1: unable to build posixmodule (PRIO_PROCESS undeclard Initial Comment: gcc -g -O3 -Wall -Wstrict-prototypes -Dss_family=__ss_family -Dss_len=__ss_len -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function `posix_nice': ./Modules/posixmodule.c:1145: warning: implicit declaration of function `getpriority' ./Modules/posixmodule.c:1145: `PRIO_PROCESS' undeclared (first use in this function) ./Modules/posixmodule.c:1145: (Each undeclared identifier is reported only once ./Modules/posixmodule.c:1145: for each function it appears in.) make: *** [Modules/posixmodule.o] Fehler 1 160.490u 10.370s 3:09.17 90.3% 0+0k 0+0io 70442pf+0w yetix@/usr/home/ajung/new/Python-2.2a1(318)% make gcc -g -O3 -Wall -Wstrict-prototypes -Dss_family=__ss_family -Dss_len=__ss_len -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function `posix_nice': ./Modules/posixmodule.c:1145: warning: implicit declaration of function `getpriority' ./Modules/posixmodule.c:1145: `PRIO_PROCESS' undeclared (first use in this function) ./Modules/posixmodule.c:1145: (Each undeclared identifier is reported only once ./Modules/posixmodule.c:1145: for each function it appears in.) make: *** [Modules/posixmodule.o] Fehler 1 Env: gcc 2.95.3, Linux 2.4.5 i386 ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-07-20 07:33 Message: Logged In: YES user_id=11375 The version of glibc is probably also relevant. Reassigning to Thomas Wouters, as this looks related to the recent nice/getpriority changes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443042&group_id=5470 From noreply@sourceforge.net Fri Jul 20 16:04:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 08:04:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-442983 ] site.py rev 1.28 broke addsitedir() Message-ID: Bugs item #442983, was opened at 2001-07-19 23:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442983&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: Guido van Rossum (gvanrossum) Summary: site.py rev 1.28 broke addsitedir() Initial Comment: addsitedir() was changed to refer to global dirs_in_sys_path, but that global got explictly del'ed on line 152 too, so it doesn't exist when addsitedir() is called. Report from c.l.py follows: """ From: David Konerding Sent: Friday, July 20, 2001 1:56 AM To: python-list@python.org Subject: python 2.1.1 trouble with addsitedir Hi, I am checking my application's compatibility wiht 2.1.1 and I've run into a snag. We use "site.addsitedir" to add a directory to the loading path. As an example, the following works just fine on Python- 2.1: [dek@tolkien dek]$ python Python 2.1 (#2, Jul 19 2001, 20:48:59) [GCC 2.95.3 20010315 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import site >>> site.addsitedir("/tmp") >>> but running it with 2.1.1 gives the following: [dek@tolkien Python-2.1.1c1] $ /var/tmp/python/bin/python Python 2.1.1c1 (#1, Jul 19 2001, 22:49:25) [GCC 2.95.3 20010315 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import site >>> site.addsitedir("/tmp") Traceback (most recent call last): File "", line 1, in ? File "/var/tmp/python/lib/python2.1/site.py", line 100, in addsitedir if not dirs_in_sys_path.has_key(sitedircase): NameError: global name 'dirs_in_sys_path' is not defined """ ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 08:04 Message: Logged In: YES user_id=6380 I've fixed this by removing the 'del dirs_in_sys_path' line, both in 2.1.1 and in 2.2 (on the trunk). This fix will make it into the 2.1.1 release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442983&group_id=5470 From noreply@sourceforge.net Fri Jul 20 16:12:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 08:12:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-442983 ] site.py rev 1.28 broke addsitedir() Message-ID: Bugs item #442983, was opened at 2001-07-19 23:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442983&group_id=5470 Category: Python Library Group: None >Status: Open Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Guido van Rossum (gvanrossum) Summary: site.py rev 1.28 broke addsitedir() Initial Comment: addsitedir() was changed to refer to global dirs_in_sys_path, but that global got explictly del'ed on line 152 too, so it doesn't exist when addsitedir() is called. Report from c.l.py follows: """ From: David Konerding Sent: Friday, July 20, 2001 1:56 AM To: python-list@python.org Subject: python 2.1.1 trouble with addsitedir Hi, I am checking my application's compatibility wiht 2.1.1 and I've run into a snag. We use "site.addsitedir" to add a directory to the loading path. As an example, the following works just fine on Python- 2.1: [dek@tolkien dek]$ python Python 2.1 (#2, Jul 19 2001, 20:48:59) [GCC 2.95.3 20010315 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import site >>> site.addsitedir("/tmp") >>> but running it with 2.1.1 gives the following: [dek@tolkien Python-2.1.1c1] $ /var/tmp/python/bin/python Python 2.1.1c1 (#1, Jul 19 2001, 22:49:25) [GCC 2.95.3 20010315 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import site >>> site.addsitedir("/tmp") Traceback (most recent call last): File "", line 1, in ? File "/var/tmp/python/lib/python2.1/site.py", line 100, in addsitedir if not dirs_in_sys_path.has_key(sitedircase): NameError: global name 'dirs_in_sys_path' is not defined """ ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-20 08:12 Message: Logged In: YES user_id=3066 I don't think that's the right fix. (In fact, I was about to check in the right fix, and encountered a conflict with yours -- the lack of reasonably quick email through digicool.com is a problem.) Specifically, just letting the dirs_in_sys_path value sit around assumes that the only use code which manipulates sys.path uses the helpers in site.py, which is a bad assumption given that these are undocumented. It is better to reset the dictionary to None and force it to be rebuilt for external calls. This way it doesn't break when other modules manipulate sys.path. Re-opening pending discussion -- keep it in the tracker so we can all see it! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 08:04 Message: Logged In: YES user_id=6380 I've fixed this by removing the 'del dirs_in_sys_path' line, both in 2.1.1 and in 2.2 (on the trunk). This fix will make it into the 2.1.1 release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442983&group_id=5470 From noreply@sourceforge.net Fri Jul 20 16:33:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 08:33:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-442526 ] lang ref: Unicode literals undocumented Message-ID: Bugs item #442526, was opened at 2001-07-18 11:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442526&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 6 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: lang ref: Unicode literals undocumented Initial Comment: I'm not really sure who *should* be writing the section on Unicode literals, but it needs to be done sooner rather than later. This is section 2.4.3 in the language reference, "Unicode literals," in Doc/ref/ref2.tex. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-20 08:33 Message: Logged In: YES user_id=3066 OK, the "String literals" section already takes care of most of the discussion of both raw and Unicode strings, but the grammar productions don't accomodate any use of prefixes for strings. That needs to be added. The unnecessary section 2.4.3 is removed in Doc/ref/ref2.tex revision 1.28. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442526&group_id=5470 From noreply@sourceforge.net Fri Jul 20 17:13:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 09:13:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-443120 ] denial-of-service attack to cgi.py Message-ID: Bugs item #443120, was opened at 2001-07-20 09:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443120&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: denial-of-service attack to cgi.py Initial Comment: I got this in the mail: """ Subject: Bug in cgi.py, denial-of-service possible From: Richard Jones To: guido@python.org, support@digicool.com Date: Fri, 20 Jul 2001 17:43:15 +1000 The inner workings of cgi.py are still a mystery to me, so I can't offer a patch. Sorry. The following code will effect a denial-of-service against any server running cgi.py (and hence Zope). import httplib params = '\n'*10 h = httplib.HTTP('localhost', 8080) h.putrequest('POST', '/') h.putheader('Content-type', 'multipart/form-data') h.putheader('Content-length', str(len(params))) h.endheaders() h.send(params) The key here is the missing boundary from the content-type header. From my observation, it seems that cgi.py defaults the boundary to "" which means that it matches boundaries without progressing through the input - creating new FieldStorage instances for each match. The result is all available RAM gobbled up eventually. I recommend testing this on a system on which you can easily kill the server process. Richard -- Richard Jones richard@bizarsoftware.com.au Senior Software Developer, Bizar Software (www.bizarsoftware.com.au) """ ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443120&group_id=5470 From noreply@sourceforge.net Fri Jul 20 17:15:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 09:15:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-443042 ] 2.2a1: unable to build posixmodule (PRIO_PROCESS undeclard Message-ID: Bugs item #443042, was opened at 2001-07-20 04:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443042&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Thomas Wouters (twouters) >Summary: 2.2a1: unable to build posixmodule (PRIO_PROCESS undeclard Initial Comment: gcc -g -O3 -Wall -Wstrict-prototypes -Dss_family=__ss_family -Dss_len=__ss_len -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function `posix_nice': ./Modules/posixmodule.c:1145: warning: implicit declaration of function `getpriority' ./Modules/posixmodule.c:1145: `PRIO_PROCESS' undeclared (first use in this function) ./Modules/posixmodule.c:1145: (Each undeclared identifier is reported only once ./Modules/posixmodule.c:1145: for each function it appears in.) make: *** [Modules/posixmodule.o] Fehler 1 160.490u 10.370s 3:09.17 90.3% 0+0k 0+0io 70442pf+0w yetix@/usr/home/ajung/new/Python-2.2a1(318)% make gcc -g -O3 -Wall -Wstrict-prototypes -Dss_family=__ss_family -Dss_len=__ss_len -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function `posix_nice': ./Modules/posixmodule.c:1145: warning: implicit declaration of function `getpriority' ./Modules/posixmodule.c:1145: `PRIO_PROCESS' undeclared (first use in this function) ./Modules/posixmodule.c:1145: (Each undeclared identifier is reported only once ./Modules/posixmodule.c:1145: for each function it appears in.) make: *** [Modules/posixmodule.o] Fehler 1 Env: gcc 2.95.3, Linux 2.4.5 i386 ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-07-20 07:33 Message: Logged In: YES user_id=11375 The version of glibc is probably also relevant. Reassigning to Thomas Wouters, as this looks related to the recent nice/getpriority changes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443042&group_id=5470 From noreply@sourceforge.net Fri Jul 20 17:17:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 09:17:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-443005 ] 2.2a1: crash via posix_do_stat Message-ID: Bugs item #443005, was opened at 2001-07-20 01:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443005&group_id=5470 Category: Python Interpreter Core >Group: Platform-specific Status: Open >Resolution: Works For Me >Priority: 3 Submitted By: Uwe Zessin (zessin_5) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2a1: crash via posix_do_stat Initial Comment: I've done a port to OpenVMS. I get a crash during Python initialization (import of SITE.PY). A work-around for me is to replace the format-string for posix_do_stat() of "et" with "s". Here is the traceback. I have removed the line numbers, because they apply to the compiler listings. $ python %SYSTEM-F-ACCVIO, access violation, ... %TRACE-F-TRACEBACK, symbolic stack dump follows image module routine PYTHON GETARGS convertsimple PYTHON GETARGS convertitem PYTHON GETARGS vgetargs1 PYTHON GETARGS PyArg_ParseTuple PYTHON POSIXMODULE posix_do_stat PYTHON POSIXMODULE posix_stat PYTHON CEVAL call_cfunction PYTHON CEVAL eval_frame PYTHON CEVAL PyEval_EvalCodeEx PYTHON CEVAL fast_function PYTHON CEVAL eval_frame PYTHON CEVAL PyEval_EvalCodeEx PYTHON CEVAL PyEval_EvalCode PYTHON IMPORT PyImport_ExecCodeModuleEx PYTHON IMPORT load_source_module PYTHON IMPORT load_module PYTHON IMPORT import_submodule PYTHON IMPORT load_next PYTHON IMPORT import_module_ex PYTHON IMPORT PyImport_ImportModuleEx PYTHON BLTINMODULE builtin___import__ PYTHON METHODOBJECT meth_call PYTHON ABSTRACT PyObject_Call PYTHON CEVAL PyEval_CallObjectWithKeywords PYTHON ABSTRACT PyObject_CallObject PYTHON ABSTRACT PyObject_CallFunction PYTHON IMPORT PyImport_Import PYTHON IMPORT PyImport_ImportModule PYTHON PYTHONRUN initsite PYTHON PYTHONRUN Py_Initialize PYTHON MAIN Py_Main PYTHON PYTHON main PYTHON PYTHON __main And here is the failing code in GETARGS.C: if ((int)strlen(PyString_AS_STRING(s)) != size) return converterr( "(encoded string without NULL b... arg, msgbuf); -> *buffer = PyMem_NEW(char, size + 1); if (*buffer == NULL) { Py_DECREF(s); return converterr("(memory error)", arg, msgbuf); } ----- I'm sorry, but I can't debug that any better. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 09:17 Message: Logged In: YES user_id=6380 I'm sorry, but I can't debug that any better either. There's nothing suspicious about the indicated line. Lowering the priority. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443005&group_id=5470 From noreply@sourceforge.net Fri Jul 20 17:32:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 09:32:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-442998 ] 2.2a1: compiler warnings Message-ID: Bugs item #442998, was opened at 2001-07-20 01:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442998&group_id=5470 Category: Python Interpreter Core >Group: Platform-specific Status: Open >Resolution: Wont Fix >Priority: 3 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Guido van Rossum (gvanrossum) Summary: 2.2a1: compiler warnings Initial Comment: I've done a port to OpenVMS. Here are some compiler warnings: ----- }; ^ %CC-I-TRAILCOMMA, Trailing comma found in enumerator list. at line number 482 in file CEVAL.C ----- There are lots of warnings in TYPEOBJECT.C like: RICHCMP_WRAPPER(lt, Py_LT); ..........................^ %CC-I-EXTRASEMI, Extraneous semicolon. at line number 1707 in file TYPEOBJECT.C RICHCMP_WRAPPER(le, Py_LE); ..........................^ %CC-I-EXTRASEMI, Extraneous semicolon. at line number 1708 in file TYPEOBJECT.C and: SLOT1(sq_concat, add, PyObject *, O); ....................................^ %CC-I-EXTRASEMI, Extraneous semicolon. at line number 1956 in file TYPEOBJECT.C SLOT1(sq_repeat, mul, int, i); .............................^ %CC-I-EXTRASEMI, Extraneous semicolon. at line number 1957 in file TYPEOBJECT.C and: ADD(sq->sq_length, tab_len); ................^ %CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer value "sq->sq_length" is "function (pointer to struct _object) returning int", which is not compatible with "void". at line number 1842 in file TYPEOBJECT.C ADD(sq->sq_concat, tab_add); ................^ %CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer value "sq->sq_concat" is "function (pointer to struct _object, pointer to struct _object) returning pointer to struct _object", which is not compatible with "void". at line number 1843 in file TYPEOBJECT.C add_staticmethodwrappers(type, tab_new, type->tp_new); ....................................................... .^ %CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer value "type->tp_new" is "function (pointer to struct _typeobject, pointer to struct _object, pointer to struct _object) returning pointer to struct _object",which is not compatible with "void". at line number 1917 in file TYPEOBJECT.C There are 100+ warnings which I don't include all, OK? ----- 4 times messages like this in UNICODEOBJECT.C: *p++ = hexdigit[(ch >> 28) & 0xf]; .............................^ %CC-I-RIGHTSHIFTOVR, In this statement, the right shift count "28" is greater than or equal to the size of the unpromoted operand "ch". at line number 1448 in file UNICODEOBJECT.C ----- If you need specific values from my CONFIG.H, please let me know. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 09:32 Message: Logged In: YES user_id=6380 I'm sorry, but I don't want to fix most of these. Trailing commas in lists are legal C, and esthetics and easy extensibility tell me that it's better to keep them. The extraneous semicolons after RICHCMP_WRAPPER() are also legal in C, and I need them so the Emacs auto-indent mode doesn't screw up. I will add (void *) casts to the function arguments in the ADD() macro and the add_staticmethodwrappers() call. I think I can add an #ifdef to the Unicode fragment. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442998&group_id=5470 From noreply@sourceforge.net Fri Jul 20 18:08:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 10:08:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-443042 ] 2.2a1: unable to build posixmodule (PRIO_PROCESS undeclard Message-ID: Bugs item #443042, was opened at 2001-07-20 04:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443042&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Thomas Wouters (twouters) Summary: 2.2a1: unable to build posixmodule (PRIO_PROCESS undeclard Initial Comment: gcc -g -O3 -Wall -Wstrict-prototypes -Dss_family=__ss_family -Dss_len=__ss_len -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function `posix_nice': ./Modules/posixmodule.c:1145: warning: implicit declaration of function `getpriority' ./Modules/posixmodule.c:1145: `PRIO_PROCESS' undeclared (first use in this function) ./Modules/posixmodule.c:1145: (Each undeclared identifier is reported only once ./Modules/posixmodule.c:1145: for each function it appears in.) make: *** [Modules/posixmodule.o] Fehler 1 160.490u 10.370s 3:09.17 90.3% 0+0k 0+0io 70442pf+0w yetix@/usr/home/ajung/new/Python-2.2a1(318)% make gcc -g -O3 -Wall -Wstrict-prototypes -Dss_family=__ss_family -Dss_len=__ss_len -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function `posix_nice': ./Modules/posixmodule.c:1145: warning: implicit declaration of function `getpriority' ./Modules/posixmodule.c:1145: `PRIO_PROCESS' undeclared (first use in this function) ./Modules/posixmodule.c:1145: (Each undeclared identifier is reported only once ./Modules/posixmodule.c:1145: for each function it appears in.) make: *** [Modules/posixmodule.o] Fehler 1 Env: gcc 2.95.3, Linux 2.4.5 i386 ---------------------------------------------------------------------- >Comment By: Andreas Jung (ajung) Date: 2001-07-20 10:08 Message: Logged In: YES user_id=11084 My system uses glibc 2.1.2. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-07-20 07:33 Message: Logged In: YES user_id=11375 The version of glibc is probably also relevant. Reassigning to Thomas Wouters, as this looks related to the recent nice/getpriority changes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443042&group_id=5470 From noreply@sourceforge.net Fri Jul 20 20:09:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 12:09:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-226706 ] many std modules assume string.letters is [a-zA-Z] Message-ID: Bugs item #226706, was opened at 2000-12-23 06:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=226706&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: many std modules assume string.letters is [a-zA-Z] Initial Comment: there are many modules in the standard library that use string.letters to mean A-Za-z, but that assumption is incorrect when locales are in use. also the readline library seems to cause the locale to be set according to the current environment variables, even if i don't call locale.*: % python2.0 -c 'import string; print string.letters' abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ % python2.0 Python 2.0 (#3, Oct 19 2000, 01:42:41) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Type "copyright", "credits" or "license" for more information. >>> print string.letters abcdefghijklmnopqrstuvwxyzµßàáâãäåæçèéêëìíîïðñòóôõöøùúûüýþÿABCDEFGHIJKLMNOPQRSTUVWXYZÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝÞ >>> here's what grep says on the standard library. most of these uses seem incorrect to me: % grep string.letters **/*.py Cookie.py:_LegalChars = string.letters + string.digits + "!#$%&'*+-.^_`|~"cmd.py:IDENTCHARS = string.letters + string.digits + '_' dospath.py: varchars = string.letters + string.digits + '_-' lib-old/codehack.py:identchars = string.letters + string.digits + '_' # Identifier characters ntpath.py: varchars = string.letters + string.digits + '_-' nturl2path.py: if len(comp) != 2 or comp[0][-1] not in string.letters: pipes.py:_safechars = string.letters + string.digits + '!@%_-+=:,./' # Safe unquoted pre.py: alphanum=string.letters+'_'+string.digits tokenize.py: namechars, numchars = string.letters + '_', string.digits urlparse.py:scheme_chars = string.letters + string.digits + '+-.' ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-20 12:09 Message: Logged In: YES user_id=3066 Added constants ascii_letters, ascii_lowercase, ascii_uppercase to the string module in revision 1.60. Modified existing uses of string.letters in the standard library, demos, and tool scripts. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-18 19:33 Message: Will look into this again after alpha1 is out -- no time before that. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-09 06:46 Message: I agree that the string module should be extended with additional variables ascii_letters (and ascii_lowercase and ascii_uppercase and ascii_whitespace). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-01-01 10:08 Message: The comment about readline calling setlocale() is unfortunately true (and causes some very subtle bugs in user code...). About the addition of more constants: I would rather like to see a database for these things which uses function calls much like the Unicode database (unicodedata). Since locales sometime matter, I think there should be an option to the functions which enables locale support (much like as for REs) on request. Default should be no locale support, since this is what most code expects anyway. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2000-12-30 19:36 Message: The set of all letters, though, will be commonly used, though maybe we need an alphanumeric constant for A-Za-z0-9 + underscore. I like the .ascii_letters suggestion. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-12-30 18:26 Message: Andrew, does it make sense to introduce new constants in string for this? It seems that each instance is referring to slightly different specifications or standards (documented or not), so perhaps the constants should be defined locally within each of the modules. This also avoids unnecessary dependencies. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2000-12-26 12:18 Message: string.ascii_letters etc is more precise than alphabet, imho. -- erno@iki.fi ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2000-12-26 08:15 Message: The docs for the string module say that, for example, string.lowercase is " A string containing all the characters that are considered lowercase letters." This implies that the strings are locale-aware; code that uses string.lowercase to mean only a-z is therefore in error. (.digits is not locale-aware.) Solution: I'd suggest adding new, not locale-aware, constants. string.alphabet, string.lower_alphabet, string.upper_alphabet, maybe? Code should then be changed to use these new constants. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=226706&group_id=5470 From noreply@sourceforge.net Fri Jul 20 21:33:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 13:33:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-442813 ] 2.2a1: list.__getitem__ and index<0 Message-ID: Bugs item #442813, was opened at 2001-07-19 10:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442813&group_id=5470 Category: type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: 2.2a1: list.__getitem__ and index<0 Initial Comment: list.__getitem__ doesn't handle negative indizes when called directly: >>> x = [1] >>> list.__getitem__(x, -1) Traceback (most recent call last): File "", line 1, in ? IndexError: list index out of range ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 13:33 Message: Logged In: YES user_id=6380 This is deeper than it seems. The list object never interprets negative indices -- that's all done under the covers of the implementation in PySequence_GetItem(). So list.__getitem__(), which is a very thin wrapper around the list object's tp_as_sequence->sq_item function (list_item in listobject.c), also doesn't interpret negative indices. But because __getitem__ is ambiguous (it can be a sequence or a mapping operation, with slightly different semantics), when you define a subclass that implements __getitem__, and you pass an instance of that subclass a negative index, the special handling of negative indices is skipped, so a[-1] ends up calling a.__getitem__(-1). This is not good. I'll have to think about a way out of this dilemma. Moving the negative index handling into the objects is an option, but this might break with 3rd party sequence objects. Doing the negative index handling twice (once in PySequence_GetItem() and again in the object) is bad, because it changes the semantics of very large negative indices. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442813&group_id=5470 From noreply@sourceforge.net Sat Jul 21 00:38:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 16:38:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-443042 ] 2.2a1: unable to build posixmodule (PRIO_PROCESS undeclard Message-ID: Bugs item #443042, was opened at 2001-07-20 04:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443042&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Thomas Wouters (twouters) Summary: 2.2a1: unable to build posixmodule (PRIO_PROCESS undeclard Initial Comment: gcc -g -O3 -Wall -Wstrict-prototypes -Dss_family=__ss_family -Dss_len=__ss_len -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function `posix_nice': ./Modules/posixmodule.c:1145: warning: implicit declaration of function `getpriority' ./Modules/posixmodule.c:1145: `PRIO_PROCESS' undeclared (first use in this function) ./Modules/posixmodule.c:1145: (Each undeclared identifier is reported only once ./Modules/posixmodule.c:1145: for each function it appears in.) make: *** [Modules/posixmodule.o] Fehler 1 160.490u 10.370s 3:09.17 90.3% 0+0k 0+0io 70442pf+0w yetix@/usr/home/ajung/new/Python-2.2a1(318)% make gcc -g -O3 -Wall -Wstrict-prototypes -Dss_family=__ss_family -Dss_len=__ss_len -I. -I./Include -DHAVE_CONFIG_H -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function `posix_nice': ./Modules/posixmodule.c:1145: warning: implicit declaration of function `getpriority' ./Modules/posixmodule.c:1145: `PRIO_PROCESS' undeclared (first use in this function) ./Modules/posixmodule.c:1145: (Each undeclared identifier is reported only once ./Modules/posixmodule.c:1145: for each function it appears in.) make: *** [Modules/posixmodule.o] Fehler 1 Env: gcc 2.95.3, Linux 2.4.5 i386 ---------------------------------------------------------------------- >Comment By: Andreas Jung (ajung) Date: 2001-07-20 16:38 Message: Logged In: YES user_id=11084 Compilation works fine after removing HAVE_BROKEN_NICE from config.h - seems to be broken :-) Andreas ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2001-07-20 10:08 Message: Logged In: YES user_id=11084 My system uses glibc 2.1.2. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-07-20 07:33 Message: Logged In: YES user_id=11375 The version of glibc is probably also relevant. Reassigning to Thomas Wouters, as this looks related to the recent nice/getpriority changes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443042&group_id=5470 From noreply@sourceforge.net Sat Jul 21 01:55:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 17:55:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-443238 ] Perm. in ../lib/python2.2/lib-dynload Message-ID: Bugs item #443238, was opened at 2001-07-20 17:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443238&group_id=5470 Category: Installation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: Perm. in ../lib/python2.2/lib-dynload Initial Comment: "make install" does not set the permissions for all *.so to a+r. Instead u+rwx is set. All other files in the lib/python2.2 folder are fine. Env. Linux 2.4.5 i386 Andreas ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443238&group_id=5470 From noreply@sourceforge.net Sat Jul 21 02:06:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Jul 2001 18:06:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-443239 ] Python 2.2a1 & Boost.Python Message-ID: Bugs item #443239, was opened at 2001-07-20 18:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443239&group_id=5470 Category: type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Guido van Rossum (gvanrossum) Summary: Python 2.2a1 & Boost.Python Initial Comment: Boost.Python is a C++ library for exposing C++ classes to Python: http://www.boost.org/libs/python/doc/index.html Python's metaclass feature is used to provide objects which look almost exactly like regular Python classes: http://www.boost.org/libs/python/doc/extending.html I have compiled the Boost.Python library using Python 2.2a1 under Linux without getting any compile-time error messages. However, with versions earlier than 2.2, we were able to derive extension classes from a mixture of built-in classes and extension classes, /even if the built-in class was the first listed base/, but that no longer works: Python 2.2a1 (#1, Jul 18 2001, 16:24:59) [GCC 2.95.2 19991024 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from boost_python_test import Bar >>> >>> class RealPythonClass: ... def real_python_method(self): ... print 'RealPythonClass.real_python_method ()' ... >>> class MISubclass2(RealPythonClass, Bar): ... def new_method(self): ... print 'MISubclass2.new_method()' ... Traceback (most recent call last): File "", line 1, in ? TypeError: PyClass_New: base must be a class >>> This example works if the extension class appears first: >>> class MISubclass2(Bar, RealPythonClass): It is somewhat important that built-in Python classes may appear first in the list of bases. Would it be possible to support this in Python 2.2? Thanks! Ralf ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443239&group_id=5470 From noreply@sourceforge.net Sun Jul 22 02:58:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 21 Jul 2001 18:58:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-443464 ] Import Numeric RandomArray on 2.1.1 Message-ID: Bugs item #443464, was opened at 2001-07-21 18:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443464&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Import Numeric RandomArray on 2.1.1 Initial Comment: Mandrake 7.2 system, python2.1.1 builds okay, but when I import RandomArray I get the following: >>> import RandomArray Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/site-packages/Numeric/RandomArray.py", line 3, in ? import LinearAlgebra File "/usr/lib/python2.1/site-packages/Numeric/LinearAlgebra.py", line 8, in ? import lapack_lite ImportError: /usr/lib/python2.1/site-packages/Numeric/lapack_lite.so: undefined symbol: dgesvd_ I've notified the Numeric team as well. In relation to another bug mentioned here, I have no trouble importing Numeric-20 on my system. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443464&group_id=5470 From noreply@sourceforge.net Sun Jul 22 08:47:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Jul 2001 00:47:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-443490 ] 2.2 Install on Linux/Mod Install Error Message-ID: Bugs item #443490, was opened at 2001-07-22 00:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443490&group_id=5470 Category: Installation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2 Install on Linux/Mod Install Error Initial Comment: *Start* copying build/scripts/pydoc -> /usr/local/bin changing mode of /usr/local/bin/pydoc to 100755 warning: install: modules installed to '/usr/local/lib/python2.1/lib-dynload/', which is not in Python's module search path (sys.path) -- you'll have to change the search path yourself *End* I do not know if this is a bug or not. Reinstalled many times with different ./configure options for Linux, and always gives the same error. If I am wrong and it is only an error, I appologize. *I'm New* Please notify me via email of what I need to do to correct this issue is it is an error. :?/ ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443490&group_id=5470 From noreply@sourceforge.net Sun Jul 22 08:52:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Jul 2001 00:52:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-443490 ] 2.2 Install on Linux/Mod Install Error Message-ID: Bugs item #443490, was opened at 2001-07-22 00:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443490&group_id=5470 Category: Installation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2 Install on Linux/Mod Install Error Initial Comment: *Start* copying build/scripts/pydoc -> /usr/local/bin changing mode of /usr/local/bin/pydoc to 100755 warning: install: modules installed to '/usr/local/lib/python2.1/lib-dynload/', which is not in Python's module search path (sys.path) -- you'll have to change the search path yourself *End* I do not know if this is a bug or not. Reinstalled many times with different ./configure options for Linux, and always gives the same error. If I am wrong and it is only an error, I appologize. *I'm New* Please notify me via email of what I need to do to correct this issue is it is an error. :?/ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-22 00:52 Message: Logged In: NO Oops... Env: Linux 2.2.14 reginaravers@accesscomm.ca is my email address. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443490&group_id=5470 From noreply@sourceforge.net Sun Jul 22 08:54:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Jul 2001 00:54:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-443490 ] 2.2 Install on Linux/Mod Install Error Message-ID: Bugs item #443490, was opened at 2001-07-22 00:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443490&group_id=5470 Category: Installation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2 Install on Linux/Mod Install Error Initial Comment: *Start* copying build/scripts/pydoc -> /usr/local/bin changing mode of /usr/local/bin/pydoc to 100755 warning: install: modules installed to '/usr/local/lib/python2.1/lib-dynload/', which is not in Python's module search path (sys.path) -- you'll have to change the search path yourself *End* I do not know if this is a bug or not. Reinstalled many times with different ./configure options for Linux, and always gives the same error. If I am wrong and it is only an error, I appologize. *I'm New* Please notify me via email of what I need to do to correct this issue is it is an error. :?/ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-22 00:54 Message: Logged In: NO Env: Linux 2.2.14 Email address is reginaravers@accesscomm.ca ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-22 00:52 Message: Logged In: NO Oops... Env: Linux 2.2.14 reginaravers@accesscomm.ca is my email address. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443490&group_id=5470 From noreply@sourceforge.net Sun Jul 22 09:08:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Jul 2001 01:08:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-443490 ] 2.2 Install on Linux/Mod Install Error Message-ID: Bugs item #443490, was opened at 2001-07-22 00:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443490&group_id=5470 Category: Installation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2 Install on Linux/Mod Install Error Initial Comment: *Start* copying build/scripts/pydoc -> /usr/local/bin changing mode of /usr/local/bin/pydoc to 100755 warning: install: modules installed to '/usr/local/lib/python2.1/lib-dynload/', which is not in Python's module search path (sys.path) -- you'll have to change the search path yourself *End* I do not know if this is a bug or not. Reinstalled many times with different ./configure options for Linux, and always gives the same error. If I am wrong and it is only an error, I appologize. *I'm New* Please notify me via email of what I need to do to correct this issue is it is an error. :?/ ---------------------------------------------------------------------- Comment By: Allan Digiby (just_gnu_it) Date: 2001-07-22 01:08 Message: Logged In: YES user_id=277768 [quote]*I'm New* [/quote] Below is proof enough of his claim. LOL :p ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-22 00:54 Message: Logged In: NO Env: Linux 2.2.14 Email address is reginaravers@accesscomm.ca ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-22 00:52 Message: Logged In: NO Oops... Env: Linux 2.2.14 reginaravers@accesscomm.ca is my email address. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443490&group_id=5470 From noreply@sourceforge.net Sun Jul 22 09:10:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Jul 2001 01:10:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-443238 ] Perm. in ../lib/python2.2/lib-dynload Message-ID: Bugs item #443238, was opened at 2001-07-20 17:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443238&group_id=5470 Category: Installation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: Perm. in ../lib/python2.2/lib-dynload Initial Comment: "make install" does not set the permissions for all *.so to a+r. Instead u+rwx is set. All other files in the lib/python2.2 folder are fine. Env. Linux 2.4.5 i386 Andreas ---------------------------------------------------------------------- Comment By: Allan Digiby (just_gnu_it) Date: 2001-07-22 01:10 Message: Logged In: YES user_id=277768 For a more detailed view, check out: 443490 || 2.2 Install on Linux/Mod Install Error ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443238&group_id=5470 From noreply@sourceforge.net Sun Jul 22 15:33:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Jul 2001 07:33:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-443490 ] 2.2 Install on Linux/Mod Install Error Message-ID: Bugs item #443490, was opened at 2001-07-22 00:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443490&group_id=5470 Category: Installation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: A.M. Kuchling (akuchling) Summary: 2.2 Install on Linux/Mod Install Error Initial Comment: *Start* copying build/scripts/pydoc -> /usr/local/bin changing mode of /usr/local/bin/pydoc to 100755 warning: install: modules installed to '/usr/local/lib/python2.1/lib-dynload/', which is not in Python's module search path (sys.path) -- you'll have to change the search path yourself *End* I do not know if this is a bug or not. Reinstalled many times with different ./configure options for Linux, and always gives the same error. If I am wrong and it is only an error, I appologize. *I'm New* Please notify me via email of what I need to do to correct this issue is it is an error. :?/ ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-22 07:33 Message: Logged In: YES user_id=6380 This is probably because there's already a Python installed on your system (most Linux installations come with Python 1.5.2). But the error message could be better. Andrew, do you know more about this? Help a fellow Canadian. :-) ---------------------------------------------------------------------- Comment By: Allan Digiby (just_gnu_it) Date: 2001-07-22 01:08 Message: Logged In: YES user_id=277768 [quote]*I'm New* [/quote] Below is proof enough of his claim. LOL :p ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-22 00:54 Message: Logged In: NO Env: Linux 2.2.14 Email address is reginaravers@accesscomm.ca ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-22 00:52 Message: Logged In: NO Oops... Env: Linux 2.2.14 reginaravers@accesscomm.ca is my email address. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443490&group_id=5470 From noreply@sourceforge.net Sun Jul 22 16:23:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Jul 2001 08:23:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-443490 ] 2.2 Install on Linux/Mod Install Error Message-ID: Bugs item #443490, was opened at 2001-07-22 00:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443490&group_id=5470 Category: Installation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: A.M. Kuchling (akuchling) Summary: 2.2 Install on Linux/Mod Install Error Initial Comment: *Start* copying build/scripts/pydoc -> /usr/local/bin changing mode of /usr/local/bin/pydoc to 100755 warning: install: modules installed to '/usr/local/lib/python2.1/lib-dynload/', which is not in Python's module search path (sys.path) -- you'll have to change the search path yourself *End* I do not know if this is a bug or not. Reinstalled many times with different ./configure options for Linux, and always gives the same error. If I am wrong and it is only an error, I appologize. *I'm New* Please notify me via email of what I need to do to correct this issue is it is an error. :?/ ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-22 08:23 Message: Logged In: YES user_id=6380 To just_gnu_it, or Allan Digiby: there was no need to be condescending. Wait till we laugh at your bug reports. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-22 07:33 Message: Logged In: YES user_id=6380 This is probably because there's already a Python installed on your system (most Linux installations come with Python 1.5.2). But the error message could be better. Andrew, do you know more about this? Help a fellow Canadian. :-) ---------------------------------------------------------------------- Comment By: Allan Digiby (just_gnu_it) Date: 2001-07-22 01:08 Message: Logged In: YES user_id=277768 [quote]*I'm New* [/quote] Below is proof enough of his claim. LOL :p ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-22 00:54 Message: Logged In: NO Env: Linux 2.2.14 Email address is reginaravers@accesscomm.ca ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-22 00:52 Message: Logged In: NO Oops... Env: Linux 2.2.14 reginaravers@accesscomm.ca is my email address. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443490&group_id=5470 From noreply@sourceforge.net Sun Jul 22 18:23:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Jul 2001 10:23:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-443559 ] creating exceptions is underdocumented Message-ID: Bugs item #443559, was opened at 2001-07-22 10:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443559&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: creating exceptions is underdocumented Initial Comment: It's not documented very well (maybe not at all?) how to create your own exceptions, what methods are available for overriding / extending, etc. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443559&group_id=5470 From noreply@sourceforge.net Sun Jul 22 21:22:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Jul 2001 13:22:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-443600 ] overload of the slicing operator Message-ID: Bugs item #443600, was opened at 2001-07-22 13:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443600&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Markus Daniel (spacy73) Assigned to: Nobody/Anonymous (nobody) Summary: overload of the slicing operator Initial Comment: It's impossible to overload the slicing operator to take two float-values. PythonWin 2.1 (#15, Apr 23 2001, 18:00:35) [MSC 32 bit (Intel)] on win32. >>> class a: ... def __getitem__(self, index): ... print repr(index) ... >>> >>> aa=a() >>> >>> aa[1.5] 1.5 >>> >>> aa[1.5:2.5] Traceback (most recent call last): File "", line 1, in ? TypeError: slice indices must be integers >>> >>> aa[1.5:2.5:3.5] slice(1.5, 2.5, 3.5) >>> ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443600&group_id=5470 From noreply@sourceforge.net Sun Jul 22 22:16:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Jul 2001 14:16:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-443614 ] enhancement for threading._Semaphore Message-ID: Bugs item #443614, was opened at 2001-07-22 14:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443614&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: enhancement for threading._Semaphore Initial Comment: The threading._Semaphore class subclasses threading._Verbose but takes no advantage of this, never calling self._note. In addition, it seems to me that most of the time it would be a bug if a semaphore is released more times than it is acquired. The attached patch adds to calls to self._note similar to those in threading._RLock adds a new instance variable, __initial_value, and adds an assert to _Semaphore.release to compare the current value of the semaphore with its initial value. If it is felt that the semantic change to the _Semaphore class caused by the addition of the assert statement would break code, I recommend that _Semaphore be subclassed with the release method overridden to include the assert check. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443614&group_id=5470 From noreply@sourceforge.net Mon Jul 23 02:48:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Jul 2001 18:48:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-443120 ] denial-of-service attack to cgi.py Message-ID: Bugs item #443120, was opened at 2001-07-20 09:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443120&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: denial-of-service attack to cgi.py Initial Comment: I got this in the mail: """ Subject: Bug in cgi.py, denial-of-service possible From: Richard Jones To: guido@python.org, support@digicool.com Date: Fri, 20 Jul 2001 17:43:15 +1000 The inner workings of cgi.py are still a mystery to me, so I can't offer a patch. Sorry. The following code will effect a denial-of-service against any server running cgi.py (and hence Zope). import httplib params = '\n'*10 h = httplib.HTTP('localhost', 8080) h.putrequest('POST', '/') h.putheader('Content-type', 'multipart/form-data') h.putheader('Content-length', str(len(params))) h.endheaders() h.send(params) The key here is the missing boundary from the content-type header. From my observation, it seems that cgi.py defaults the boundary to "" which means that it matches boundaries without progressing through the input - creating new FieldStorage instances for each match. The result is all available RAM gobbled up eventually. I recommend testing this on a system on which you can easily kill the server process. Richard -- Richard Jones richard@bizarsoftware.com.au Senior Software Developer, Bizar Software (www.bizarsoftware.com.au) """ ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-07-22 18:48 Message: Logged In: YES user_id=6405 This is a patch - it's against a patched cgi.py (I've applied the fix for "too many open files"). RFC 2046 requires a boundary argument for the multipart content types (http://www.ietf.org/rfc/rfc2046.txt, 5.1.1, second paragraph). This patch does fix the given exploit. *** /usr/lib/python2.1/cgi.py Tue Jul 10 14:29:37 2001 --- cgi.py Mon Jul 23 11:37:45 2001 *************** *** 514,519 **** --- 514,521 ---- if ctype == 'application/x-www-form-urlencoded': self.read_urlencoded() elif ctype[:10] == 'multipart/': + if not self.innerboundary: + raise ValueError, 'multipart message with no boundary' self.read_multi(environ, keep_blank_values, strict_parsing) else: self.read_single() ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443120&group_id=5470 From noreply@sourceforge.net Mon Jul 23 12:07:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 04:07:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-443762 ] dictionary type ignores argument list Message-ID: Bugs item #443762, was opened at 2001-07-23 04:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443762&group_id=5470 Category: type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Duncan Booth (duncanb) Assigned to: Guido van Rossum (gvanrossum) Summary: dictionary type ignores argument list Initial Comment: In 2.2a1 the dictionary type object completely ignores its argument list when constructing a new dictionary. It always returns an empty dictionary no matter what arguments are specified. Either: it should check that it has been called with no arguments. Or: it should take some arguments and do something useful with them. I would suggest that the following arguments would be useful: dictionary() should return a new empty dictionary. dictionary(d) where d is a dictionary should return a copy of the original dictionary. dictionary(k1=v1, k2=v2, k3=v3, ...) should return a dictionary with keys k1, k2, k3, ... and corresponding values. dictionary(kvlist) where kvlist is a list of key, value tuples should build a dictionary from the key value pairs (effectively this is the inverse of d.items ()). dictionary(kseq, vseq) should do the same as dictionary (zip(kseq, vseq)) i.e. create a dictionary initialised with corresponding elements from each list as key and value. Any other arguments to dictionary should be rejected. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443762&group_id=5470 From noreply@sourceforge.net Mon Jul 23 13:58:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 05:58:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-443783 ] Cygwin32 builds threads, but they hang Message-ID: Bugs item #443783, was opened at 2001-07-23 05:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443783&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Tim Peters (tim_one) Summary: Cygwin32 builds threads, but they hang Initial Comment: Recent cygwin32 install. recent descr-branch checkout. Windows 98 system. Python compiles with thread support. However, 'test_asynchat' and 'test_thread*' hang. Workaround: configure --without-threads ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443783&group_id=5470 From noreply@sourceforge.net Mon Jul 23 13:59:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 05:59:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-443784 ] test_poll hangs in cygwin Message-ID: Bugs item #443784, was opened at 2001-07-23 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443784&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Tim Peters (tim_one) Summary: test_poll hangs in cygwin Initial Comment: Fresh install of cygwin32. Fresh checkout of descr- branch. Windows 98. test_poll hangs. Output when running test_poll manually: Running poll test 1 This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/test/test_poll.py", line 171, in ? test_poll1() File "/usr/lib/python2.1/test/test_poll.py", line 65, in test_poll1 poll_unit_tests() File "/usr/lib/python2.1/test/test_poll.py", line 77, in poll_unit_tests r = p.poll() KeyboardInterrupt ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443784&group_id=5470 From noreply@sourceforge.net Mon Jul 23 14:49:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 06:49:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-443793 ] Subclassed dictionary gives SystemError Message-ID: Bugs item #443793, was opened at 2001-07-23 06:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443793&group_id=5470 Category: type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Duncan Booth (duncanb) Assigned to: Guido van Rossum (gvanrossum) Summary: Subclassed dictionary gives SystemError Initial Comment: The following code gives 'SystemError: NULL object passed to Py_BuildValue' when run on Python 2.2a1: --- begin --- class mydict(dictionary): def __setitem__(self, key, value): pass d = mydict() del d['b'] # This line raises SystemError. --- end --- ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443793&group_id=5470 From noreply@sourceforge.net Mon Jul 23 14:51:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 06:51:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-443793 ] Subclassed dictionary gives SystemError Message-ID: Bugs item #443793, was opened at 2001-07-23 06:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443793&group_id=5470 Category: type/class unification Group: Python 2.2 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Duncan Booth (duncanb) Assigned to: Guido van Rossum (gvanrossum) Summary: Subclassed dictionary gives SystemError Initial Comment: The following code gives 'SystemError: NULL object passed to Py_BuildValue' when run on Python 2.2a1: --- begin --- class mydict(dictionary): def __setitem__(self, key, value): pass d = mydict() del d['b'] # This line raises SystemError. --- end --- ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-23 06:51 Message: Logged In: YES user_id=6380 Thanks -- this is a known bug and fixed in CVS (check out the latest typeobject.c from the descr-branch). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443793&group_id=5470 From noreply@sourceforge.net Mon Jul 23 18:10:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 10:10:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-210648 ] performance-problem decoding quoted-printable (PR#340) Message-ID: Bugs item #210648, was opened at 2000-07-31 14:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210648&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: Invalid Priority: 4 Submitted By: Nobody/Anonymous (nobody) Assigned to: Barry Warsaw (bwarsaw) Summary: performance-problem decoding quoted-printable (PR#340) Initial Comment: Jitterbug-Id: 340 Submitted-By: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= Date: Fri, 26 May 2000 16:51:51 +0200 Version: None OS: None --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Problem on python 1.5.1 on linux 2.2.14aa6. Decoding quoted-printable files using mimetools.decode is really slow. The really strange thing is, that it appers to work a lot faster on smaller files! I put together a little test-program that reads blocks from a file, and decodes them individually. (The output will not be 100% correct. The point was just to test the performance). Results show the time it took to decode a 300k file with the diferent block-sizes: 1k: 6.28 s 3k: 6.59 s 10k: 8.57 s 30k: 30.45 s 100k: 127.82 s 300k: 221.67 s I looked in quopri.decode for clues about the problem, but could not find any. Is there something _very_ wrong with my reasoning, or is something wrong here? -- Ragnar Kjørstad --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="test.py" #!/usr/bin/python from mimetools import decode from StringIO import StringIO from sys import stdout, argv from string import atoi bsize=atoi(argv[1]) output=StringIO() f=open("mail-test") s=f.read(bsize) while s: input=StringIO(s) decode(input, output, 'quoted-printable') s=f.read(bsize) stdout.write('.') stdout.flush() stdout.write('done\n') --7JfCtLOvnd9MIVvH-- ==================================================================== Audit trail: Tue Jul 11 08:25:57 2000 guido moved from incoming to open ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-23 10:10 Message: Logged In: NO Ive reproduced this problem. The file that gives the library fits is a PDF file that reports as quoted-printable. The file is an actual PDF sent with Microsoft Outlook. Every line in the quoted-printable ends in an =. It looks like the decode function will keep appending to a single line if it finds an = at the end of the line. This is the flag that tells the quopri.decode that the line is a partial line. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-09-21 18:35 Message: I marked this Invalid and Closed. There *may* have been a buffering problem in 1.5.2 that got fixed, or it may simply be that the original report used an unrealistic input file (which is what I suspect -- gory details below), or both. But note that the true complaint ("decode is really slow") probably remains valid. There's *something* still going on here in 2.0b1, at least under Win98SE. Here's the output from a more self-contained version of the program: C:\Python20>python mtest.py 1024 4.6 2048 6.1 10240 7.9 30720 8.8 102400 8.9 307200 9.4 1024 4.5 2048 5.8 10240 8.3 30720 8.9 102400 9.0 307200 9.4 C:\Python20> That's with everything in cache, and there's a very clear & reproducible factor-of-2 advantage to using the small blocksize. Here's the program: BIGFILE = "DLLs/tk83.dll" def timer(fname, blockseq): from mimetools import decode from StringIO import StringIO from time import clock for mult in blockseq: start = clock() bsize = mult * 1024 output = StringIO() f = open(fname, "rb") s = f.read(bsize) while s: input = StringIO(s) decode(input, output, 'quoted-printable') s = f.read(bsize) f.close() del output, f, s, input finish = clock() print "%10d %10.1f" % (bsize, finish - start) if __name__ == "__main__": timer(BIGFILE, (1, 2, 10, 30, 100, 300) * 2) Of course, I'm reading in a binary file there, so the test makes no real sense! And I *suspect* the original bug report also used a nonsense file. Why that's important will become clear soon. If I interrupt the program at random, it's usually on line 72 of quopri.py: File "C:\PYTHON20\lib\quopri.py", line 72, in decode new = new + c; i = i+1 That hints at a problem with the quadratic-time nature of repeated appends. Conventional wisdom is that's just theoretical, but it isn't, and the crossover point is highly platform-dependent. If I replace the call to decode with: while 1: line = input.readline() if not line: break new = "" for ch in line: pass output.write(line) then there's no apparent dependence on block size. So this is not a problem with buffering, it's specific to decode. But if I replace the "pass" with new = new + ch then I get back a very strong dependence on block size. And that loop is what decode does, except for the useful parts . So that explains *my* glitch: the smaller the blocksize, the more "lines" get artificially created, the smaller the longest lines become, and the less the ch-at-a-time append can hurt. But this is all an artifact of me using a binary file for input! That is, it's an artifact of using a test file with nearly arbitrarily long "lines". If I create a giant 4Mb text file via catenating all the *.html files in the Windows Python doc/lib directory, there is no dependence on blocksize in the test program, other than that it gets a little *faster* the larger the block size. And that's what I'd expect (repeated catenation is linear-time on all platforms I've heard of, so long as the lines are reasonably short). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-09-19 11:11 Message: Can't reproduce it either. Note he's using Python 1.5.1. Maybe it was a buffering problem in StringIO there - quopri.py is using readline(). Barry, if you don't have another idea, just close it as Invalid. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2000-09-19 09:52 Message: I can't reproduce the problem. On sparc-sun-solaris2.6, Python 1.5.2 needs the same time for a 330k file, regardless of the block size. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210648&group_id=5470 From noreply@sourceforge.net Mon Jul 23 18:48:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 10:48:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-443866 ] Evaluating func_code causing core dump Message-ID: Bugs item #443866, was opened at 2001-07-23 10:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443866&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jonathan Hogg (jhogg) Assigned to: Nobody/Anonymous (nobody) Summary: Evaluating func_code causing core dump Initial Comment: Python 2.2a1 (#1, Jul 19 2001, 18:18:51) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)] on linux2 The intepreter dies hard if you directly evaluate the func_code of a function that has a closure. E.g.: ----- def func1(): return lambda: 4 + y f = func1() print "Ugly test 1:", eval( f.func_code, {'y': 38} ) def func2(x): return lambda: x + y f = func2(4) print "Ugly test 2:", eval( f.func_code, {'y': 38} ) ----- The second eval will cause a core dump on UNIX. The offending code is in PyEval_EvalCodeEx() of ceval.c line 2466. This loop attempts to match free vars against the closure, but the closure is NULL if the function is called with eval. I know this is very broken usage of the interpreter, but it should die more cleanly than a core dump ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443866&group_id=5470 From noreply@sourceforge.net Mon Jul 23 21:00:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 13:00:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-432570 ] overlapping groups ? Message-ID: Bugs item #432570, was opened at 2001-06-12 15:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432570&group_id=5470 Category: Regular Expressions Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fredrik Lundh (effbot) Summary: overlapping groups ? Initial Comment: with perl: $tag = ''; $tag =~ /<(\/|\?)?(.*?)(\/|\?)?>/; print "1=$1\n"; print "2=$2\n"; print "3=$3\n"; you get: 1= 2=abc xyz="def/ghi" 3= with python (ActivePython 2.1, build 210 ActiveState based on Python 2.1 (#15, Apr 19 2001, 10:28:27) [MSC 32 bit (Intel)] on win32): import re p = re.compile("<(/|\?)?(.*?)(/|\?)?>") tag = '' m = p.search(tag) print '1='+str(m.group(1)) print '2='+str(m.group(2)) print '3='+str(m.group(3)) you get: 1=None 2=abc xyz="def/ghi" 3=abc xyz="def/ uups ... cu, jk. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432570&group_id=5470 From noreply@sourceforge.net Mon Jul 23 21:07:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 13:07:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-439710 ] User-defined mime.types file Message-ID: Bugs item #439710, was opened at 2001-07-09 06:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439710&group_id=5470 >Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: User-defined mime.types file Initial Comment: Zope users sometimes asks to add additional mime.types entries to Zope. Zopes mime-types handling is mostly based on mimetypes.py. In such cases users should be able to maintain their own mime.types files. mimetypes.py currently tries to look for mime.types files in 4 hardcoded locations. It would be more convinient to specify additional locations e.g. by an env. var that holds a list of additional locations or by any other mechanism that allows user-defined locations. The hardcoded locations also don't work on Windows. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-23 13:07 Message: Logged In: YES user_id=3066 Sounds like there should be an object which can be configured with a search path at construction time. Applications could then store an appropriate mime.types file in a location that makes sense for them. Would this suite your purposes? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439710&group_id=5470 From noreply@sourceforge.net Mon Jul 23 21:12:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 13:12:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-439710 ] User-defined mime.types file Message-ID: Bugs item #439710, was opened at 2001-07-09 06:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439710&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: User-defined mime.types file Initial Comment: Zope users sometimes asks to add additional mime.types entries to Zope. Zopes mime-types handling is mostly based on mimetypes.py. In such cases users should be able to maintain their own mime.types files. mimetypes.py currently tries to look for mime.types files in 4 hardcoded locations. It would be more convinient to specify additional locations e.g. by an env. var that holds a list of additional locations or by any other mechanism that allows user-defined locations. The hardcoded locations also don't work on Windows. ---------------------------------------------------------------------- >Comment By: Andreas Jung (ajung) Date: 2001-07-23 13:12 Message: Logged In: YES user_id=11084 A more OO approach would be nice. At least a possibility to add "somehow" different file locations. I have not special preference for any solution. Andreas ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-23 13:07 Message: Logged In: YES user_id=3066 Sounds like there should be an object which can be configured with a search path at construction time. Applications could then store an appropriate mime.types file in a location that makes sense for them. Would this suite your purposes? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439710&group_id=5470 From noreply@sourceforge.net Mon Jul 23 22:00:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 14:00:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-443784 ] test_poll hangs in cygwin Message-ID: Bugs item #443784, was opened at 2001-07-23 05:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443784&group_id=5470 Category: Windows >Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) >Assigned to: Nobody/Anonymous (nobody) Summary: test_poll hangs in cygwin Initial Comment: Fresh install of cygwin32. Fresh checkout of descr- branch. Windows 98. test_poll hangs. Output when running test_poll manually: Running poll test 1 This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/test/test_poll.py", line 171, in ? test_poll1() File "/usr/lib/python2.1/test/test_poll.py", line 65, in test_poll1 poll_unit_tests() File "/usr/lib/python2.1/test/test_poll.py", line 77, in poll_unit_tests r = p.poll() KeyboardInterrupt ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-23 14:00 Message: Logged In: YES user_id=31435 test_poll's failure on Cygwin is already noted in the main README file, and isn't unique to descr-branch. You need a platform expert for this; since the chance of me fixing it is 0, unassigned the bug. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443784&group_id=5470 From noreply@sourceforge.net Mon Jul 23 22:03:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 14:03:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-443783 ] Cygwin32 builds threads, but they hang Message-ID: Bugs item #443783, was opened at 2001-07-23 05:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443783&group_id=5470 Category: Windows >Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) >Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin32 builds threads, but they hang Initial Comment: Recent cygwin32 install. recent descr-branch checkout. Windows 98 system. Python compiles with thread support. However, 'test_asynchat' and 'test_thread*' hang. Workaround: configure --without-threads ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-23 14:03 Message: Logged In: YES user_id=31435 The README file already says Cygwin has to be built via configure --with-threads=no This has nothing to do with descr-branch. Unassigned this bug, pending a Cygwin expert to deal with it. Jeff, please read the README file before rediscovering all the other things already known not to work . ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443783&group_id=5470 From noreply@sourceforge.net Mon Jul 23 22:16:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 14:16:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-441600 ] Misleading doc of $ metacharacter in re Message-ID: Bugs item #441600, was opened at 2001-07-15 22:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441600&group_id=5470 >Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: Misleading doc of $ metacharacter in re Initial Comment: From: machin_john_888@hotmail.com (John Machin) Newsgroups: comp.lang.python Subject: Re: re Challenge: More Compact? References: NNTP-Posting-Host: 140.168.16.251 Message-ID: <92ae279c.0107152124.4c049d5e@posting.google.com> "Tim Peters" wrote in message news:... > BTW, does it bother anyone that all of these solutions accept an IP ending > with a newline? > > regexps-are-surprising-ly y'rs - tim Straight out of the horse's mouth at http://python.sourceforge.net/devel-docs/lib/re- syntax.html (this is in section 4.2.1 of the Python Library Reference): "$" Matches the end of the string, and in MULTILINE mode also matches before a newline. foo matches both 'foo' and 'foobar', while the regular expression foo$ matches only 'foo'. But the real story only emerges two pages later (in section 4.2.3): M MULTILINE When specified, the pattern character "^" matches at the beginning of the string and at the beginning of each line (immediately following each newline); and the pattern character "$" matches at the end of the string and at the end of each line (immediately preceding each newline). By default, "^" matches only at the beginning of the string, and "$" only at the end of the string and immediately before the newline (if any) at the end of the string. I shall enter a bug report and leave it up to the powers_that_be to decide whether to change the behaviour or section 4.2.1 of the documentation. To answer Tim's question, yes it bothers me ... the solution of course always when you want to validate that the pattern matches the whole string (and not some leading substring) is to have \Z at the end of your pattern (not $). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-23 14:16 Message: Logged In: YES user_id=3066 Fixed the documentation in Doc/lib/libre.tex revision 1.64. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441600&group_id=5470 From noreply@sourceforge.net Tue Jul 24 03:51:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 19:51:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-439710 ] User-defined mime.types file Message-ID: Bugs item #439710, was opened at 2001-07-09 06:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439710&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: User-defined mime.types file Initial Comment: Zope users sometimes asks to add additional mime.types entries to Zope. Zopes mime-types handling is mostly based on mimetypes.py. In such cases users should be able to maintain their own mime.types files. mimetypes.py currently tries to look for mime.types files in 4 hardcoded locations. It would be more convinient to specify additional locations e.g. by an env. var that holds a list of additional locations or by any other mechanism that allows user-defined locations. The hardcoded locations also don't work on Windows. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-23 19:51 Message: Logged In: YES user_id=3066 I've attached a new version of mimetypes.py; something like this should do the trick and be easy to extend as needed. Comments welcome. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2001-07-23 13:12 Message: Logged In: YES user_id=11084 A more OO approach would be nice. At least a possibility to add "somehow" different file locations. I have not special preference for any solution. Andreas ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-23 13:07 Message: Logged In: YES user_id=3066 Sounds like there should be an object which can be configured with a search path at construction time. Applications could then store an appropriate mime.types file in a location that makes sense for them. Would this suite your purposes? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439710&group_id=5470 From noreply@sourceforge.net Tue Jul 24 07:26:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Jul 2001 23:26:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-444004 ] distutils not mentioned in library docs Message-ID: Bugs item #444004, was opened at 2001-07-23 23:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444004&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: distutils not mentioned in library docs Initial Comment: distutils is un(der)documented in the standard library ref - it's not in the library docs (afaics) nor is it mentioned in the "stuff what is not documented". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444004&group_id=5470 From noreply@sourceforge.net Tue Jul 24 08:11:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Jul 2001 00:11:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-438786 ] CVS 2.1.1c1 broken on osf1V4 Message-ID: Bugs item #438786, was opened at 2001-07-05 07:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Martin v. Löwis (loewis) Summary: CVS 2.1.1c1 broken on osf1V4 Initial Comment: As of right now, the CVS branch for the 2.1 bugfix release cannot import the math module on my Digital Unix platform. ImportError: Unresolved symbol in /tmp_mnt/home/gball/usr/src/python/dist/src/build/lib.osf1-V4.0-alpha-2.1/math.so: __eprintf uname is OSF1 surya V4.0 878 alpha ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-24 00:11 Message: Logged In: YES user_id=21627 Gregory, can you please try the attached patch, and report whether it changes anything? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 13:33 Message: Logged In: YES user_id=6380 I don't recall why that was. It was 6 years ago! Quite possibly things have changed; the OSF in use now is probably quite different than the one then. So, Martin, try to back out the change and see if this doesn't break other things. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-19 12:38 Message: Logged In: YES user_id=21627 This seems to originate fromt the fragment OSF1) CC=cc without_gcc=;; which was introduced in configure.in 1.23, with the comment on osf/1, never use gcc Therefore, I'm assigning it to Guido. My proposal is to close this as "won't fix" - if setting CC doesn't work, just don't do that. Alternatively, if nobody can remember why gcc should not be used on OSF/1, it might be reasonable to back-out this change. ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-19 12:12 Message: Logged In: YES user_id=11365 I just checked out the 2.1.1 branch again and it still seems to be broken. After a fresh config with $CC set to gcc in the environment, the Makefile contains CC= cc OPT= -O -Olimit 1500 CCSHARED= so it looks like configure has decided to use cc and chosen flags for that compiler. Then, the actual build command lines look like gcc -I. -I/tmp_mnt/home/gball/usr/src/python/dist/src/./Include -I/usr/local/include -IInclude/ -c /tmp_mnt/home/gball/usr/src/python/dist/src/Modules/fpectlmodule.c -o build/temp.osf1-V4.0-alpha-2.1/fpectlmodule.o i.e. just "gcc" instead of "cc -O -Olimit 1500" so it looks like the environment variable gets pulled in only at the last moment and replaces $(CC), $(OPT) and possibly $(CCSHARED), thereby throwing away the work done by configure. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-19 02:59 Message: Logged In: YES user_id=34209 Gregory, did you get a chance to test the patch attached to bug #437487, or the 2.1.1 CVS tree ? I'd like to know if this is fixed in 2.1.1. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-16 08:56 Message: Logged In: YES user_id=34209 Ah, yes, that sounds very plausible. The fix for that problem, which was checked in on the trunk, will be in Python 2.1.1-final as well. The Solaris bugreport has a patch attached to it; could you test it to see if it solves your 2.1.1c1 problem ? ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-09 08:48 Message: Logged In: YES user_id=11365 The problem goes away if I clear $CC instead of having it set to gcc. There's a similar problem on Solaris reported recently. I think the configure script should try to spot this sort of thing, but I suppose that's an Autoconf feature request, not a python bug... Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-08 14:06 Message: Logged In: YES user_id=21627 This sounds like a bug in your compiler installation. __eprintf is typically defined in libgcc.a; make sure you use a consistent compiler capable of building binaries for your system throughout the build process. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 From noreply@sourceforge.net Tue Jul 24 08:14:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Jul 2001 00:14:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-416944 ] 2.0: cum sympt; w/gdb bktr; OBSD2.8. Message-ID: Bugs item #416944, was opened at 2001-04-17 21:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416944&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Wont Fix Priority: 3 Submitted By: Brad Allen (valaulmo) Assigned to: Martin v. Löwis (loewis) Summary: 2.0: cum sympt; w/gdb bktr; OBSD2.8. Initial Comment: Reverted to Python 2.0 + all patches on patch pages, still with OpenBSD 2.8. Only non-default module set is zlib (needed for Mojo Nation according to the docs). System is Pentium 133MHz. Ok, I'm getting better at this now. This time, I ran GDB on it, since I noticed that one of the bugs may have cumulative dependent symptoms. Also, I'm typing this bug report into the web browser so that it wraps correctly (I'll cross my fingers that it doesn't crash though; that's why I prefer Emacs; I suppose I could try SSL W3 Emacs but that is hard; not now.) Here is the gdb output where it did die: [... lots of tests ...] test_long Program received signal SIGSEGV, Segmentation fault. 0x4017bc2f in _thread_machdep_switch () (gdb) bt #0 0x4017bc2f in _thread_machdep_switch () #1 0x401c8308 in _sigq_check_reqd () #2 0x4017ba66 in _thread_kern_sig_undefer () #3 0x4017eb68 in pthread_cond_signal () #4 0x1510d in PyThread_release_lock (lock=0x27c320) at thread_pthread.h:344 #5 0x43006 in eval_code2 (co=0x3c7d80, globals=0x3c104c, locals=0x0, args=0x25cd58, argcount=2, kws=0x25cd60, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:617 #6 0x450b3 in eval_code2 (co=0x3c7f40, globals=0x3c104c, locals=0x0, args=0x1a4d60, argcount=1, kws=0x1a4d64, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1850 #7 0x450b3 in eval_code2 (co=0x4221c0, globals=0x3c104c, locals=0x0, args=0x39a140, argcount=0, kws=0x39a140, kwcount=0, defs=0x29c1b8, defcount=1, owner=0x0) at ceval.c:1850 #8 0x450b3 in eval_code2 (co=0x41c900, globals=0x3c104c, locals=0x3c104c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1850 #9 0x42625 in PyEval_EvalCode (co=0x41c900, globals=0x3c104c, locals=0x3c104c) at ceval.c:319 #10 0xacff in PyImport_ExecCodeModuleEx (name=0xdfbfd180 "test_long", co=0x41c900, pathname=0xdfbfcce0 "./Lib/test/test_long.py") at import.c:495 #11 0xb30a in load_source_module (name=0xdfbfd180 "test_long", pathname=0xdfbfcce0 "./Lib/test/test_long.py", fp=0x401fa83c) at import.c:758 #12 0xbc23 in load_module (name=0xdfbfd180 "test_long", fp=0x401fa83c, buf=0xdfbfcce0 "./Lib/test/test_long.py", type=1) at import.c:1227 #13 0xc8fb in import_submodule (mod=0x1140fc, subname=0xdfbfd180 "test_long", fullname=0xdfbfd180 "test_long") at import.c:1755 #14 0xc4ca in load_next (mod=0x1140fc, altmod=0x1140fc, p_name=0xdfbfd58c, buf=0xdfbfd180 "test_long", p_buflen=0xdfbfd17c) at import.c:1611 #15 0xc142 in import_module_ex (name=0x0, globals=0x14624c, locals=0x1a538c, fromlist=0x29c02c) at import.c:1462 ---Type to continue, or q to quit--- #16 0xc277 in PyImport_ImportModuleEx (name=0x19f0d4 "test_long", globals=0x14624c, locals=0x1a538c, fromlist=0x29c02c) at import.c:1503 #17 0x3ce47 in builtin___import__ (self=0x0, args=0x3b198c) at bltinmodule.c:31 #18 0x4668d in call_builtin (func=0x141070, arg=0x3b198c, kw=0x0) at ceval.c:2650 #19 0x46507 in PyEval_CallObjectWithKeywords (func=0x141070, arg=0x3b198c, kw=0x0) at ceval.c:2618 #20 0x453ac in eval_code2 (co=0x1cc240, globals=0x14624c, locals=0x0, args=0x15fdcc, argcount=5, kws=0x15fde0, kwcount=0, defs=0x1c4738, defcount=1, owner=0x0) at ceval.c:1951 #21 0x450b3 in eval_code2 (co=0x1c9f00, globals=0x14624c, locals=0x0, args=0x140f44, argcount=0, kws=0x140f44, kwcount=0, defs=0x18d918, defcount=10, owner=0x0) at ceval.c:1850 #22 0x450b3 in eval_code2 (co=0x1c9f80, globals=0x14624c, locals=0x14624c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1850 #23 0x42625 in PyEval_EvalCode (co=0x1c9f80, globals=0x14624c, locals=0x14624c) at ceval.c:319 #24 0x1272f in run_node (n=0x155400, filename=0xdfbfdb5a "./Lib/test/regrtest.py", globals=0x14624c, locals=0x14624c) at pythonrun.c:886 #25 0x126e8 in run_err_node (n=0x155400, filename=0xdfbfdb5a "./Lib/test/regrtest.py", globals=0x14624c, locals=0x14624c) at pythonrun.c:874 #26 0x126c4 in PyRun_FileEx (fp=0x401fa7e4, filename=0xdfbfdb5a "./Lib/test/regrtest.py", start=257, globals=0x14624c, locals=0x14624c, closeit=1) at pythonrun.c:866 #27 0x11cfe in PyRun_SimpleFileEx (fp=0x401fa7e4, filename=0xdfbfdb5a "./Lib/test/regrtest.py", closeit=1) at pythonrun.c:579 #28 0x118f3 in PyRun_AnyFileEx (fp=0x401fa7e4, filename=0xdfbfdb5a "./Lib/test/regrtest.py", closeit=1) at pythonrun.c:459 #29 0x24bb in Py_Main (argc=2, argv=0xdfbfdac8) at main.c:289 ---Type to continue, or q to quit--- #30 0x17b5 in main (argc=4, argv=0xdfbfdac8) at python.c:10 (gdb) Once again, I will attach the config.* (config.cache, etc.) to this in a file. Brad Allen ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-24 00:14 Message: Logged In: YES user_id=21627 There is a known bug on some BSD variants that causes problems when mixing both the threaded and the nonthreaded libc. So unless it can be established that this is not the cause, or unless other information on this bug becomes available, I close this as "won't fix". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-02 03:21 Message: Logged In: YES user_id=21627 Without access to an OpenBSD machine, this is difficult to analyze. I agree with Jeremy that it looks like a bug in your C library and/or operating system, and I also recommend to build Python with --disable-threads. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-24 10:44 Message: Logged In: YES user_id=21627 To me, this likes like a bug in the multithread support of your operating system. To work around this bug, you should configure python with --disable-threads. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416944&group_id=5470 From noreply@sourceforge.net Tue Jul 24 16:12:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Jul 2001 08:12:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-444129 ] python20 dll not found Message-ID: Bugs item #444129, was opened at 2001-07-24 08:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 Category: Windows Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: python20 dll not found Initial Comment: after upgrading from 2.0 to 2.1 then to 2.1.1 getting error that cant find python20.dll. I completely removed all traces of python and did a fresh install even modified the registry and removed all instances of python and pywin. It is important to note that I also removed an re-installed win32all and it failed to completely install because this error. Another note though python will still run after the error is given the win32 extensions fail to load. I am running on japaneese version of win2000 but had the same problem on the english version(the steps mentioned fixed the problem on english version). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 From noreply@sourceforge.net Tue Jul 24 17:34:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Jul 2001 09:34:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-444129 ] python20 dll not found Message-ID: Bugs item #444129, was opened at 2001-07-24 08:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 Category: Windows >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: python20 dll not found Initial Comment: after upgrading from 2.0 to 2.1 then to 2.1.1 getting error that cant find python20.dll. I completely removed all traces of python and did a fresh install even modified the registry and removed all instances of python and pywin. It is important to note that I also removed an re-installed win32all and it failed to completely install because this error. Another note though python will still run after the error is given the win32 extensions fail to load. I am running on japaneese version of win2000 but had the same problem on the english version(the steps mentioned fixed the problem on english version). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-24 09:34 Message: Logged In: YES user_id=31435 It sounds like you're trying to use Python 2.1.1 with a version of win32all built for 2.0. If so, you can't do that -- Python 2.1.x supplies python21.dll, not python20.dll. Go to ActiveState's site and either install ActivePython from them (which comes with a matched set of components), or get build 140 of win32all.exe from them (which was built to work with Python 2.1 -- but won't work with Python 2.0). Feel free to reopen this bug report if that doesn't solve it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 From noreply@sourceforge.net Tue Jul 24 17:39:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Jul 2001 09:39:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-444004 ] distutils not mentioned in library docs Message-ID: Bugs item #444004, was opened at 2001-07-23 23:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444004&group_id=5470 Category: Documentation Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: distutils not mentioned in library docs Initial Comment: distutils is un(der)documented in the standard library ref - it's not in the library docs (afaics) nor is it mentioned in the "stuff what is not documented". ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-24 09:39 Message: Logged In: YES user_id=3066 I've added a section on the distutils package; it's mostly empty but contains references to the two separate manuals for distutils. API references for distutils will be added to the "Distributing Python Modules" manual, since the APIs should normally only be needed when creating a distutils setup.py file. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444004&group_id=5470 From noreply@sourceforge.net Tue Jul 24 17:54:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Jul 2001 09:54:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-444129 ] python20 dll not found Message-ID: Bugs item #444129, was opened at 2001-07-24 08:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 Category: Windows Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: python20 dll not found Initial Comment: after upgrading from 2.0 to 2.1 then to 2.1.1 getting error that cant find python20.dll. I completely removed all traces of python and did a fresh install even modified the registry and removed all instances of python and pywin. It is important to note that I also removed an re-installed win32all and it failed to completely install because this error. Another note though python will still run after the error is given the win32 extensions fail to load. I am running on japaneese version of win2000 but had the same problem on the english version(the steps mentioned fixed the problem on english version). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 09:54 Message: Logged In: NO I am in fact not using the wrong version of win32all, the problem occurs prior to the install of the extensions. And it is correct that the 2.0 dll's are not installed and python2.1.1 (or 2.1) is complaining about it. I originaly thought the same thing so I removed win32all and python2.1.1 unloaded the dll's and re-installed 2.1.1 prior to re-installing win32all I got the same errors. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 09:34 Message: Logged In: YES user_id=31435 It sounds like you're trying to use Python 2.1.1 with a version of win32all built for 2.0. If so, you can't do that -- Python 2.1.x supplies python21.dll, not python20.dll. Go to ActiveState's site and either install ActivePython from them (which comes with a matched set of components), or get build 140 of win32all.exe from them (which was built to work with Python 2.1 -- but won't work with Python 2.0). Feel free to reopen this bug report if that doesn't solve it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 From noreply@sourceforge.net Tue Jul 24 18:00:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Jul 2001 10:00:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-444129 ] python20 dll not found Message-ID: Bugs item #444129, was opened at 2001-07-24 08:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 Category: Windows >Group: Irreproducible >Status: Open >Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: python20 dll not found Initial Comment: after upgrading from 2.0 to 2.1 then to 2.1.1 getting error that cant find python20.dll. I completely removed all traces of python and did a fresh install even modified the registry and removed all instances of python and pywin. It is important to note that I also removed an re-installed win32all and it failed to completely install because this error. Another note though python will still run after the error is given the win32 extensions fail to load. I am running on japaneese version of win2000 but had the same problem on the english version(the steps mentioned fixed the problem on english version). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-24 10:00 Message: Logged In: YES user_id=6380 Sorry to butt in... Are you perhaps trying to use a third party extension like PIL or Numeric Python? Or your own? Extensions built for one Python version won't work with another. Can you tell us exactly what you did that gave the error message? Preferably with the path to the executable that you are trying to run that gives the exception. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 09:54 Message: Logged In: NO I am in fact not using the wrong version of win32all, the problem occurs prior to the install of the extensions. And it is correct that the 2.0 dll's are not installed and python2.1.1 (or 2.1) is complaining about it. I originaly thought the same thing so I removed win32all and python2.1.1 unloaded the dll's and re-installed 2.1.1 prior to re-installing win32all I got the same errors. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 09:34 Message: Logged In: YES user_id=31435 It sounds like you're trying to use Python 2.1.1 with a version of win32all built for 2.0. If so, you can't do that -- Python 2.1.x supplies python21.dll, not python20.dll. Go to ActiveState's site and either install ActivePython from them (which comes with a matched set of components), or get build 140 of win32all.exe from them (which was built to work with Python 2.1 -- but won't work with Python 2.0). Feel free to reopen this bug report if that doesn't solve it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 From noreply@sourceforge.net Tue Jul 24 18:07:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Jul 2001 10:07:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-444129 ] python20 dll not found Message-ID: Bugs item #444129, was opened at 2001-07-24 08:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 Category: Windows >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: python20 dll not found Initial Comment: after upgrading from 2.0 to 2.1 then to 2.1.1 getting error that cant find python20.dll. I completely removed all traces of python and did a fresh install even modified the registry and removed all instances of python and pywin. It is important to note that I also removed an re-installed win32all and it failed to completely install because this error. Another note though python will still run after the error is given the win32 extensions fail to load. I am running on japaneese version of win2000 but had the same problem on the english version(the steps mentioned fixed the problem on english version). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-24 10:07 Message: Logged In: YES user_id=31435 Then we need more specific information from you. I've never heard of this and find it difficult to believe that anything in the std Python 2.1 distribution requires python20.dll. I just removed all traces of all Pythons from my Win2K box, installed a fresh 2.1.1, and ran the std test suite to completion without any problems. Exactly what do you do that triggers a msg about python20.dll? If I can't reproduce it (and so far I can't), all we can do is guess. Do you perhaps have your own customizations in a PYTHONSTARTUP file that may be trying to access obsolete stuff? Have you tried running Python with -v to get a trace of what it's trying to import? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-24 10:00 Message: Logged In: YES user_id=6380 Sorry to butt in... Are you perhaps trying to use a third party extension like PIL or Numeric Python? Or your own? Extensions built for one Python version won't work with another. Can you tell us exactly what you did that gave the error message? Preferably with the path to the executable that you are trying to run that gives the exception. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 09:54 Message: Logged In: NO I am in fact not using the wrong version of win32all, the problem occurs prior to the install of the extensions. And it is correct that the 2.0 dll's are not installed and python2.1.1 (or 2.1) is complaining about it. I originaly thought the same thing so I removed win32all and python2.1.1 unloaded the dll's and re-installed 2.1.1 prior to re-installing win32all I got the same errors. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 09:34 Message: Logged In: YES user_id=31435 It sounds like you're trying to use Python 2.1.1 with a version of win32all built for 2.0. If so, you can't do that -- Python 2.1.x supplies python21.dll, not python20.dll. Go to ActiveState's site and either install ActivePython from them (which comes with a matched set of components), or get build 140 of win32all.exe from them (which was built to work with Python 2.1 -- but won't work with Python 2.0). Feel free to reopen this bug report if that doesn't solve it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 From noreply@sourceforge.net Tue Jul 24 18:35:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Jul 2001 10:35:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-444129 ] python20 dll not found Message-ID: Bugs item #444129, was opened at 2001-07-24 08:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 Category: Windows Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: python20 dll not found Initial Comment: after upgrading from 2.0 to 2.1 then to 2.1.1 getting error that cant find python20.dll. I completely removed all traces of python and did a fresh install even modified the registry and removed all instances of python and pywin. It is important to note that I also removed an re-installed win32all and it failed to completely install because this error. Another note though python will still run after the error is given the win32 extensions fail to load. I am running on japaneese version of win2000 but had the same problem on the english version(the steps mentioned fixed the problem on english version). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 10:35 Message: Logged In: NO As of my last attempt I was running nothing but BeOpen pyhton 2.1.1 (no third party libraries)on a clean system. The error occurs when I run python from the command line or IDLE. I rolled back to 2.0 then installed 2.1.1 on top of it just now and it seemed to fix python. I then installed win32all 140 and the install script throws a similar error saying "module use of python20.dll conflicts with this version of python". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 10:07 Message: Logged In: YES user_id=31435 Then we need more specific information from you. I've never heard of this and find it difficult to believe that anything in the std Python 2.1 distribution requires python20.dll. I just removed all traces of all Pythons from my Win2K box, installed a fresh 2.1.1, and ran the std test suite to completion without any problems. Exactly what do you do that triggers a msg about python20.dll? If I can't reproduce it (and so far I can't), all we can do is guess. Do you perhaps have your own customizations in a PYTHONSTARTUP file that may be trying to access obsolete stuff? Have you tried running Python with -v to get a trace of what it's trying to import? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-24 10:00 Message: Logged In: YES user_id=6380 Sorry to butt in... Are you perhaps trying to use a third party extension like PIL or Numeric Python? Or your own? Extensions built for one Python version won't work with another. Can you tell us exactly what you did that gave the error message? Preferably with the path to the executable that you are trying to run that gives the exception. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 09:54 Message: Logged In: NO I am in fact not using the wrong version of win32all, the problem occurs prior to the install of the extensions. And it is correct that the 2.0 dll's are not installed and python2.1.1 (or 2.1) is complaining about it. I originaly thought the same thing so I removed win32all and python2.1.1 unloaded the dll's and re-installed 2.1.1 prior to re-installing win32all I got the same errors. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 09:34 Message: Logged In: YES user_id=31435 It sounds like you're trying to use Python 2.1.1 with a version of win32all built for 2.0. If so, you can't do that -- Python 2.1.x supplies python21.dll, not python20.dll. Go to ActiveState's site and either install ActivePython from them (which comes with a matched set of components), or get build 140 of win32all.exe from them (which was built to work with Python 2.1 -- but won't work with Python 2.0). Feel free to reopen this bug report if that doesn't solve it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 From noreply@sourceforge.net Tue Jul 24 19:04:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Jul 2001 11:04:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-438786 ] CVS 2.1.1c1 broken on osf1V4 Message-ID: Bugs item #438786, was opened at 2001-07-05 07:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Martin v. Löwis (loewis) Summary: CVS 2.1.1c1 broken on osf1V4 Initial Comment: As of right now, the CVS branch for the 2.1 bugfix release cannot import the math module on my Digital Unix platform. ImportError: Unresolved symbol in /tmp_mnt/home/gball/usr/src/python/dist/src/build/lib.osf1-V4.0-alpha-2.1/math.so: __eprintf uname is OSF1 surya V4.0 878 alpha ---------------------------------------------------------------------- >Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-24 11:04 Message: Logged In: YES user_id=11365 Yes, the patch works and make test fails only on test_format, I believe this is a known platform C library bug. I have attached a patch for the setup.py in python/dist/src. It touches code which is supposed to allow variables set on the make commandline to have effect. I see two issues with it. One, it effectively replaces CC and OPT from the Makefile with just CC. This is inconsistent with the behaviour of the Makefile and configure. My setup.patch addresses this. Two, it doesn't really do what it says, because the variable it picks up from the environment can has not necessarily got there through a commandline argument to make. This only becomes a problem when configure decides to ignore an environment variable, as was the case on OSF. Martin's patch stops this from happening on OSF, but the code is still fragile. Here's an idea: make should always export its value of CC into the environment of subprocesses. Using Gnu make I'd do this with an 'export' directive. I'll next send a patch to Makefile.pre.in which should do the job portably but it isn't especially pretty. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-24 00:11 Message: Logged In: YES user_id=21627 Gregory, can you please try the attached patch, and report whether it changes anything? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 13:33 Message: Logged In: YES user_id=6380 I don't recall why that was. It was 6 years ago! Quite possibly things have changed; the OSF in use now is probably quite different than the one then. So, Martin, try to back out the change and see if this doesn't break other things. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-19 12:38 Message: Logged In: YES user_id=21627 This seems to originate fromt the fragment OSF1) CC=cc without_gcc=;; which was introduced in configure.in 1.23, with the comment on osf/1, never use gcc Therefore, I'm assigning it to Guido. My proposal is to close this as "won't fix" - if setting CC doesn't work, just don't do that. Alternatively, if nobody can remember why gcc should not be used on OSF/1, it might be reasonable to back-out this change. ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-19 12:12 Message: Logged In: YES user_id=11365 I just checked out the 2.1.1 branch again and it still seems to be broken. After a fresh config with $CC set to gcc in the environment, the Makefile contains CC= cc OPT= -O -Olimit 1500 CCSHARED= so it looks like configure has decided to use cc and chosen flags for that compiler. Then, the actual build command lines look like gcc -I. -I/tmp_mnt/home/gball/usr/src/python/dist/src/./Include -I/usr/local/include -IInclude/ -c /tmp_mnt/home/gball/usr/src/python/dist/src/Modules/fpectlmodule.c -o build/temp.osf1-V4.0-alpha-2.1/fpectlmodule.o i.e. just "gcc" instead of "cc -O -Olimit 1500" so it looks like the environment variable gets pulled in only at the last moment and replaces $(CC), $(OPT) and possibly $(CCSHARED), thereby throwing away the work done by configure. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-19 02:59 Message: Logged In: YES user_id=34209 Gregory, did you get a chance to test the patch attached to bug #437487, or the 2.1.1 CVS tree ? I'd like to know if this is fixed in 2.1.1. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-16 08:56 Message: Logged In: YES user_id=34209 Ah, yes, that sounds very plausible. The fix for that problem, which was checked in on the trunk, will be in Python 2.1.1-final as well. The Solaris bugreport has a patch attached to it; could you test it to see if it solves your 2.1.1c1 problem ? ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-09 08:48 Message: Logged In: YES user_id=11365 The problem goes away if I clear $CC instead of having it set to gcc. There's a similar problem on Solaris reported recently. I think the configure script should try to spot this sort of thing, but I suppose that's an Autoconf feature request, not a python bug... Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-08 14:06 Message: Logged In: YES user_id=21627 This sounds like a bug in your compiler installation. __eprintf is typically defined in libgcc.a; make sure you use a consistent compiler capable of building binaries for your system throughout the build process. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 From noreply@sourceforge.net Tue Jul 24 19:05:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Jul 2001 11:05:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-438786 ] CVS 2.1.1c1 broken on osf1V4 Message-ID: Bugs item #438786, was opened at 2001-07-05 07:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Martin v. Löwis (loewis) Summary: CVS 2.1.1c1 broken on osf1V4 Initial Comment: As of right now, the CVS branch for the 2.1 bugfix release cannot import the math module on my Digital Unix platform. ImportError: Unresolved symbol in /tmp_mnt/home/gball/usr/src/python/dist/src/build/lib.osf1-V4.0-alpha-2.1/math.so: __eprintf uname is OSF1 surya V4.0 878 alpha ---------------------------------------------------------------------- >Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-24 11:05 Message: Logged In: YES user_id=11365 Next patch uploaded. ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-24 11:04 Message: Logged In: YES user_id=11365 Yes, the patch works and make test fails only on test_format, I believe this is a known platform C library bug. I have attached a patch for the setup.py in python/dist/src. It touches code which is supposed to allow variables set on the make commandline to have effect. I see two issues with it. One, it effectively replaces CC and OPT from the Makefile with just CC. This is inconsistent with the behaviour of the Makefile and configure. My setup.patch addresses this. Two, it doesn't really do what it says, because the variable it picks up from the environment can has not necessarily got there through a commandline argument to make. This only becomes a problem when configure decides to ignore an environment variable, as was the case on OSF. Martin's patch stops this from happening on OSF, but the code is still fragile. Here's an idea: make should always export its value of CC into the environment of subprocesses. Using Gnu make I'd do this with an 'export' directive. I'll next send a patch to Makefile.pre.in which should do the job portably but it isn't especially pretty. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-24 00:11 Message: Logged In: YES user_id=21627 Gregory, can you please try the attached patch, and report whether it changes anything? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 13:33 Message: Logged In: YES user_id=6380 I don't recall why that was. It was 6 years ago! Quite possibly things have changed; the OSF in use now is probably quite different than the one then. So, Martin, try to back out the change and see if this doesn't break other things. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-19 12:38 Message: Logged In: YES user_id=21627 This seems to originate fromt the fragment OSF1) CC=cc without_gcc=;; which was introduced in configure.in 1.23, with the comment on osf/1, never use gcc Therefore, I'm assigning it to Guido. My proposal is to close this as "won't fix" - if setting CC doesn't work, just don't do that. Alternatively, if nobody can remember why gcc should not be used on OSF/1, it might be reasonable to back-out this change. ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-19 12:12 Message: Logged In: YES user_id=11365 I just checked out the 2.1.1 branch again and it still seems to be broken. After a fresh config with $CC set to gcc in the environment, the Makefile contains CC= cc OPT= -O -Olimit 1500 CCSHARED= so it looks like configure has decided to use cc and chosen flags for that compiler. Then, the actual build command lines look like gcc -I. -I/tmp_mnt/home/gball/usr/src/python/dist/src/./Include -I/usr/local/include -IInclude/ -c /tmp_mnt/home/gball/usr/src/python/dist/src/Modules/fpectlmodule.c -o build/temp.osf1-V4.0-alpha-2.1/fpectlmodule.o i.e. just "gcc" instead of "cc -O -Olimit 1500" so it looks like the environment variable gets pulled in only at the last moment and replaces $(CC), $(OPT) and possibly $(CCSHARED), thereby throwing away the work done by configure. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-19 02:59 Message: Logged In: YES user_id=34209 Gregory, did you get a chance to test the patch attached to bug #437487, or the 2.1.1 CVS tree ? I'd like to know if this is fixed in 2.1.1. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-16 08:56 Message: Logged In: YES user_id=34209 Ah, yes, that sounds very plausible. The fix for that problem, which was checked in on the trunk, will be in Python 2.1.1-final as well. The Solaris bugreport has a patch attached to it; could you test it to see if it solves your 2.1.1c1 problem ? ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-09 08:48 Message: Logged In: YES user_id=11365 The problem goes away if I clear $CC instead of having it set to gcc. There's a similar problem on Solaris reported recently. I think the configure script should try to spot this sort of thing, but I suppose that's an Autoconf feature request, not a python bug... Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-08 14:06 Message: Logged In: YES user_id=21627 This sounds like a bug in your compiler installation. __eprintf is typically defined in libgcc.a; make sure you use a consistent compiler capable of building binaries for your system throughout the build process. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 From noreply@sourceforge.net Tue Jul 24 19:06:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Jul 2001 11:06:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-438786 ] CVS 2.1.1c1 broken on osf1V4 Message-ID: Bugs item #438786, was opened at 2001-07-05 07:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Martin v. Löwis (loewis) Summary: CVS 2.1.1c1 broken on osf1V4 Initial Comment: As of right now, the CVS branch for the 2.1 bugfix release cannot import the math module on my Digital Unix platform. ImportError: Unresolved symbol in /tmp_mnt/home/gball/usr/src/python/dist/src/build/lib.osf1-V4.0-alpha-2.1/math.so: __eprintf uname is OSF1 surya V4.0 878 alpha ---------------------------------------------------------------------- >Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-24 11:06 Message: Logged In: YES user_id=11365 Doh! Now it's uploaded. Sorry for the extra traffic. ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-24 11:05 Message: Logged In: YES user_id=11365 Next patch uploaded. ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-24 11:04 Message: Logged In: YES user_id=11365 Yes, the patch works and make test fails only on test_format, I believe this is a known platform C library bug. I have attached a patch for the setup.py in python/dist/src. It touches code which is supposed to allow variables set on the make commandline to have effect. I see two issues with it. One, it effectively replaces CC and OPT from the Makefile with just CC. This is inconsistent with the behaviour of the Makefile and configure. My setup.patch addresses this. Two, it doesn't really do what it says, because the variable it picks up from the environment can has not necessarily got there through a commandline argument to make. This only becomes a problem when configure decides to ignore an environment variable, as was the case on OSF. Martin's patch stops this from happening on OSF, but the code is still fragile. Here's an idea: make should always export its value of CC into the environment of subprocesses. Using Gnu make I'd do this with an 'export' directive. I'll next send a patch to Makefile.pre.in which should do the job portably but it isn't especially pretty. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-24 00:11 Message: Logged In: YES user_id=21627 Gregory, can you please try the attached patch, and report whether it changes anything? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 13:33 Message: Logged In: YES user_id=6380 I don't recall why that was. It was 6 years ago! Quite possibly things have changed; the OSF in use now is probably quite different than the one then. So, Martin, try to back out the change and see if this doesn't break other things. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-19 12:38 Message: Logged In: YES user_id=21627 This seems to originate fromt the fragment OSF1) CC=cc without_gcc=;; which was introduced in configure.in 1.23, with the comment on osf/1, never use gcc Therefore, I'm assigning it to Guido. My proposal is to close this as "won't fix" - if setting CC doesn't work, just don't do that. Alternatively, if nobody can remember why gcc should not be used on OSF/1, it might be reasonable to back-out this change. ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-19 12:12 Message: Logged In: YES user_id=11365 I just checked out the 2.1.1 branch again and it still seems to be broken. After a fresh config with $CC set to gcc in the environment, the Makefile contains CC= cc OPT= -O -Olimit 1500 CCSHARED= so it looks like configure has decided to use cc and chosen flags for that compiler. Then, the actual build command lines look like gcc -I. -I/tmp_mnt/home/gball/usr/src/python/dist/src/./Include -I/usr/local/include -IInclude/ -c /tmp_mnt/home/gball/usr/src/python/dist/src/Modules/fpectlmodule.c -o build/temp.osf1-V4.0-alpha-2.1/fpectlmodule.o i.e. just "gcc" instead of "cc -O -Olimit 1500" so it looks like the environment variable gets pulled in only at the last moment and replaces $(CC), $(OPT) and possibly $(CCSHARED), thereby throwing away the work done by configure. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-19 02:59 Message: Logged In: YES user_id=34209 Gregory, did you get a chance to test the patch attached to bug #437487, or the 2.1.1 CVS tree ? I'd like to know if this is fixed in 2.1.1. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-16 08:56 Message: Logged In: YES user_id=34209 Ah, yes, that sounds very plausible. The fix for that problem, which was checked in on the trunk, will be in Python 2.1.1-final as well. The Solaris bugreport has a patch attached to it; could you test it to see if it solves your 2.1.1c1 problem ? ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-09 08:48 Message: Logged In: YES user_id=11365 The problem goes away if I clear $CC instead of having it set to gcc. There's a similar problem on Solaris reported recently. I think the configure script should try to spot this sort of thing, but I suppose that's an Autoconf feature request, not a python bug... Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-08 14:06 Message: Logged In: YES user_id=21627 This sounds like a bug in your compiler installation. __eprintf is typically defined in libgcc.a; make sure you use a consistent compiler capable of building binaries for your system throughout the build process. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 From noreply@sourceforge.net Tue Jul 24 19:08:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Jul 2001 11:08:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-436103 ] Compiling pygtk Message-ID: Bugs item #436103, was opened at 2001-06-25 07:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436103&group_id=5470 Category: Extension Modules Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Compiling pygtk Initial Comment: Hello, I wanted to install Narval from (www.logilab.org) I install Python 2.1 and i try to install pygtk. And i get this error Like i am a newbie it's perhaps nothing from python narval@tst03cn:~/install/pygtk-0.6.6$ make make all-recursive make[1]: Entering directory `/home/narval/install/pygtk-0.6.6' Making all in generate make[2]: Entering directory `/home/narval/install/pygtk-0.6.6/generate' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/narval/install/pygtk-0.6.6/generate' Making all in pyglade make[2]: Entering directory `/home/narval/install/pygtk-0.6.6/pyglade' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/narval/install/pygtk-0.6.6/pyglade' make[2]: Entering directory `/home/narval/install/pygtk-0.6.6' cd . && /usr/bin/python mkgtk.py 'import site' failed; use -v for traceback Traceback (innermost last): File "mkgtk.py", line 5, in ? import generate File "./generate/generate.py", line 1, in ? import os File "/home/narval/lib/python2.1/os.py", line 37 return [n for n in dir(module) if n[0] != '_'] ^ SyntaxError: invalid syntax make[2]: *** [gtkmodule_defs.c] Error 1 make[2]: Leaving directory `/home/narval/install/pygtk-0.6.6' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/narval/install/pygtk-0.6.6' make: *** [all-recursive-am] Error 2 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-24 11:08 Message: Logged In: YES user_id=21627 Since there was no feedback on whether the proposed fix solves the problem, I close the report. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-06-26 15:01 Message: Logged In: YES user_id=21627 You should be using Python 2.1 to execute this code. As you can see, /usr/bin/python mkgtk.py is invoked, which probably is not 2.1. Make sure your Python installation is found before /usr/bin/python is. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436103&group_id=5470 From noreply@sourceforge.net Tue Jul 24 19:14:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Jul 2001 11:14:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-444129 ] python20 dll not found Message-ID: Bugs item #444129, was opened at 2001-07-24 08:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 Category: Windows Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: python20 dll not found Initial Comment: after upgrading from 2.0 to 2.1 then to 2.1.1 getting error that cant find python20.dll. I completely removed all traces of python and did a fresh install even modified the registry and removed all instances of python and pywin. It is important to note that I also removed an re-installed win32all and it failed to completely install because this error. Another note though python will still run after the error is given the win32 extensions fail to load. I am running on japaneese version of win2000 but had the same problem on the english version(the steps mentioned fixed the problem on english version). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 11:14 Message: Logged In: NO Okay lets get more specific after installing 2.1.1 on top of 2.0 it worked I then uninstalled 2.0 and the error is back "python20.dll not found". I ran with -v option and the last lib to load before the error is UserDict. If I install 2.0 then 2.1.1 I seem to be ok with python then but if I try to install win32all it complains and fails stating incompatible dll message. Starting over I have uninstalled everything and re- installed 2.1.1 and have the same problem. the command I am running is... c:\python21\python.exe -v ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 10:35 Message: Logged In: NO As of my last attempt I was running nothing but BeOpen pyhton 2.1.1 (no third party libraries)on a clean system. The error occurs when I run python from the command line or IDLE. I rolled back to 2.0 then installed 2.1.1 on top of it just now and it seemed to fix python. I then installed win32all 140 and the install script throws a similar error saying "module use of python20.dll conflicts with this version of python". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 10:07 Message: Logged In: YES user_id=31435 Then we need more specific information from you. I've never heard of this and find it difficult to believe that anything in the std Python 2.1 distribution requires python20.dll. I just removed all traces of all Pythons from my Win2K box, installed a fresh 2.1.1, and ran the std test suite to completion without any problems. Exactly what do you do that triggers a msg about python20.dll? If I can't reproduce it (and so far I can't), all we can do is guess. Do you perhaps have your own customizations in a PYTHONSTARTUP file that may be trying to access obsolete stuff? Have you tried running Python with -v to get a trace of what it's trying to import? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-24 10:00 Message: Logged In: YES user_id=6380 Sorry to butt in... Are you perhaps trying to use a third party extension like PIL or Numeric Python? Or your own? Extensions built for one Python version won't work with another. Can you tell us exactly what you did that gave the error message? Preferably with the path to the executable that you are trying to run that gives the exception. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 09:54 Message: Logged In: NO I am in fact not using the wrong version of win32all, the problem occurs prior to the install of the extensions. And it is correct that the 2.0 dll's are not installed and python2.1.1 (or 2.1) is complaining about it. I originaly thought the same thing so I removed win32all and python2.1.1 unloaded the dll's and re-installed 2.1.1 prior to re-installing win32all I got the same errors. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 09:34 Message: Logged In: YES user_id=31435 It sounds like you're trying to use Python 2.1.1 with a version of win32all built for 2.0. If so, you can't do that -- Python 2.1.x supplies python21.dll, not python20.dll. Go to ActiveState's site and either install ActivePython from them (which comes with a matched set of components), or get build 140 of win32all.exe from them (which was built to work with Python 2.1 -- but won't work with Python 2.0). Feel free to reopen this bug report if that doesn't solve it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 From noreply@sourceforge.net Tue Jul 24 19:33:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Jul 2001 11:33:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-444201 ] Add Py-compile prefixes for getset Message-ID: Bugs item #444201, was opened at 2001-07-24 11:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444201&group_id=5470 Category: type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Add Py-compile prefixes for getset Initial Comment: The getset structure should have a Py-prefixed name. Ditto for structmember. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444201&group_id=5470 From noreply@sourceforge.net Tue Jul 24 20:12:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Jul 2001 12:12:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-444129 ] python20 dll not found Message-ID: Bugs item #444129, was opened at 2001-07-24 08:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 Category: Windows >Group: Irreproducible >Status: Open >Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: python20 dll not found Initial Comment: after upgrading from 2.0 to 2.1 then to 2.1.1 getting error that cant find python20.dll. I completely removed all traces of python and did a fresh install even modified the registry and removed all instances of python and pywin. It is important to note that I also removed an re-installed win32all and it failed to completely install because this error. Another note though python will still run after the error is given the win32 extensions fail to load. I am running on japaneese version of win2000 but had the same problem on the english version(the steps mentioned fixed the problem on english version). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-24 12:12 Message: Logged In: YES user_id=31435 I can't reproduce this on my system -- I see no problems at all. Can you capture the full output from running python - v and attach it to this report? I know exactly what's on my box, but can only guess about what's on yours. There are lots of clues in -v output that would help me. *Somehow* you're picking up an obsolete component, but there are no such components in the PythonLabs distribution. Note that "I then uninstalled 2.0" will cause registry entries to get restored to what they were at the time you first installed 2.0; that will wipe out the registry entries you created if you installed 2.1.1 before uninstalling 2.0. Anything relying on the registry *may* get screwed by that. Our (PythonLabs) distribution doesn't use the registry for much, but win32all may. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 11:14 Message: Logged In: NO Okay lets get more specific after installing 2.1.1 on top of 2.0 it worked I then uninstalled 2.0 and the error is back "python20.dll not found". I ran with -v option and the last lib to load before the error is UserDict. If I install 2.0 then 2.1.1 I seem to be ok with python then but if I try to install win32all it complains and fails stating incompatible dll message. Starting over I have uninstalled everything and re- installed 2.1.1 and have the same problem. the command I am running is... c:\python21\python.exe -v ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 10:35 Message: Logged In: NO As of my last attempt I was running nothing but BeOpen pyhton 2.1.1 (no third party libraries)on a clean system. The error occurs when I run python from the command line or IDLE. I rolled back to 2.0 then installed 2.1.1 on top of it just now and it seemed to fix python. I then installed win32all 140 and the install script throws a similar error saying "module use of python20.dll conflicts with this version of python". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 10:07 Message: Logged In: YES user_id=31435 Then we need more specific information from you. I've never heard of this and find it difficult to believe that anything in the std Python 2.1 distribution requires python20.dll. I just removed all traces of all Pythons from my Win2K box, installed a fresh 2.1.1, and ran the std test suite to completion without any problems. Exactly what do you do that triggers a msg about python20.dll? If I can't reproduce it (and so far I can't), all we can do is guess. Do you perhaps have your own customizations in a PYTHONSTARTUP file that may be trying to access obsolete stuff? Have you tried running Python with -v to get a trace of what it's trying to import? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-24 10:00 Message: Logged In: YES user_id=6380 Sorry to butt in... Are you perhaps trying to use a third party extension like PIL or Numeric Python? Or your own? Extensions built for one Python version won't work with another. Can you tell us exactly what you did that gave the error message? Preferably with the path to the executable that you are trying to run that gives the exception. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 09:54 Message: Logged In: NO I am in fact not using the wrong version of win32all, the problem occurs prior to the install of the extensions. And it is correct that the 2.0 dll's are not installed and python2.1.1 (or 2.1) is complaining about it. I originaly thought the same thing so I removed win32all and python2.1.1 unloaded the dll's and re-installed 2.1.1 prior to re-installing win32all I got the same errors. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 09:34 Message: Logged In: YES user_id=31435 It sounds like you're trying to use Python 2.1.1 with a version of win32all built for 2.0. If so, you can't do that -- Python 2.1.x supplies python21.dll, not python20.dll. Go to ActiveState's site and either install ActivePython from them (which comes with a matched set of components), or get build 140 of win32all.exe from them (which was built to work with Python 2.1 -- but won't work with Python 2.0). Feel free to reopen this bug report if that doesn't solve it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 From noreply@sourceforge.net Tue Jul 24 20:32:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Jul 2001 12:32:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-444229 ] 5 .__new__(list, '42') == 42 Message-ID: Bugs item #444229, was opened at 2001-07-24 12:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444229&group_id=5470 Category: type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: 5 .__new__(list, '42') == 42 Initial Comment: This expression should raise an exception, since list is not a subclass of int. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444229&group_id=5470 From noreply@sourceforge.net Tue Jul 24 22:39:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Jul 2001 14:39:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-438786 ] CVS 2.1.1c1 broken on osf1V4 Message-ID: Bugs item #438786, was opened at 2001-07-05 07:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Martin v. Löwis (loewis) Summary: CVS 2.1.1c1 broken on osf1V4 Initial Comment: As of right now, the CVS branch for the 2.1 bugfix release cannot import the math module on my Digital Unix platform. ImportError: Unresolved symbol in /tmp_mnt/home/gball/usr/src/python/dist/src/build/lib.osf1-V4.0-alpha-2.1/math.so: __eprintf uname is OSF1 surya V4.0 878 alpha ---------------------------------------------------------------------- >Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-24 14:39 Message: Logged In: YES user_id=11365 I tried testing that patch and it sucked. I'll try again. ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-24 11:06 Message: Logged In: YES user_id=11365 Doh! Now it's uploaded. Sorry for the extra traffic. ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-24 11:05 Message: Logged In: YES user_id=11365 Next patch uploaded. ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-24 11:04 Message: Logged In: YES user_id=11365 Yes, the patch works and make test fails only on test_format, I believe this is a known platform C library bug. I have attached a patch for the setup.py in python/dist/src. It touches code which is supposed to allow variables set on the make commandline to have effect. I see two issues with it. One, it effectively replaces CC and OPT from the Makefile with just CC. This is inconsistent with the behaviour of the Makefile and configure. My setup.patch addresses this. Two, it doesn't really do what it says, because the variable it picks up from the environment can has not necessarily got there through a commandline argument to make. This only becomes a problem when configure decides to ignore an environment variable, as was the case on OSF. Martin's patch stops this from happening on OSF, but the code is still fragile. Here's an idea: make should always export its value of CC into the environment of subprocesses. Using Gnu make I'd do this with an 'export' directive. I'll next send a patch to Makefile.pre.in which should do the job portably but it isn't especially pretty. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-24 00:11 Message: Logged In: YES user_id=21627 Gregory, can you please try the attached patch, and report whether it changes anything? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 13:33 Message: Logged In: YES user_id=6380 I don't recall why that was. It was 6 years ago! Quite possibly things have changed; the OSF in use now is probably quite different than the one then. So, Martin, try to back out the change and see if this doesn't break other things. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-19 12:38 Message: Logged In: YES user_id=21627 This seems to originate fromt the fragment OSF1) CC=cc without_gcc=;; which was introduced in configure.in 1.23, with the comment on osf/1, never use gcc Therefore, I'm assigning it to Guido. My proposal is to close this as "won't fix" - if setting CC doesn't work, just don't do that. Alternatively, if nobody can remember why gcc should not be used on OSF/1, it might be reasonable to back-out this change. ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-19 12:12 Message: Logged In: YES user_id=11365 I just checked out the 2.1.1 branch again and it still seems to be broken. After a fresh config with $CC set to gcc in the environment, the Makefile contains CC= cc OPT= -O -Olimit 1500 CCSHARED= so it looks like configure has decided to use cc and chosen flags for that compiler. Then, the actual build command lines look like gcc -I. -I/tmp_mnt/home/gball/usr/src/python/dist/src/./Include -I/usr/local/include -IInclude/ -c /tmp_mnt/home/gball/usr/src/python/dist/src/Modules/fpectlmodule.c -o build/temp.osf1-V4.0-alpha-2.1/fpectlmodule.o i.e. just "gcc" instead of "cc -O -Olimit 1500" so it looks like the environment variable gets pulled in only at the last moment and replaces $(CC), $(OPT) and possibly $(CCSHARED), thereby throwing away the work done by configure. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-19 02:59 Message: Logged In: YES user_id=34209 Gregory, did you get a chance to test the patch attached to bug #437487, or the 2.1.1 CVS tree ? I'd like to know if this is fixed in 2.1.1. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-16 08:56 Message: Logged In: YES user_id=34209 Ah, yes, that sounds very plausible. The fix for that problem, which was checked in on the trunk, will be in Python 2.1.1-final as well. The Solaris bugreport has a patch attached to it; could you test it to see if it solves your 2.1.1c1 problem ? ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-09 08:48 Message: Logged In: YES user_id=11365 The problem goes away if I clear $CC instead of having it set to gcc. There's a similar problem on Solaris reported recently. I think the configure script should try to spot this sort of thing, but I suppose that's an Autoconf feature request, not a python bug... Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-08 14:06 Message: Logged In: YES user_id=21627 This sounds like a bug in your compiler installation. __eprintf is typically defined in libgcc.a; make sure you use a consistent compiler capable of building binaries for your system throughout the build process. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 From noreply@sourceforge.net Tue Jul 24 23:35:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Jul 2001 15:35:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-443866 ] Evaluating func_code causing core dump Message-ID: Bugs item #443866, was opened at 2001-07-23 10:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443866&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jonathan Hogg (jhogg) >Assigned to: Jeremy Hylton (jhylton) Summary: Evaluating func_code causing core dump Initial Comment: Python 2.2a1 (#1, Jul 19 2001, 18:18:51) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)] on linux2 The intepreter dies hard if you directly evaluate the func_code of a function that has a closure. E.g.: ----- def func1(): return lambda: 4 + y f = func1() print "Ugly test 1:", eval( f.func_code, {'y': 38} ) def func2(x): return lambda: x + y f = func2(4) print "Ugly test 2:", eval( f.func_code, {'y': 38} ) ----- The second eval will cause a core dump on UNIX. The offending code is in PyEval_EvalCodeEx() of ceval.c line 2466. This loop attempts to match free vars against the closure, but the closure is NULL if the function is called with eval. I know this is very broken usage of the interpreter, but it should die more cleanly than a core dump ;-) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-24 15:35 Message: Logged In: YES user_id=31435 Assigned to Jeremy in the hopes this will speed his return to us . ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443866&group_id=5470 From noreply@sourceforge.net Wed Jul 25 08:48:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Jul 2001 00:48:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-438786 ] CVS 2.1.1c1 broken on osf1V4 Message-ID: Bugs item #438786, was opened at 2001-07-05 07:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Martin v. Löwis (loewis) Summary: CVS 2.1.1c1 broken on osf1V4 Initial Comment: As of right now, the CVS branch for the 2.1 bugfix release cannot import the math module on my Digital Unix platform. ImportError: Unresolved symbol in /tmp_mnt/home/gball/usr/src/python/dist/src/build/lib.osf1-V4.0-alpha-2.1/math.so: __eprintf uname is OSF1 surya V4.0 878 alpha ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-25 00:48 Message: Logged In: YES user_id=21627 osf.patch was committed as 1.235. As for the changes to setup.py and Makefile.pre.in: I cannot understand what problem they solve. Please demonstrate the bug that is fixed with these changes in more detail (i.e. what is the setting of your environment variables, and what unexpected results do you get without these changes). ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-24 14:39 Message: Logged In: YES user_id=11365 I tried testing that patch and it sucked. I'll try again. ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-24 11:06 Message: Logged In: YES user_id=11365 Doh! Now it's uploaded. Sorry for the extra traffic. ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-24 11:05 Message: Logged In: YES user_id=11365 Next patch uploaded. ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-24 11:04 Message: Logged In: YES user_id=11365 Yes, the patch works and make test fails only on test_format, I believe this is a known platform C library bug. I have attached a patch for the setup.py in python/dist/src. It touches code which is supposed to allow variables set on the make commandline to have effect. I see two issues with it. One, it effectively replaces CC and OPT from the Makefile with just CC. This is inconsistent with the behaviour of the Makefile and configure. My setup.patch addresses this. Two, it doesn't really do what it says, because the variable it picks up from the environment can has not necessarily got there through a commandline argument to make. This only becomes a problem when configure decides to ignore an environment variable, as was the case on OSF. Martin's patch stops this from happening on OSF, but the code is still fragile. Here's an idea: make should always export its value of CC into the environment of subprocesses. Using Gnu make I'd do this with an 'export' directive. I'll next send a patch to Makefile.pre.in which should do the job portably but it isn't especially pretty. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-24 00:11 Message: Logged In: YES user_id=21627 Gregory, can you please try the attached patch, and report whether it changes anything? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-19 13:33 Message: Logged In: YES user_id=6380 I don't recall why that was. It was 6 years ago! Quite possibly things have changed; the OSF in use now is probably quite different than the one then. So, Martin, try to back out the change and see if this doesn't break other things. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-19 12:38 Message: Logged In: YES user_id=21627 This seems to originate fromt the fragment OSF1) CC=cc without_gcc=;; which was introduced in configure.in 1.23, with the comment on osf/1, never use gcc Therefore, I'm assigning it to Guido. My proposal is to close this as "won't fix" - if setting CC doesn't work, just don't do that. Alternatively, if nobody can remember why gcc should not be used on OSF/1, it might be reasonable to back-out this change. ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-19 12:12 Message: Logged In: YES user_id=11365 I just checked out the 2.1.1 branch again and it still seems to be broken. After a fresh config with $CC set to gcc in the environment, the Makefile contains CC= cc OPT= -O -Olimit 1500 CCSHARED= so it looks like configure has decided to use cc and chosen flags for that compiler. Then, the actual build command lines look like gcc -I. -I/tmp_mnt/home/gball/usr/src/python/dist/src/./Include -I/usr/local/include -IInclude/ -c /tmp_mnt/home/gball/usr/src/python/dist/src/Modules/fpectlmodule.c -o build/temp.osf1-V4.0-alpha-2.1/fpectlmodule.o i.e. just "gcc" instead of "cc -O -Olimit 1500" so it looks like the environment variable gets pulled in only at the last moment and replaces $(CC), $(OPT) and possibly $(CCSHARED), thereby throwing away the work done by configure. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-19 02:59 Message: Logged In: YES user_id=34209 Gregory, did you get a chance to test the patch attached to bug #437487, or the 2.1.1 CVS tree ? I'd like to know if this is fixed in 2.1.1. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-07-16 08:56 Message: Logged In: YES user_id=34209 Ah, yes, that sounds very plausible. The fix for that problem, which was checked in on the trunk, will be in Python 2.1.1-final as well. The Solaris bugreport has a patch attached to it; could you test it to see if it solves your 2.1.1c1 problem ? ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2001-07-09 08:48 Message: Logged In: YES user_id=11365 The problem goes away if I clear $CC instead of having it set to gcc. There's a similar problem on Solaris reported recently. I think the configure script should try to spot this sort of thing, but I suppose that's an Autoconf feature request, not a python bug... Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-08 14:06 Message: Logged In: YES user_id=21627 This sounds like a bug in your compiler installation. __eprintf is typically defined in libgcc.a; make sure you use a consistent compiler capable of building binaries for your system throughout the build process. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470 From noreply@sourceforge.net Wed Jul 25 15:55:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Jul 2001 07:55:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-444486 ] Potential leak in Py_InitModule4() Message-ID: Bugs item #444486, was opened at 2001-07-25 07:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444486&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 3 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: Potential leak in Py_InitModule4() Initial Comment: Martin Sjögren discovered that Py_InitModule4() doesn't DECREF v when either of the PyDict_SetItemString() calls fails. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444486&group_id=5470 From noreply@sourceforge.net Wed Jul 25 16:05:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Jul 2001 08:05:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-444493 ] u'\U00010001' segfaults with current CVS Message-ID: Bugs item #444493, was opened at 2001-07-25 08:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444493&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: u'\U00010001' segfaults with current CVS Initial Comment: The current CVS version segfaults simply by entering u'\U00010001' in the interactive session. Lib/test/test_unicode.py fails too. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444493&group_id=5470 From noreply@sourceforge.net Wed Jul 25 16:05:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Jul 2001 08:05:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-444493 ] u'\U00010001' segfaults with current CVS Message-ID: Bugs item #444493, was opened at 2001-07-25 08:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444493&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: u'\U00010001' segfaults with current CVS Initial Comment: The current CVS version segfaults simply by entering u'\U00010001' in the interactive session. Lib/test/test_unicode.py fails too. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2001-07-25 08:05 Message: Logged In: YES user_id=89016 BTW, I used a UCS4 build. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444493&group_id=5470 From noreply@sourceforge.net Wed Jul 25 17:03:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Jul 2001 09:03:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-444510 ] int() should guarantee truncation Message-ID: Bugs item #444510, was opened at 2001-07-25 09:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444510&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: int() should guarantee truncation Initial Comment: The int() function currently warns that it cannot guarantee truncation because C doesn't guarantee it. However, all known (to us) C implementations *do* truncate, and the C99 standard requires it, so we might as well change the code to promise truncation and tighten the docs. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444510&group_id=5470 From noreply@sourceforge.net Wed Jul 25 17:04:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Jul 2001 09:04:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-444512 ] pydoc: Mozilla does not use localhost Message-ID: Bugs item #444512, was opened at 2001-07-25 09:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444512&group_id=5470 Category: demos and tools Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc: Mozilla does not use localhost Initial Comment: pydoc gives the browser the argument "http://localhost:7464/". However, Mozilla does not support localhost browsing yet (bug 86449 in Bugzilla), so this does not work. Here is how to fix it: replace line 1591 in pydoc.py host = (sys.platform == 'mac') and '127.0.0.1' or 'localhost' by if (sys.platform == 'mac'): host = '127.0.0.1' else: if (sys.platform == 'linux2'): from socket import gethostname host = gethostname() else: host = 'localhost' ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444512&group_id=5470 From noreply@sourceforge.net Wed Jul 25 17:08:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Jul 2001 09:08:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-444493 ] u'\U00010001' segfaults with current CVS Message-ID: Bugs item #444493, was opened at 2001-07-25 08:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444493&group_id=5470 Category: Unicode Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: u'\U00010001' segfaults with current CVS Initial Comment: The current CVS version segfaults simply by entering u'\U00010001' in the interactive session. Lib/test/test_unicode.py fails too. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-25 09:08 Message: Logged In: YES user_id=38388 The bug only showed up in UCS-4 builds due to a missing resize in the codec. The tests also showed that the raw-unicode-escape codec is not round-trip safe on UCS-4 builds. Fixed the first part, removed the raw-unicode-escape codec from the tests for the second part. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-07-25 08:05 Message: Logged In: YES user_id=89016 BTW, I used a UCS4 build. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444493&group_id=5470 From noreply@sourceforge.net Wed Jul 25 17:10:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Jul 2001 09:10:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-444514 ] raw-unicode-escape codec fails roundtrip Message-ID: Bugs item #444514, was opened at 2001-07-25 09:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444514&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: M.-A. Lemburg (lemburg) Summary: raw-unicode-escape codec fails roundtrip Initial Comment: On wide Python builds, the raw-unicode-escape codec fails the round-trip for non-BMP code points. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444514&group_id=5470 From noreply@sourceforge.net Wed Jul 25 17:49:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Jul 2001 09:49:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-444129 ] python20 dll not found Message-ID: Bugs item #444129, was opened at 2001-07-24 08:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 Category: Windows Group: Irreproducible Status: Open Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: python20 dll not found Initial Comment: after upgrading from 2.0 to 2.1 then to 2.1.1 getting error that cant find python20.dll. I completely removed all traces of python and did a fresh install even modified the registry and removed all instances of python and pywin. It is important to note that I also removed an re-installed win32all and it failed to completely install because this error. Another note though python will still run after the error is given the win32 extensions fail to load. I am running on japaneese version of win2000 but had the same problem on the english version(the steps mentioned fixed the problem on english version). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-25 09:49 Message: Logged In: NO Here is the exact output displayed upon executing "python - v" E:\Python21>python -v # E:\Python21\lib\site.pyc matches E:\Python21\lib\site.py import site # precompiled from E:\Python21\lib\site.pyc # E:\Python21\lib\os.pyc matches E:\Python21\lib\os.py import os # precompiled from E:\Python21\lib\os.pyc import nt # builtin # E:\Python21\lib\ntpath.pyc matches E:\Python21 \lib\ntpath.py import ntpath # precompiled from E:\Python21\lib\ntpath.pyc # E:\Python21\lib\stat.pyc matches E:\Python21\lib\stat.py import stat # precompiled from E:\Python21\lib\stat.pyc # E:\Python21\lib\UserDict.pyc matches E:\Python21 \lib\UserDict.py import UserDict # precompiled from E:\Python21 \lib\UserDict.pyc Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> Here is the additional error that appears displayed in a Windows dialog box. I have not typed it in "exactly" as it appears. The dots (...........) below represent a bunch of lines with directory paths: Dialog Box Title: Dynamic Library python20.dll path not found ============================================================ Dynamic Library python20.dll path not found. e:\su5j\security\test\bin................................... ............................................................ .......... ............................................................ ............................................................ ............................... e:\Program Files\Microsoft Visual Studio\Common\msdev98 \BIN\;T:\tools\bin; c:\ATF ============================================================ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 12:12 Message: Logged In: YES user_id=31435 I can't reproduce this on my system -- I see no problems at all. Can you capture the full output from running python - v and attach it to this report? I know exactly what's on my box, but can only guess about what's on yours. There are lots of clues in -v output that would help me. *Somehow* you're picking up an obsolete component, but there are no such components in the PythonLabs distribution. Note that "I then uninstalled 2.0" will cause registry entries to get restored to what they were at the time you first installed 2.0; that will wipe out the registry entries you created if you installed 2.1.1 before uninstalling 2.0. Anything relying on the registry *may* get screwed by that. Our (PythonLabs) distribution doesn't use the registry for much, but win32all may. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 11:14 Message: Logged In: NO Okay lets get more specific after installing 2.1.1 on top of 2.0 it worked I then uninstalled 2.0 and the error is back "python20.dll not found". I ran with -v option and the last lib to load before the error is UserDict. If I install 2.0 then 2.1.1 I seem to be ok with python then but if I try to install win32all it complains and fails stating incompatible dll message. Starting over I have uninstalled everything and re- installed 2.1.1 and have the same problem. the command I am running is... c:\python21\python.exe -v ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 10:35 Message: Logged In: NO As of my last attempt I was running nothing but BeOpen pyhton 2.1.1 (no third party libraries)on a clean system. The error occurs when I run python from the command line or IDLE. I rolled back to 2.0 then installed 2.1.1 on top of it just now and it seemed to fix python. I then installed win32all 140 and the install script throws a similar error saying "module use of python20.dll conflicts with this version of python". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 10:07 Message: Logged In: YES user_id=31435 Then we need more specific information from you. I've never heard of this and find it difficult to believe that anything in the std Python 2.1 distribution requires python20.dll. I just removed all traces of all Pythons from my Win2K box, installed a fresh 2.1.1, and ran the std test suite to completion without any problems. Exactly what do you do that triggers a msg about python20.dll? If I can't reproduce it (and so far I can't), all we can do is guess. Do you perhaps have your own customizations in a PYTHONSTARTUP file that may be trying to access obsolete stuff? Have you tried running Python with -v to get a trace of what it's trying to import? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-24 10:00 Message: Logged In: YES user_id=6380 Sorry to butt in... Are you perhaps trying to use a third party extension like PIL or Numeric Python? Or your own? Extensions built for one Python version won't work with another. Can you tell us exactly what you did that gave the error message? Preferably with the path to the executable that you are trying to run that gives the exception. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 09:54 Message: Logged In: NO I am in fact not using the wrong version of win32all, the problem occurs prior to the install of the extensions. And it is correct that the 2.0 dll's are not installed and python2.1.1 (or 2.1) is complaining about it. I originaly thought the same thing so I removed win32all and python2.1.1 unloaded the dll's and re-installed 2.1.1 prior to re-installing win32all I got the same errors. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 09:34 Message: Logged In: YES user_id=31435 It sounds like you're trying to use Python 2.1.1 with a version of win32all built for 2.0. If so, you can't do that -- Python 2.1.x supplies python21.dll, not python20.dll. Go to ActiveState's site and either install ActivePython from them (which comes with a matched set of components), or get build 140 of win32all.exe from them (which was built to work with Python 2.1 -- but won't work with Python 2.0). Feel free to reopen this bug report if that doesn't solve it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 From noreply@sourceforge.net Wed Jul 25 18:41:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Jul 2001 10:41:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-444129 ] python20 dll not found Message-ID: Bugs item #444129, was opened at 2001-07-24 08:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 Category: Windows Group: Irreproducible Status: Open Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Mark Hammond (mhammond) Summary: python20 dll not found Initial Comment: after upgrading from 2.0 to 2.1 then to 2.1.1 getting error that cant find python20.dll. I completely removed all traces of python and did a fresh install even modified the registry and removed all instances of python and pywin. It is important to note that I also removed an re-installed win32all and it failed to completely install because this error. Another note though python will still run after the error is given the win32 extensions fail to load. I am running on japaneese version of win2000 but had the same problem on the english version(the steps mentioned fixed the problem on english version). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-25 10:41 Message: Logged In: YES user_id=31435 Assigned to Mark: can you make sense of this? I have to figure it has *something* to do with win32all, because this is the only report of its kind, and the -v output below shows that the base distribution is acting normally in all respects, including getting to the interactive prompt without trouble. Anonymous, do you use a PYTHONSTARTUP file? I asked before, but didn't hear back. That's the only way I know of in the std distribution to execute some Python code at startup that doesn't get mentioned in the -v outpout. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-25 09:49 Message: Logged In: NO Here is the exact output displayed upon executing "python - v" E:\Python21>python -v # E:\Python21\lib\site.pyc matches E:\Python21\lib\site.py import site # precompiled from E:\Python21\lib\site.pyc # E:\Python21\lib\os.pyc matches E:\Python21\lib\os.py import os # precompiled from E:\Python21\lib\os.pyc import nt # builtin # E:\Python21\lib\ntpath.pyc matches E:\Python21 \lib\ntpath.py import ntpath # precompiled from E:\Python21\lib\ntpath.pyc # E:\Python21\lib\stat.pyc matches E:\Python21\lib\stat.py import stat # precompiled from E:\Python21\lib\stat.pyc # E:\Python21\lib\UserDict.pyc matches E:\Python21 \lib\UserDict.py import UserDict # precompiled from E:\Python21 \lib\UserDict.pyc Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> Here is the additional error that appears displayed in a Windows dialog box. I have not typed it in "exactly" as it appears. The dots (...........) below represent a bunch of lines with directory paths: Dialog Box Title: Dynamic Library python20.dll path not found ============================================================ Dynamic Library python20.dll path not found. e:\su5j\security\test\bin................................... ............................................................ .......... ............................................................ ............................................................ ............................... e:\Program Files\Microsoft Visual Studio\Common\msdev98 \BIN\;T:\tools\bin; c:\ATF ============================================================ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 12:12 Message: Logged In: YES user_id=31435 I can't reproduce this on my system -- I see no problems at all. Can you capture the full output from running python - v and attach it to this report? I know exactly what's on my box, but can only guess about what's on yours. There are lots of clues in -v output that would help me. *Somehow* you're picking up an obsolete component, but there are no such components in the PythonLabs distribution. Note that "I then uninstalled 2.0" will cause registry entries to get restored to what they were at the time you first installed 2.0; that will wipe out the registry entries you created if you installed 2.1.1 before uninstalling 2.0. Anything relying on the registry *may* get screwed by that. Our (PythonLabs) distribution doesn't use the registry for much, but win32all may. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 11:14 Message: Logged In: NO Okay lets get more specific after installing 2.1.1 on top of 2.0 it worked I then uninstalled 2.0 and the error is back "python20.dll not found". I ran with -v option and the last lib to load before the error is UserDict. If I install 2.0 then 2.1.1 I seem to be ok with python then but if I try to install win32all it complains and fails stating incompatible dll message. Starting over I have uninstalled everything and re- installed 2.1.1 and have the same problem. the command I am running is... c:\python21\python.exe -v ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 10:35 Message: Logged In: NO As of my last attempt I was running nothing but BeOpen pyhton 2.1.1 (no third party libraries)on a clean system. The error occurs when I run python from the command line or IDLE. I rolled back to 2.0 then installed 2.1.1 on top of it just now and it seemed to fix python. I then installed win32all 140 and the install script throws a similar error saying "module use of python20.dll conflicts with this version of python". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 10:07 Message: Logged In: YES user_id=31435 Then we need more specific information from you. I've never heard of this and find it difficult to believe that anything in the std Python 2.1 distribution requires python20.dll. I just removed all traces of all Pythons from my Win2K box, installed a fresh 2.1.1, and ran the std test suite to completion without any problems. Exactly what do you do that triggers a msg about python20.dll? If I can't reproduce it (and so far I can't), all we can do is guess. Do you perhaps have your own customizations in a PYTHONSTARTUP file that may be trying to access obsolete stuff? Have you tried running Python with -v to get a trace of what it's trying to import? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-24 10:00 Message: Logged In: YES user_id=6380 Sorry to butt in... Are you perhaps trying to use a third party extension like PIL or Numeric Python? Or your own? Extensions built for one Python version won't work with another. Can you tell us exactly what you did that gave the error message? Preferably with the path to the executable that you are trying to run that gives the exception. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 09:54 Message: Logged In: NO I am in fact not using the wrong version of win32all, the problem occurs prior to the install of the extensions. And it is correct that the 2.0 dll's are not installed and python2.1.1 (or 2.1) is complaining about it. I originaly thought the same thing so I removed win32all and python2.1.1 unloaded the dll's and re-installed 2.1.1 prior to re-installing win32all I got the same errors. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 09:34 Message: Logged In: YES user_id=31435 It sounds like you're trying to use Python 2.1.1 with a version of win32all built for 2.0. If so, you can't do that -- Python 2.1.x supplies python21.dll, not python20.dll. Go to ActiveState's site and either install ActivePython from them (which comes with a matched set of components), or get build 140 of win32all.exe from them (which was built to work with Python 2.1 -- but won't work with Python 2.0). Feel free to reopen this bug report if that doesn't solve it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 From noreply@sourceforge.net Wed Jul 25 21:31:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Jul 2001 13:31:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-444589 ] install_data.py does not record dirs Message-ID: Bugs item #444589, was opened at 2001-07-25 13:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444589&group_id=5470 Category: Distutils Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jon Nelson (jnelson) Assigned to: A.M. Kuchling (akuchling) Summary: install_data.py does not record dirs Initial Comment: Let's say I want to create a directory but not put anything in it. Logically, I would add: data_files = [ ('directory', [] ) ], to my setup.py file. However, it doesn't work. The following small patch allows special behavior for empty file lists. It is quite useful for normal installs, as well as for bdist and friends. --- install_data.py.orig Wed Jul 25 15:27:19 2001 +++ install_data.py Wed Jul 25 15:26:54 2001 @@ -63,6 +63,8 @@ elif self.root: dir = change_root(self.root, dir) self.mkpath(dir) + if f[1] == []: + self.outfiles.append(dir) for data in f[1]: data = convert_path(data) (out, _) = self.copy_file(data, dir) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444589&group_id=5470 From noreply@sourceforge.net Wed Jul 25 21:35:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Jul 2001 13:35:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-436732 ] install.py does not record path file Message-ID: Bugs item #436732, was opened at 2001-06-27 07:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436732&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jon Nelson (jnelson) Assigned to: Greg Ward (gward) Summary: install.py does not record path file Initial Comment: install.py does not record in INSTALLED_FILES when it creates the .pth file which is created when extra_path is used. Included is a patch: --- install.py.orig Wed Jun 27 08:55:39 2001 +++ install.py Wed Jun 27 08:56:30 2001 @@ -489,6 +489,9 @@ # write list of installed files, if requested. if self.record: outputs = self.get_outputs() + if self.path_file and self.install_path_file: + outputs.append(os.path.join(self.install_libbase, + self.path_file + ".pth")) if self.root: # strip any package prefix root_len = len(self.root) for counter in xrange(len(outputs)): ---------------------------------------------------------------------- >Comment By: Jon Nelson (jnelson) Date: 2001-07-25 13:35 Message: Logged In: YES user_id=8446 Is anything going to be done about this? It's really quite necessary. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=436732&group_id=5470 From noreply@sourceforge.net Wed Jul 25 22:01:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Jul 2001 14:01:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-443120 ] denial-of-service attack to cgi.py Message-ID: Bugs item #443120, was opened at 2001-07-20 09:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443120&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) >Assigned to: Guido van Rossum (gvanrossum) Summary: denial-of-service attack to cgi.py Initial Comment: I got this in the mail: """ Subject: Bug in cgi.py, denial-of-service possible From: Richard Jones To: guido@python.org, support@digicool.com Date: Fri, 20 Jul 2001 17:43:15 +1000 The inner workings of cgi.py are still a mystery to me, so I can't offer a patch. Sorry. The following code will effect a denial-of-service against any server running cgi.py (and hence Zope). import httplib params = '\n'*10 h = httplib.HTTP('localhost', 8080) h.putrequest('POST', '/') h.putheader('Content-type', 'multipart/form-data') h.putheader('Content-length', str(len(params))) h.endheaders() h.send(params) The key here is the missing boundary from the content-type header. From my observation, it seems that cgi.py defaults the boundary to "" which means that it matches boundaries without progressing through the input - creating new FieldStorage instances for each match. The result is all available RAM gobbled up eventually. I recommend testing this on a system on which you can easily kill the server process. Richard -- Richard Jones richard@bizarsoftware.com.au Senior Software Developer, Bizar Software (www.bizarsoftware.com.au) """ ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-25 14:01 Message: Logged In: YES user_id=6380 Fixed by a more elaborate patch from the hand of Evan Simpson, cgi rev. 1.65. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2001-07-22 18:48 Message: Logged In: YES user_id=6405 This is a patch - it's against a patched cgi.py (I've applied the fix for "too many open files"). RFC 2046 requires a boundary argument for the multipart content types (http://www.ietf.org/rfc/rfc2046.txt, 5.1.1, second paragraph). This patch does fix the given exploit. *** /usr/lib/python2.1/cgi.py Tue Jul 10 14:29:37 2001 --- cgi.py Mon Jul 23 11:37:45 2001 *************** *** 514,519 **** --- 514,521 ---- if ctype == 'application/x-www-form-urlencoded': self.read_urlencoded() elif ctype[:10] == 'multipart/': + if not self.innerboundary: + raise ValueError, 'multipart message with no boundary' self.read_multi(environ, keep_blank_values, strict_parsing) else: self.read_single() ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443120&group_id=5470 From noreply@sourceforge.net Thu Jul 26 05:58:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Jul 2001 21:58:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-443005 ] 2.2a1: crash via posix_do_stat Message-ID: Bugs item #443005, was opened at 2001-07-20 01:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443005&group_id=5470 Category: Python Interpreter Core Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Uwe Zessin (zessin_5) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2a1: crash via posix_do_stat Initial Comment: I've done a port to OpenVMS. I get a crash during Python initialization (import of SITE.PY). A work-around for me is to replace the format-string for posix_do_stat() of "et" with "s". Here is the traceback. I have removed the line numbers, because they apply to the compiler listings. $ python %SYSTEM-F-ACCVIO, access violation, ... %TRACE-F-TRACEBACK, symbolic stack dump follows image module routine PYTHON GETARGS convertsimple PYTHON GETARGS convertitem PYTHON GETARGS vgetargs1 PYTHON GETARGS PyArg_ParseTuple PYTHON POSIXMODULE posix_do_stat PYTHON POSIXMODULE posix_stat PYTHON CEVAL call_cfunction PYTHON CEVAL eval_frame PYTHON CEVAL PyEval_EvalCodeEx PYTHON CEVAL fast_function PYTHON CEVAL eval_frame PYTHON CEVAL PyEval_EvalCodeEx PYTHON CEVAL PyEval_EvalCode PYTHON IMPORT PyImport_ExecCodeModuleEx PYTHON IMPORT load_source_module PYTHON IMPORT load_module PYTHON IMPORT import_submodule PYTHON IMPORT load_next PYTHON IMPORT import_module_ex PYTHON IMPORT PyImport_ImportModuleEx PYTHON BLTINMODULE builtin___import__ PYTHON METHODOBJECT meth_call PYTHON ABSTRACT PyObject_Call PYTHON CEVAL PyEval_CallObjectWithKeywords PYTHON ABSTRACT PyObject_CallObject PYTHON ABSTRACT PyObject_CallFunction PYTHON IMPORT PyImport_Import PYTHON IMPORT PyImport_ImportModule PYTHON PYTHONRUN initsite PYTHON PYTHONRUN Py_Initialize PYTHON MAIN Py_Main PYTHON PYTHON main PYTHON PYTHON __main And here is the failing code in GETARGS.C: if ((int)strlen(PyString_AS_STRING(s)) != size) return converterr( "(encoded string without NULL b... arg, msgbuf); -> *buffer = PyMem_NEW(char, size + 1); if (*buffer == NULL) { Py_DECREF(s); return converterr("(memory error)", arg, msgbuf); } ----- I'm sorry, but I can't debug that any better. ---------------------------------------------------------------------- >Comment By: Uwe Zessin (zessin_5) Date: 2001-07-25 21:58 Message: Logged In: YES user_id=155755 Problem found. I was using a modified copy of posix_do_stat() and missed the change to PyArg_ParseTuple (new parameter 'Py_FileSystemDefaultEncoding'). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-20 09:17 Message: Logged In: YES user_id=6380 I'm sorry, but I can't debug that any better either. There's nothing suspicious about the indicated line. Lowering the priority. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443005&group_id=5470 From noreply@sourceforge.net Thu Jul 26 06:27:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Jul 2001 22:27:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-444683 ] IDLE starts too late to enable "yield" Message-ID: Bugs item #444683, was opened at 2001-07-25 22:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444683&group_id=5470 Category: IDLE Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: IDLE starts too late to enable "yield" Initial Comment: In attempting to test the use of the new generators, it seems that IDLE is too far into its operation to allow "yield" with something like: from __future__ import generators It would be nice to know how to enable it in IDLE. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444683&group_id=5470 From noreply@sourceforge.net Thu Jul 26 07:02:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Jul 2001 23:02:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-444683 ] IDLE starts too late to enable "yield" Message-ID: Bugs item #444683, was opened at 2001-07-25 22:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444683&group_id=5470 Category: IDLE Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) >Summary: IDLE starts too late to enable "yield" Initial Comment: In attempting to test the use of the new generators, it seems that IDLE is too far into its operation to allow "yield" with something like: from __future__ import generators It would be nice to know how to enable it in IDLE. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-25 23:02 Message: Logged In: YES user_id=31435 Yes, this is a *general* issue with the future statement, and explained in the future-statement PEP. It's not really IDLE's problem (neither the cause nor the cure); it's a problem for all simulated (non-native) shells, including doctest.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444683&group_id=5470 From noreply@sourceforge.net Thu Jul 26 09:27:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 01:27:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-444707 ] cgi.escape() should replace single quote Message-ID: Bugs item #444707, was opened at 2001-07-26 01:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444707&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Artur Zaprzala (zybi) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.escape() should replace single quote Initial Comment: escape function from cgi module should be able to replace signle quotation marks with ' as they are allowed as HTML element attribute delimiters. Reference: http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444707&group_id=5470 From noreply@sourceforge.net Thu Jul 26 12:53:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 04:53:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-444683 ] IDLE starts too late to enable "yield" Message-ID: Bugs item #444683, was opened at 2001-07-25 22:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444683&group_id=5470 Category: IDLE Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: IDLE starts too late to enable "yield" Initial Comment: In attempting to test the use of the new generators, it seems that IDLE is too far into its operation to allow "yield" with something like: from __future__ import generators It would be nice to know how to enable it in IDLE. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-07-26 04:53 Message: Logged In: YES user_id=6656 I've come up with a way to do this. It's a bit gross, although it does seem to work: [mwh@starship src]$ ./python Lib/code.py Python 2.2a0 (#1, Jul 26 2001, 07:37:26) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> yield 1 :1: Warning: 'yield' will become a reserved keyword in the future :1: Warning: 'yield' will become a reserved keyword in the future :1: Warning: 'yield' will become a reserved keyword in the future File "", line 1 yield 1 ^ SyntaxError: invalid syntax >>> from __future__ import generators >>> yield 1 SyntaxError: 'yield' outside function >>> (I can't test it in Idle 'cause I'm on a dial-up connection to the starship) Anyway, see it here: http://starship.python.net/crew/mwh/hacks/codeop-hack.diff As well as the inherent unpleasantness, adding this global state to codeop.py sucks rather, too. But doing a better job would mean creating some kind of object interface and then getting Idle to use it, and I'm too lazy (especially if the idea is going to get thrown out anyway). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-25 23:02 Message: Logged In: YES user_id=31435 Yes, this is a *general* issue with the future statement, and explained in the future-statement PEP. It's not really IDLE's problem (neither the cause nor the cure); it's a problem for all simulated (non-native) shells, including doctest.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444683&group_id=5470 From noreply@sourceforge.net Thu Jul 26 14:16:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 06:16:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-444683 ] IDLE starts too late to enable "yield" Message-ID: Bugs item #444683, was opened at 2001-07-25 22:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444683&group_id=5470 Category: IDLE Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) >Summary: IDLE starts too late to enable "yield" Initial Comment: In attempting to test the use of the new generators, it seems that IDLE is too far into its operation to allow "yield" with something like: from __future__ import generators It would be nice to know how to enable it in IDLE. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 06:16 Message: Logged In: YES user_id=6380 A simple solution would be to add the future statement to codeop.py, but of course that has other disadvantages. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-07-26 04:53 Message: Logged In: YES user_id=6656 I've come up with a way to do this. It's a bit gross, although it does seem to work: [mwh@starship src]$ ./python Lib/code.py Python 2.2a0 (#1, Jul 26 2001, 07:37:26) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> yield 1 :1: Warning: 'yield' will become a reserved keyword in the future :1: Warning: 'yield' will become a reserved keyword in the future :1: Warning: 'yield' will become a reserved keyword in the future File "", line 1 yield 1 ^ SyntaxError: invalid syntax >>> from __future__ import generators >>> yield 1 SyntaxError: 'yield' outside function >>> (I can't test it in Idle 'cause I'm on a dial-up connection to the starship) Anyway, see it here: http://starship.python.net/crew/mwh/hacks/codeop-hack.diff As well as the inherent unpleasantness, adding this global state to codeop.py sucks rather, too. But doing a better job would mean creating some kind of object interface and then getting Idle to use it, and I'm too lazy (especially if the idea is going to get thrown out anyway). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-25 23:02 Message: Logged In: YES user_id=31435 Yes, this is a *general* issue with the future statement, and explained in the future-statement PEP. It's not really IDLE's problem (neither the cause nor the cure); it's a problem for all simulated (non-native) shells, including doctest.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444683&group_id=5470 From noreply@sourceforge.net Thu Jul 26 14:57:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 06:57:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-444797 ] dlopen fails loading shared lib modules Message-ID: Bugs item #444797, was opened at 2001-07-26 06:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444797&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: dlopen fails loading shared lib modules Initial Comment: If the python interpreter is embedded in (built as) a shared library that can be dynamically loaded by an application, python shared library modules can not be imported on Solaris and IRIX. This works on HP-UX, AIX, and NT. I have implemented a fix in the attached file 'dynload_shlib.c' (from python 2.0). IRIX requires the additional RTLD_GLOBAL 'mode' flag to be passed to the dlopen calls. Solaris requires the additional RTLD_GLOBAL and RTLD_PARENT 'mode' flags to be passed to the dlopen calls (the RTLD_GROUP and RTLD_WORLD flags were OR'd in to preserve the defaults). Please integrate this fix into future versions of python. I can provide more detailed information about the problem if necessary. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444797&group_id=5470 From noreply@sourceforge.net Thu Jul 26 14:59:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 06:59:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-231774 ] Architecture-specific config.h is badly named Message-ID: Bugs item #231774, was opened at 2001-02-09 13:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231774&group_id=5470 Category: Build Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gilbert Ramirez (gramirez) Assigned to: Thomas Wouters (twouters) Summary: Architecture-specific config.h is badly named Initial Comment: If Python is installed with architecture-dependent and architecture-independent files in separate locations (using --prefix and --exec-prefix), then config.h is placed in a directory different than Python.h (and pyport.h and pgenheaders.h, which also #include "config.h"). If I build a python module which has its own config.h (like pygtk), the build fails because Python.h #include's the *wrong* config.h. I cannot easily change the order of the -I flags when compiling pygtk because autoconf places its flags (AM_CPPFLAGS) before any CPPFLAGS that I define in the CPPFLAGS environment variable. It would be cleaner to follow the glib model which names its installed arch-specific file "glibconfig.h". We could install config.h as pythonconfig.h, and have Python.h #include "pythonconfig.h" ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-26 06:59 Message: Logged In: YES user_id=21627 Fixed with patch #411138, for Python 2.2. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-25 00:37 Message: Logged In: YES user_id=21627 As for legitimately including config.h: it is normally included indirectly, as a result of AC_CHECK_HEADER(Python.h) or the like. configure will add it the project's config.h, which might confuse the further configuration process or have arbitrary other strange effects. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-25 00:31 Message: Logged In: YES user_id=21627 A fix for that problem has been submitted as http://sourceforge.net/tracker/index.php?func=detail&aid=411138&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-02-15 03:31 Message: I'll do it, but I don't mind if anyone else does it before me (One free alpha is enough, anyway :-) My main question is: should anybody be (legitimately) including Python's config.h directly ? I was thinking 'py_acconfig.h' myself, for the new autoconf config.h name. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-02-09 16:03 Message: Assigned to Thomas. Reassign to someone else if you don't want it! Guido said he did want it, but didn't bother assigning it to anyone. Given that we delayed "in dict", we have to find some other way to justify giving you a free alpha release . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-02-09 14:10 Message: Good idea! Patch anybody? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231774&group_id=5470 From noreply@sourceforge.net Thu Jul 26 15:52:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 07:52:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-444797 ] dlopen fails loading shared lib modules Message-ID: Bugs item #444797, was opened at 2001-07-26 06:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444797&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: dlopen fails loading shared lib modules Initial Comment: If the python interpreter is embedded in (built as) a shared library that can be dynamically loaded by an application, python shared library modules can not be imported on Solaris and IRIX. This works on HP-UX, AIX, and NT. I have implemented a fix in the attached file 'dynload_shlib.c' (from python 2.0). IRIX requires the additional RTLD_GLOBAL 'mode' flag to be passed to the dlopen calls. Solaris requires the additional RTLD_GLOBAL and RTLD_PARENT 'mode' flags to be passed to the dlopen calls (the RTLD_GROUP and RTLD_WORLD flags were OR'd in to preserve the defaults). Please integrate this fix into future versions of python. I can provide more detailed information about the problem if necessary. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 07:52 Message: Logged In: YES user_id=6380 Sorry, your attachment didn't come through. When you wish to attach a file to a tracker item you must check the checkbox before submitting changes. Please try again and check to make sure that it worked. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444797&group_id=5470 From noreply@sourceforge.net Thu Jul 26 15:52:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 07:52:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-444129 ] python20 dll not found Message-ID: Bugs item #444129, was opened at 2001-07-24 08:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 Category: Windows Group: Irreproducible Status: Open Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Mark Hammond (mhammond) Summary: python20 dll not found Initial Comment: after upgrading from 2.0 to 2.1 then to 2.1.1 getting error that cant find python20.dll. I completely removed all traces of python and did a fresh install even modified the registry and removed all instances of python and pywin. It is important to note that I also removed an re-installed win32all and it failed to completely install because this error. Another note though python will still run after the error is given the win32 extensions fail to load. I am running on japaneese version of win2000 but had the same problem on the english version(the steps mentioned fixed the problem on english version). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-26 07:52 Message: Logged In: NO No we do not use a PYTHONSTARTUP file. Furthermore, I figured I would quit tryint to use 2.1 and go with 2.0. Well, guess what, when I try to use 2.0, it says it cannot find python21.dll. But when I try to use 2.1 (the reason to write to you guys), it says it cannot find the python20.dll ??????????????????????????????????? Note that I have manually deleted everythinng, checked the registers, etc, etc, etc. But obviously, something is hidden somewhere or there is something else going on. I, too, think that it may have to do with the win32 extension, but the whole thing is a huge mystery. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-25 10:41 Message: Logged In: YES user_id=31435 Assigned to Mark: can you make sense of this? I have to figure it has *something* to do with win32all, because this is the only report of its kind, and the -v output below shows that the base distribution is acting normally in all respects, including getting to the interactive prompt without trouble. Anonymous, do you use a PYTHONSTARTUP file? I asked before, but didn't hear back. That's the only way I know of in the std distribution to execute some Python code at startup that doesn't get mentioned in the -v outpout. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-25 09:49 Message: Logged In: NO Here is the exact output displayed upon executing "python - v" E:\Python21>python -v # E:\Python21\lib\site.pyc matches E:\Python21\lib\site.py import site # precompiled from E:\Python21\lib\site.pyc # E:\Python21\lib\os.pyc matches E:\Python21\lib\os.py import os # precompiled from E:\Python21\lib\os.pyc import nt # builtin # E:\Python21\lib\ntpath.pyc matches E:\Python21 \lib\ntpath.py import ntpath # precompiled from E:\Python21\lib\ntpath.pyc # E:\Python21\lib\stat.pyc matches E:\Python21\lib\stat.py import stat # precompiled from E:\Python21\lib\stat.pyc # E:\Python21\lib\UserDict.pyc matches E:\Python21 \lib\UserDict.py import UserDict # precompiled from E:\Python21 \lib\UserDict.pyc Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> Here is the additional error that appears displayed in a Windows dialog box. I have not typed it in "exactly" as it appears. The dots (...........) below represent a bunch of lines with directory paths: Dialog Box Title: Dynamic Library python20.dll path not found ============================================================ Dynamic Library python20.dll path not found. e:\su5j\security\test\bin................................... ............................................................ .......... ............................................................ ............................................................ ............................... e:\Program Files\Microsoft Visual Studio\Common\msdev98 \BIN\;T:\tools\bin; c:\ATF ============================================================ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 12:12 Message: Logged In: YES user_id=31435 I can't reproduce this on my system -- I see no problems at all. Can you capture the full output from running python - v and attach it to this report? I know exactly what's on my box, but can only guess about what's on yours. There are lots of clues in -v output that would help me. *Somehow* you're picking up an obsolete component, but there are no such components in the PythonLabs distribution. Note that "I then uninstalled 2.0" will cause registry entries to get restored to what they were at the time you first installed 2.0; that will wipe out the registry entries you created if you installed 2.1.1 before uninstalling 2.0. Anything relying on the registry *may* get screwed by that. Our (PythonLabs) distribution doesn't use the registry for much, but win32all may. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 11:14 Message: Logged In: NO Okay lets get more specific after installing 2.1.1 on top of 2.0 it worked I then uninstalled 2.0 and the error is back "python20.dll not found". I ran with -v option and the last lib to load before the error is UserDict. If I install 2.0 then 2.1.1 I seem to be ok with python then but if I try to install win32all it complains and fails stating incompatible dll message. Starting over I have uninstalled everything and re- installed 2.1.1 and have the same problem. the command I am running is... c:\python21\python.exe -v ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 10:35 Message: Logged In: NO As of my last attempt I was running nothing but BeOpen pyhton 2.1.1 (no third party libraries)on a clean system. The error occurs when I run python from the command line or IDLE. I rolled back to 2.0 then installed 2.1.1 on top of it just now and it seemed to fix python. I then installed win32all 140 and the install script throws a similar error saying "module use of python20.dll conflicts with this version of python". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 10:07 Message: Logged In: YES user_id=31435 Then we need more specific information from you. I've never heard of this and find it difficult to believe that anything in the std Python 2.1 distribution requires python20.dll. I just removed all traces of all Pythons from my Win2K box, installed a fresh 2.1.1, and ran the std test suite to completion without any problems. Exactly what do you do that triggers a msg about python20.dll? If I can't reproduce it (and so far I can't), all we can do is guess. Do you perhaps have your own customizations in a PYTHONSTARTUP file that may be trying to access obsolete stuff? Have you tried running Python with -v to get a trace of what it's trying to import? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-24 10:00 Message: Logged In: YES user_id=6380 Sorry to butt in... Are you perhaps trying to use a third party extension like PIL or Numeric Python? Or your own? Extensions built for one Python version won't work with another. Can you tell us exactly what you did that gave the error message? Preferably with the path to the executable that you are trying to run that gives the exception. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 09:54 Message: Logged In: NO I am in fact not using the wrong version of win32all, the problem occurs prior to the install of the extensions. And it is correct that the 2.0 dll's are not installed and python2.1.1 (or 2.1) is complaining about it. I originaly thought the same thing so I removed win32all and python2.1.1 unloaded the dll's and re-installed 2.1.1 prior to re-installing win32all I got the same errors. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 09:34 Message: Logged In: YES user_id=31435 It sounds like you're trying to use Python 2.1.1 with a version of win32all built for 2.0. If so, you can't do that -- Python 2.1.x supplies python21.dll, not python20.dll. Go to ActiveState's site and either install ActivePython from them (which comes with a matched set of components), or get build 140 of win32all.exe from them (which was built to work with Python 2.1 -- but won't work with Python 2.0). Feel free to reopen this bug report if that doesn't solve it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 From noreply@sourceforge.net Thu Jul 26 15:57:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 07:57:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-444129 ] python20 dll not found Message-ID: Bugs item #444129, was opened at 2001-07-24 08:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 Category: Windows Group: Irreproducible >Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Mark Hammond (mhammond) Summary: python20 dll not found Initial Comment: after upgrading from 2.0 to 2.1 then to 2.1.1 getting error that cant find python20.dll. I completely removed all traces of python and did a fresh install even modified the registry and removed all instances of python and pywin. It is important to note that I also removed an re-installed win32all and it failed to completely install because this error. Another note though python will still run after the error is given the win32 extensions fail to load. I am running on japaneese version of win2000 but had the same problem on the english version(the steps mentioned fixed the problem on english version). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 07:57 Message: Logged In: YES user_id=6380 It sounds like you have screwed something over by your manual interventions. I suggest that we close this bug report and you reinstall Windows. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-26 07:52 Message: Logged In: NO No we do not use a PYTHONSTARTUP file. Furthermore, I figured I would quit tryint to use 2.1 and go with 2.0. Well, guess what, when I try to use 2.0, it says it cannot find python21.dll. But when I try to use 2.1 (the reason to write to you guys), it says it cannot find the python20.dll ??????????????????????????????????? Note that I have manually deleted everythinng, checked the registers, etc, etc, etc. But obviously, something is hidden somewhere or there is something else going on. I, too, think that it may have to do with the win32 extension, but the whole thing is a huge mystery. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-25 10:41 Message: Logged In: YES user_id=31435 Assigned to Mark: can you make sense of this? I have to figure it has *something* to do with win32all, because this is the only report of its kind, and the -v output below shows that the base distribution is acting normally in all respects, including getting to the interactive prompt without trouble. Anonymous, do you use a PYTHONSTARTUP file? I asked before, but didn't hear back. That's the only way I know of in the std distribution to execute some Python code at startup that doesn't get mentioned in the -v outpout. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-25 09:49 Message: Logged In: NO Here is the exact output displayed upon executing "python - v" E:\Python21>python -v # E:\Python21\lib\site.pyc matches E:\Python21\lib\site.py import site # precompiled from E:\Python21\lib\site.pyc # E:\Python21\lib\os.pyc matches E:\Python21\lib\os.py import os # precompiled from E:\Python21\lib\os.pyc import nt # builtin # E:\Python21\lib\ntpath.pyc matches E:\Python21 \lib\ntpath.py import ntpath # precompiled from E:\Python21\lib\ntpath.pyc # E:\Python21\lib\stat.pyc matches E:\Python21\lib\stat.py import stat # precompiled from E:\Python21\lib\stat.pyc # E:\Python21\lib\UserDict.pyc matches E:\Python21 \lib\UserDict.py import UserDict # precompiled from E:\Python21 \lib\UserDict.pyc Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> Here is the additional error that appears displayed in a Windows dialog box. I have not typed it in "exactly" as it appears. The dots (...........) below represent a bunch of lines with directory paths: Dialog Box Title: Dynamic Library python20.dll path not found ============================================================ Dynamic Library python20.dll path not found. e:\su5j\security\test\bin................................... ............................................................ .......... ............................................................ ............................................................ ............................... e:\Program Files\Microsoft Visual Studio\Common\msdev98 \BIN\;T:\tools\bin; c:\ATF ============================================================ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 12:12 Message: Logged In: YES user_id=31435 I can't reproduce this on my system -- I see no problems at all. Can you capture the full output from running python - v and attach it to this report? I know exactly what's on my box, but can only guess about what's on yours. There are lots of clues in -v output that would help me. *Somehow* you're picking up an obsolete component, but there are no such components in the PythonLabs distribution. Note that "I then uninstalled 2.0" will cause registry entries to get restored to what they were at the time you first installed 2.0; that will wipe out the registry entries you created if you installed 2.1.1 before uninstalling 2.0. Anything relying on the registry *may* get screwed by that. Our (PythonLabs) distribution doesn't use the registry for much, but win32all may. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 11:14 Message: Logged In: NO Okay lets get more specific after installing 2.1.1 on top of 2.0 it worked I then uninstalled 2.0 and the error is back "python20.dll not found". I ran with -v option and the last lib to load before the error is UserDict. If I install 2.0 then 2.1.1 I seem to be ok with python then but if I try to install win32all it complains and fails stating incompatible dll message. Starting over I have uninstalled everything and re- installed 2.1.1 and have the same problem. the command I am running is... c:\python21\python.exe -v ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 10:35 Message: Logged In: NO As of my last attempt I was running nothing but BeOpen pyhton 2.1.1 (no third party libraries)on a clean system. The error occurs when I run python from the command line or IDLE. I rolled back to 2.0 then installed 2.1.1 on top of it just now and it seemed to fix python. I then installed win32all 140 and the install script throws a similar error saying "module use of python20.dll conflicts with this version of python". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 10:07 Message: Logged In: YES user_id=31435 Then we need more specific information from you. I've never heard of this and find it difficult to believe that anything in the std Python 2.1 distribution requires python20.dll. I just removed all traces of all Pythons from my Win2K box, installed a fresh 2.1.1, and ran the std test suite to completion without any problems. Exactly what do you do that triggers a msg about python20.dll? If I can't reproduce it (and so far I can't), all we can do is guess. Do you perhaps have your own customizations in a PYTHONSTARTUP file that may be trying to access obsolete stuff? Have you tried running Python with -v to get a trace of what it's trying to import? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-24 10:00 Message: Logged In: YES user_id=6380 Sorry to butt in... Are you perhaps trying to use a third party extension like PIL or Numeric Python? Or your own? Extensions built for one Python version won't work with another. Can you tell us exactly what you did that gave the error message? Preferably with the path to the executable that you are trying to run that gives the exception. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 09:54 Message: Logged In: NO I am in fact not using the wrong version of win32all, the problem occurs prior to the install of the extensions. And it is correct that the 2.0 dll's are not installed and python2.1.1 (or 2.1) is complaining about it. I originaly thought the same thing so I removed win32all and python2.1.1 unloaded the dll's and re-installed 2.1.1 prior to re-installing win32all I got the same errors. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 09:34 Message: Logged In: YES user_id=31435 It sounds like you're trying to use Python 2.1.1 with a version of win32all built for 2.0. If so, you can't do that -- Python 2.1.x supplies python21.dll, not python20.dll. Go to ActiveState's site and either install ActivePython from them (which comes with a matched set of components), or get build 140 of win32all.exe from them (which was built to work with Python 2.1 -- but won't work with Python 2.0). Feel free to reopen this bug report if that doesn't solve it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 From noreply@sourceforge.net Thu Jul 26 16:07:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 08:07:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-444129 ] python20 dll not found Message-ID: Bugs item #444129, was opened at 2001-07-24 08:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 Category: Windows Group: Irreproducible Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Mark Hammond (mhammond) Summary: python20 dll not found Initial Comment: after upgrading from 2.0 to 2.1 then to 2.1.1 getting error that cant find python20.dll. I completely removed all traces of python and did a fresh install even modified the registry and removed all instances of python and pywin. It is important to note that I also removed an re-installed win32all and it failed to completely install because this error. Another note though python will still run after the error is given the win32 extensions fail to load. I am running on japaneese version of win2000 but had the same problem on the english version(the steps mentioned fixed the problem on english version). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-26 08:07 Message: Logged In: NO True, we may have screwed something up, but this is not what caused the problem in the first place. In other words, there is a bug somewhere that should be fixed. The fact that we may have screwed something up in trying to resolve it is not only irrelevant but it also does not mean the bug is gone. Others in my company have had the same problem but were able to get around the bug. Sure, close the bug report; we will start from scratch and, well, hopefully the mysterious bug will not come up again......... Nevertheless, a big THANK YOU for your gracious intervention and attempts at solving this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 07:57 Message: Logged In: YES user_id=6380 It sounds like you have screwed something over by your manual interventions. I suggest that we close this bug report and you reinstall Windows. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-26 07:52 Message: Logged In: NO No we do not use a PYTHONSTARTUP file. Furthermore, I figured I would quit tryint to use 2.1 and go with 2.0. Well, guess what, when I try to use 2.0, it says it cannot find python21.dll. But when I try to use 2.1 (the reason to write to you guys), it says it cannot find the python20.dll ??????????????????????????????????? Note that I have manually deleted everythinng, checked the registers, etc, etc, etc. But obviously, something is hidden somewhere or there is something else going on. I, too, think that it may have to do with the win32 extension, but the whole thing is a huge mystery. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-25 10:41 Message: Logged In: YES user_id=31435 Assigned to Mark: can you make sense of this? I have to figure it has *something* to do with win32all, because this is the only report of its kind, and the -v output below shows that the base distribution is acting normally in all respects, including getting to the interactive prompt without trouble. Anonymous, do you use a PYTHONSTARTUP file? I asked before, but didn't hear back. That's the only way I know of in the std distribution to execute some Python code at startup that doesn't get mentioned in the -v outpout. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-25 09:49 Message: Logged In: NO Here is the exact output displayed upon executing "python - v" E:\Python21>python -v # E:\Python21\lib\site.pyc matches E:\Python21\lib\site.py import site # precompiled from E:\Python21\lib\site.pyc # E:\Python21\lib\os.pyc matches E:\Python21\lib\os.py import os # precompiled from E:\Python21\lib\os.pyc import nt # builtin # E:\Python21\lib\ntpath.pyc matches E:\Python21 \lib\ntpath.py import ntpath # precompiled from E:\Python21\lib\ntpath.pyc # E:\Python21\lib\stat.pyc matches E:\Python21\lib\stat.py import stat # precompiled from E:\Python21\lib\stat.pyc # E:\Python21\lib\UserDict.pyc matches E:\Python21 \lib\UserDict.py import UserDict # precompiled from E:\Python21 \lib\UserDict.pyc Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> Here is the additional error that appears displayed in a Windows dialog box. I have not typed it in "exactly" as it appears. The dots (...........) below represent a bunch of lines with directory paths: Dialog Box Title: Dynamic Library python20.dll path not found ============================================================ Dynamic Library python20.dll path not found. e:\su5j\security\test\bin................................... ............................................................ .......... ............................................................ ............................................................ ............................... e:\Program Files\Microsoft Visual Studio\Common\msdev98 \BIN\;T:\tools\bin; c:\ATF ============================================================ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 12:12 Message: Logged In: YES user_id=31435 I can't reproduce this on my system -- I see no problems at all. Can you capture the full output from running python - v and attach it to this report? I know exactly what's on my box, but can only guess about what's on yours. There are lots of clues in -v output that would help me. *Somehow* you're picking up an obsolete component, but there are no such components in the PythonLabs distribution. Note that "I then uninstalled 2.0" will cause registry entries to get restored to what they were at the time you first installed 2.0; that will wipe out the registry entries you created if you installed 2.1.1 before uninstalling 2.0. Anything relying on the registry *may* get screwed by that. Our (PythonLabs) distribution doesn't use the registry for much, but win32all may. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 11:14 Message: Logged In: NO Okay lets get more specific after installing 2.1.1 on top of 2.0 it worked I then uninstalled 2.0 and the error is back "python20.dll not found". I ran with -v option and the last lib to load before the error is UserDict. If I install 2.0 then 2.1.1 I seem to be ok with python then but if I try to install win32all it complains and fails stating incompatible dll message. Starting over I have uninstalled everything and re- installed 2.1.1 and have the same problem. the command I am running is... c:\python21\python.exe -v ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 10:35 Message: Logged In: NO As of my last attempt I was running nothing but BeOpen pyhton 2.1.1 (no third party libraries)on a clean system. The error occurs when I run python from the command line or IDLE. I rolled back to 2.0 then installed 2.1.1 on top of it just now and it seemed to fix python. I then installed win32all 140 and the install script throws a similar error saying "module use of python20.dll conflicts with this version of python". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 10:07 Message: Logged In: YES user_id=31435 Then we need more specific information from you. I've never heard of this and find it difficult to believe that anything in the std Python 2.1 distribution requires python20.dll. I just removed all traces of all Pythons from my Win2K box, installed a fresh 2.1.1, and ran the std test suite to completion without any problems. Exactly what do you do that triggers a msg about python20.dll? If I can't reproduce it (and so far I can't), all we can do is guess. Do you perhaps have your own customizations in a PYTHONSTARTUP file that may be trying to access obsolete stuff? Have you tried running Python with -v to get a trace of what it's trying to import? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-24 10:00 Message: Logged In: YES user_id=6380 Sorry to butt in... Are you perhaps trying to use a third party extension like PIL or Numeric Python? Or your own? Extensions built for one Python version won't work with another. Can you tell us exactly what you did that gave the error message? Preferably with the path to the executable that you are trying to run that gives the exception. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 09:54 Message: Logged In: NO I am in fact not using the wrong version of win32all, the problem occurs prior to the install of the extensions. And it is correct that the 2.0 dll's are not installed and python2.1.1 (or 2.1) is complaining about it. I originaly thought the same thing so I removed win32all and python2.1.1 unloaded the dll's and re-installed 2.1.1 prior to re-installing win32all I got the same errors. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 09:34 Message: Logged In: YES user_id=31435 It sounds like you're trying to use Python 2.1.1 with a version of win32all built for 2.0. If so, you can't do that -- Python 2.1.x supplies python21.dll, not python20.dll. Go to ActiveState's site and either install ActivePython from them (which comes with a matched set of components), or get build 140 of win32all.exe from them (which was built to work with Python 2.1 -- but won't work with Python 2.0). Feel free to reopen this bug report if that doesn't solve it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 From noreply@sourceforge.net Thu Jul 26 16:13:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 08:13:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-444129 ] python20 dll not found Message-ID: Bugs item #444129, was opened at 2001-07-24 08:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 Category: Windows Group: Irreproducible Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Mark Hammond (mhammond) Summary: python20 dll not found Initial Comment: after upgrading from 2.0 to 2.1 then to 2.1.1 getting error that cant find python20.dll. I completely removed all traces of python and did a fresh install even modified the registry and removed all instances of python and pywin. It is important to note that I also removed an re-installed win32all and it failed to completely install because this error. Another note though python will still run after the error is given the win32 extensions fail to load. I am running on japaneese version of win2000 but had the same problem on the english version(the steps mentioned fixed the problem on english version). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 08:13 Message: Logged In: YES user_id=6380 Bugs of this nature almost *always* end up being caused by some local bizarrity of the Windows configuration, not by something the Python installer could have prevented. The fact that others in your company have the same problem (but no-one outside your company has reported this) suggests that it could be some kind of network management problem. Good luck! ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-26 08:07 Message: Logged In: NO True, we may have screwed something up, but this is not what caused the problem in the first place. In other words, there is a bug somewhere that should be fixed. The fact that we may have screwed something up in trying to resolve it is not only irrelevant but it also does not mean the bug is gone. Others in my company have had the same problem but were able to get around the bug. Sure, close the bug report; we will start from scratch and, well, hopefully the mysterious bug will not come up again......... Nevertheless, a big THANK YOU for your gracious intervention and attempts at solving this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 07:57 Message: Logged In: YES user_id=6380 It sounds like you have screwed something over by your manual interventions. I suggest that we close this bug report and you reinstall Windows. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-26 07:52 Message: Logged In: NO No we do not use a PYTHONSTARTUP file. Furthermore, I figured I would quit tryint to use 2.1 and go with 2.0. Well, guess what, when I try to use 2.0, it says it cannot find python21.dll. But when I try to use 2.1 (the reason to write to you guys), it says it cannot find the python20.dll ??????????????????????????????????? Note that I have manually deleted everythinng, checked the registers, etc, etc, etc. But obviously, something is hidden somewhere or there is something else going on. I, too, think that it may have to do with the win32 extension, but the whole thing is a huge mystery. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-25 10:41 Message: Logged In: YES user_id=31435 Assigned to Mark: can you make sense of this? I have to figure it has *something* to do with win32all, because this is the only report of its kind, and the -v output below shows that the base distribution is acting normally in all respects, including getting to the interactive prompt without trouble. Anonymous, do you use a PYTHONSTARTUP file? I asked before, but didn't hear back. That's the only way I know of in the std distribution to execute some Python code at startup that doesn't get mentioned in the -v outpout. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-25 09:49 Message: Logged In: NO Here is the exact output displayed upon executing "python - v" E:\Python21>python -v # E:\Python21\lib\site.pyc matches E:\Python21\lib\site.py import site # precompiled from E:\Python21\lib\site.pyc # E:\Python21\lib\os.pyc matches E:\Python21\lib\os.py import os # precompiled from E:\Python21\lib\os.pyc import nt # builtin # E:\Python21\lib\ntpath.pyc matches E:\Python21 \lib\ntpath.py import ntpath # precompiled from E:\Python21\lib\ntpath.pyc # E:\Python21\lib\stat.pyc matches E:\Python21\lib\stat.py import stat # precompiled from E:\Python21\lib\stat.pyc # E:\Python21\lib\UserDict.pyc matches E:\Python21 \lib\UserDict.py import UserDict # precompiled from E:\Python21 \lib\UserDict.pyc Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> Here is the additional error that appears displayed in a Windows dialog box. I have not typed it in "exactly" as it appears. The dots (...........) below represent a bunch of lines with directory paths: Dialog Box Title: Dynamic Library python20.dll path not found ============================================================ Dynamic Library python20.dll path not found. e:\su5j\security\test\bin................................... ............................................................ .......... ............................................................ ............................................................ ............................... e:\Program Files\Microsoft Visual Studio\Common\msdev98 \BIN\;T:\tools\bin; c:\ATF ============================================================ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 12:12 Message: Logged In: YES user_id=31435 I can't reproduce this on my system -- I see no problems at all. Can you capture the full output from running python - v and attach it to this report? I know exactly what's on my box, but can only guess about what's on yours. There are lots of clues in -v output that would help me. *Somehow* you're picking up an obsolete component, but there are no such components in the PythonLabs distribution. Note that "I then uninstalled 2.0" will cause registry entries to get restored to what they were at the time you first installed 2.0; that will wipe out the registry entries you created if you installed 2.1.1 before uninstalling 2.0. Anything relying on the registry *may* get screwed by that. Our (PythonLabs) distribution doesn't use the registry for much, but win32all may. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 11:14 Message: Logged In: NO Okay lets get more specific after installing 2.1.1 on top of 2.0 it worked I then uninstalled 2.0 and the error is back "python20.dll not found". I ran with -v option and the last lib to load before the error is UserDict. If I install 2.0 then 2.1.1 I seem to be ok with python then but if I try to install win32all it complains and fails stating incompatible dll message. Starting over I have uninstalled everything and re- installed 2.1.1 and have the same problem. the command I am running is... c:\python21\python.exe -v ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 10:35 Message: Logged In: NO As of my last attempt I was running nothing but BeOpen pyhton 2.1.1 (no third party libraries)on a clean system. The error occurs when I run python from the command line or IDLE. I rolled back to 2.0 then installed 2.1.1 on top of it just now and it seemed to fix python. I then installed win32all 140 and the install script throws a similar error saying "module use of python20.dll conflicts with this version of python". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 10:07 Message: Logged In: YES user_id=31435 Then we need more specific information from you. I've never heard of this and find it difficult to believe that anything in the std Python 2.1 distribution requires python20.dll. I just removed all traces of all Pythons from my Win2K box, installed a fresh 2.1.1, and ran the std test suite to completion without any problems. Exactly what do you do that triggers a msg about python20.dll? If I can't reproduce it (and so far I can't), all we can do is guess. Do you perhaps have your own customizations in a PYTHONSTARTUP file that may be trying to access obsolete stuff? Have you tried running Python with -v to get a trace of what it's trying to import? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-24 10:00 Message: Logged In: YES user_id=6380 Sorry to butt in... Are you perhaps trying to use a third party extension like PIL or Numeric Python? Or your own? Extensions built for one Python version won't work with another. Can you tell us exactly what you did that gave the error message? Preferably with the path to the executable that you are trying to run that gives the exception. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 09:54 Message: Logged In: NO I am in fact not using the wrong version of win32all, the problem occurs prior to the install of the extensions. And it is correct that the 2.0 dll's are not installed and python2.1.1 (or 2.1) is complaining about it. I originaly thought the same thing so I removed win32all and python2.1.1 unloaded the dll's and re-installed 2.1.1 prior to re-installing win32all I got the same errors. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 09:34 Message: Logged In: YES user_id=31435 It sounds like you're trying to use Python 2.1.1 with a version of win32all built for 2.0. If so, you can't do that -- Python 2.1.x supplies python21.dll, not python20.dll. Go to ActiveState's site and either install ActivePython from them (which comes with a matched set of components), or get build 140 of win32all.exe from them (which was built to work with Python 2.1 -- but won't work with Python 2.0). Feel free to reopen this bug report if that doesn't solve it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 From noreply@sourceforge.net Thu Jul 26 16:32:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 08:32:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-444129 ] python20 dll not found Message-ID: Bugs item #444129, was opened at 2001-07-24 08:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 Category: Windows Group: Irreproducible >Status: Open Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Mark Hammond (mhammond) Summary: python20 dll not found Initial Comment: after upgrading from 2.0 to 2.1 then to 2.1.1 getting error that cant find python20.dll. I completely removed all traces of python and did a fresh install even modified the registry and removed all instances of python and pywin. It is important to note that I also removed an re-installed win32all and it failed to completely install because this error. Another note though python will still run after the error is given the win32 extensions fail to load. I am running on japaneese version of win2000 but had the same problem on the english version(the steps mentioned fixed the problem on english version). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-26 08:32 Message: Logged In: YES user_id=31435 I'm reopening this, at least until MarkH has a chance to look at it. While some Windows Mysteries never get solved, you can't tell which those are in advance . Anonymous, I also would like to know what's going on, but you have a unique problem (never reported before), and one I can't reproduce. But my experience w/ win32all is trivial. That's why I want MarkH (win32all's author) to see this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 08:13 Message: Logged In: YES user_id=6380 Bugs of this nature almost *always* end up being caused by some local bizarrity of the Windows configuration, not by something the Python installer could have prevented. The fact that others in your company have the same problem (but no-one outside your company has reported this) suggests that it could be some kind of network management problem. Good luck! ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-26 08:07 Message: Logged In: NO True, we may have screwed something up, but this is not what caused the problem in the first place. In other words, there is a bug somewhere that should be fixed. The fact that we may have screwed something up in trying to resolve it is not only irrelevant but it also does not mean the bug is gone. Others in my company have had the same problem but were able to get around the bug. Sure, close the bug report; we will start from scratch and, well, hopefully the mysterious bug will not come up again......... Nevertheless, a big THANK YOU for your gracious intervention and attempts at solving this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 07:57 Message: Logged In: YES user_id=6380 It sounds like you have screwed something over by your manual interventions. I suggest that we close this bug report and you reinstall Windows. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-26 07:52 Message: Logged In: NO No we do not use a PYTHONSTARTUP file. Furthermore, I figured I would quit tryint to use 2.1 and go with 2.0. Well, guess what, when I try to use 2.0, it says it cannot find python21.dll. But when I try to use 2.1 (the reason to write to you guys), it says it cannot find the python20.dll ??????????????????????????????????? Note that I have manually deleted everythinng, checked the registers, etc, etc, etc. But obviously, something is hidden somewhere or there is something else going on. I, too, think that it may have to do with the win32 extension, but the whole thing is a huge mystery. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-25 10:41 Message: Logged In: YES user_id=31435 Assigned to Mark: can you make sense of this? I have to figure it has *something* to do with win32all, because this is the only report of its kind, and the -v output below shows that the base distribution is acting normally in all respects, including getting to the interactive prompt without trouble. Anonymous, do you use a PYTHONSTARTUP file? I asked before, but didn't hear back. That's the only way I know of in the std distribution to execute some Python code at startup that doesn't get mentioned in the -v outpout. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-25 09:49 Message: Logged In: NO Here is the exact output displayed upon executing "python - v" E:\Python21>python -v # E:\Python21\lib\site.pyc matches E:\Python21\lib\site.py import site # precompiled from E:\Python21\lib\site.pyc # E:\Python21\lib\os.pyc matches E:\Python21\lib\os.py import os # precompiled from E:\Python21\lib\os.pyc import nt # builtin # E:\Python21\lib\ntpath.pyc matches E:\Python21 \lib\ntpath.py import ntpath # precompiled from E:\Python21\lib\ntpath.pyc # E:\Python21\lib\stat.pyc matches E:\Python21\lib\stat.py import stat # precompiled from E:\Python21\lib\stat.pyc # E:\Python21\lib\UserDict.pyc matches E:\Python21 \lib\UserDict.py import UserDict # precompiled from E:\Python21 \lib\UserDict.pyc Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> Here is the additional error that appears displayed in a Windows dialog box. I have not typed it in "exactly" as it appears. The dots (...........) below represent a bunch of lines with directory paths: Dialog Box Title: Dynamic Library python20.dll path not found ============================================================ Dynamic Library python20.dll path not found. e:\su5j\security\test\bin................................... ............................................................ .......... ............................................................ ............................................................ ............................... e:\Program Files\Microsoft Visual Studio\Common\msdev98 \BIN\;T:\tools\bin; c:\ATF ============================================================ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 12:12 Message: Logged In: YES user_id=31435 I can't reproduce this on my system -- I see no problems at all. Can you capture the full output from running python - v and attach it to this report? I know exactly what's on my box, but can only guess about what's on yours. There are lots of clues in -v output that would help me. *Somehow* you're picking up an obsolete component, but there are no such components in the PythonLabs distribution. Note that "I then uninstalled 2.0" will cause registry entries to get restored to what they were at the time you first installed 2.0; that will wipe out the registry entries you created if you installed 2.1.1 before uninstalling 2.0. Anything relying on the registry *may* get screwed by that. Our (PythonLabs) distribution doesn't use the registry for much, but win32all may. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 11:14 Message: Logged In: NO Okay lets get more specific after installing 2.1.1 on top of 2.0 it worked I then uninstalled 2.0 and the error is back "python20.dll not found". I ran with -v option and the last lib to load before the error is UserDict. If I install 2.0 then 2.1.1 I seem to be ok with python then but if I try to install win32all it complains and fails stating incompatible dll message. Starting over I have uninstalled everything and re- installed 2.1.1 and have the same problem. the command I am running is... c:\python21\python.exe -v ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 10:35 Message: Logged In: NO As of my last attempt I was running nothing but BeOpen pyhton 2.1.1 (no third party libraries)on a clean system. The error occurs when I run python from the command line or IDLE. I rolled back to 2.0 then installed 2.1.1 on top of it just now and it seemed to fix python. I then installed win32all 140 and the install script throws a similar error saying "module use of python20.dll conflicts with this version of python". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 10:07 Message: Logged In: YES user_id=31435 Then we need more specific information from you. I've never heard of this and find it difficult to believe that anything in the std Python 2.1 distribution requires python20.dll. I just removed all traces of all Pythons from my Win2K box, installed a fresh 2.1.1, and ran the std test suite to completion without any problems. Exactly what do you do that triggers a msg about python20.dll? If I can't reproduce it (and so far I can't), all we can do is guess. Do you perhaps have your own customizations in a PYTHONSTARTUP file that may be trying to access obsolete stuff? Have you tried running Python with -v to get a trace of what it's trying to import? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-24 10:00 Message: Logged In: YES user_id=6380 Sorry to butt in... Are you perhaps trying to use a third party extension like PIL or Numeric Python? Or your own? Extensions built for one Python version won't work with another. Can you tell us exactly what you did that gave the error message? Preferably with the path to the executable that you are trying to run that gives the exception. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 09:54 Message: Logged In: NO I am in fact not using the wrong version of win32all, the problem occurs prior to the install of the extensions. And it is correct that the 2.0 dll's are not installed and python2.1.1 (or 2.1) is complaining about it. I originaly thought the same thing so I removed win32all and python2.1.1 unloaded the dll's and re-installed 2.1.1 prior to re-installing win32all I got the same errors. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 09:34 Message: Logged In: YES user_id=31435 It sounds like you're trying to use Python 2.1.1 with a version of win32all built for 2.0. If so, you can't do that -- Python 2.1.x supplies python21.dll, not python20.dll. Go to ActiveState's site and either install ActivePython from them (which comes with a matched set of components), or get build 140 of win32all.exe from them (which was built to work with Python 2.1 -- but won't work with Python 2.0). Feel free to reopen this bug report if that doesn't solve it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 From noreply@sourceforge.net Thu Jul 26 16:28:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 08:28:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-444707 ] cgi.escape() should replace single quote Message-ID: Bugs item #444707, was opened at 2001-07-26 01:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444707&group_id=5470 Category: Python Library >Group: Feature Request Status: Open Resolution: None >Priority: 1 Submitted By: Artur Zaprzala (zybi) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.escape() should replace single quote Initial Comment: escape function from cgi module should be able to replace signle quotation marks with ' as they are allowed as HTML element attribute delimiters. Reference: http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 08:28 Message: Logged In: YES user_id=6380 By convention, attributes normally use double quotes, and this is what cgi.escape() assumes. Why can't you use double quotes? How would escape() know whether you want single quotes or double quotes? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444707&group_id=5470 From noreply@sourceforge.net Thu Jul 26 16:51:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 08:51:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-444842 ] array's buffer_info() -> length in bytes Message-ID: Bugs item #444842, was opened at 2001-07-26 08:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444842&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: array's buffer_info() -> length in bytes Initial Comment: In arraymodule.c, the array's method buffer_info() is documented to return (address, length), where 'length' is measured in bytes. Unfortunately, it currently returns the number of items instead. It should be fixed. Changing the return value could potentially break code relying on the actual (undocumented) behavior. On the other hand, merely changing the documentation to 'officialize' the bug would be a departure from buffer_info()'s original goal to provide direct raw memory access. I think the bug should be fixed, with a note about the different behavior of previous versions in the docs -- for maximum portability, users can always compute the length in bytes separately as "len(a)*a.itemsize". Current users of buffer_info() may already have noticed the bug and used the above formula to get the length, so their code won't break. Fix: in arraymodule.c: array_buffer_info: PyTuple_SET_ITEM(retval, 1, PyInt_FromLong((long)(self->ob_size * self->ob_descr->itemsize))); The multiplication should not overflow (care was taken about it at resize time). Armin ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444842&group_id=5470 From noreply@sourceforge.net Thu Jul 26 18:10:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 10:10:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-444797 ] dlopen fails loading shared lib modules Message-ID: Bugs item #444797, was opened at 2001-07-26 06:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444797&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: dlopen fails loading shared lib modules Initial Comment: If the python interpreter is embedded in (built as) a shared library that can be dynamically loaded by an application, python shared library modules can not be imported on Solaris and IRIX. This works on HP-UX, AIX, and NT. I have implemented a fix in the attached file 'dynload_shlib.c' (from python 2.0). IRIX requires the additional RTLD_GLOBAL 'mode' flag to be passed to the dlopen calls. Solaris requires the additional RTLD_GLOBAL and RTLD_PARENT 'mode' flags to be passed to the dlopen calls (the RTLD_GROUP and RTLD_WORLD flags were OR'd in to preserve the defaults). Please integrate this fix into future versions of python. I can provide more detailed information about the problem if necessary. ---------------------------------------------------------------------- Comment By: Dave Smith (dts) Date: 2001-07-26 10:10 Message: Logged In: YES user_id=281856 I don't see any way to attach a file to an existing bug#, so i've just cut/pasted the file below. --- BEGIN dynload_shlib.c --- /* Support for dynamic loading of extension modules */ #include "Python.h" #include "importdl.h" #include #include #if defined(__NetBSD__) && (NetBSD < 199712) #include #include #define dlerror() "error in dynamic linking" #else #ifdef HAVE_DLFCN_H #include #endif #endif #ifndef RTLD_LAZY #define RTLD_LAZY 1 #endif const struct filedescr _PyImport_DynLoadFiletab[] = { #ifdef __CYGWIN__ {".pyd", "rb", C_EXTENSION}, {".dll", "rb", C_EXTENSION}, #else {".so", "rb", C_EXTENSION}, {"module.so", "rb", C_EXTENSION}, #endif {0, 0} }; static struct { dev_t dev; ino_t ino; void *handle; } handles[128]; static int nhandles = 0; dl_funcptr _PyImport_GetDynLoadFunc(const char *fqname, const char *shortname, const char *pathname, FILE *fp) { dl_funcptr p; void *handle; char funcname[258]; char pathbuf[260]; int mode; if (strchr(pathname, '/') == NULL) { /* Prefix bare filename with "./" */ sprintf(pathbuf, "./%-.255s", pathname); pathname = pathbuf; } /* ### should there be a leading underscore for some platforms? */ sprintf(funcname, "init%.200s", shortname); if (fp != NULL) { int i; struct stat statb; fstat(fileno(fp), &statb); for (i = 0; i < nhandles; i++) { if (statb.st_dev == handles[i].dev && statb.st_ino == handles[i].ino) { p = (dl_funcptr) dlsym(handles[i].handle, funcname); return p; } } if (nhandles < 128) { handles[nhandles].dev = statb.st_dev; handles[nhandles].ino = statb.st_ino; } } mode = RTLD_GLOBAL; #ifdef RTLD_GROUP mode |= RTLD_GROUP; #endif #ifdef RTLD_PARENT mode |= RTLD_PARENT; #endif #ifdef RTLD_WORLD mode |= RTLD_WORLD; #endif #ifdef RTLD_NOW /* RTLD_NOW: resolve externals now (i.e. core dump now if some are missing) */ if (Py_VerboseFlag) printf("dlopen(\%s\, %d);\n", pathname, RTLD_NOW | mode); handle = dlopen(pathname, RTLD_NOW | mode); #else if (Py_VerboseFlag) printf("dlopen(\%s\, %d);\n", pathname, RTLD_LAZY | mode); handle = dlopen(pathname, RTLD_LAZY | mode); #endif /* RTLD_NOW */ if (handle == NULL) { PyErr_SetString(PyExc_ImportError, dlerror()); return NULL; } if (fp != NULL && nhandles < 128) handles[nhandles++].handle = handle; p = (dl_funcptr) dlsym(handle, funcname); return p; } --- END dynload_shlib.c --- ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 07:52 Message: Logged In: YES user_id=6380 Sorry, your attachment didn't come through. When you wish to attach a file to a tracker item you must check the checkbox before submitting changes. Please try again and check to make sure that it worked. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444797&group_id=5470 From noreply@sourceforge.net Thu Jul 26 18:18:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 10:18:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-444797 ] dlopen fails loading shared lib modules Message-ID: Bugs item #444797, was opened at 2001-07-26 06:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444797&group_id=5470 >Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: dlopen fails loading shared lib modules Initial Comment: If the python interpreter is embedded in (built as) a shared library that can be dynamically loaded by an application, python shared library modules can not be imported on Solaris and IRIX. This works on HP-UX, AIX, and NT. I have implemented a fix in the attached file 'dynload_shlib.c' (from python 2.0). IRIX requires the additional RTLD_GLOBAL 'mode' flag to be passed to the dlopen calls. Solaris requires the additional RTLD_GLOBAL and RTLD_PARENT 'mode' flags to be passed to the dlopen calls (the RTLD_GROUP and RTLD_WORLD flags were OR'd in to preserve the defaults). Please integrate this fix into future versions of python. I can provide more detailed information about the problem if necessary. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 10:18 Message: Logged In: YES user_id=6380 I've attached a context diff to make it clearer what you changed. Unfortunately, there have been other changes to this file (to allow user control over the dynload flags) so someone (not me) is going to have to do a merge. ---------------------------------------------------------------------- Comment By: Dave Smith (dts) Date: 2001-07-26 10:10 Message: Logged In: YES user_id=281856 I don't see any way to attach a file to an existing bug#, so i've just cut/pasted the file below. --- BEGIN dynload_shlib.c --- /* Support for dynamic loading of extension modules */ #include "Python.h" #include "importdl.h" #include #include #if defined(__NetBSD__) && (NetBSD < 199712) #include #include #define dlerror() "error in dynamic linking" #else #ifdef HAVE_DLFCN_H #include #endif #endif #ifndef RTLD_LAZY #define RTLD_LAZY 1 #endif const struct filedescr _PyImport_DynLoadFiletab[] = { #ifdef __CYGWIN__ {".pyd", "rb", C_EXTENSION}, {".dll", "rb", C_EXTENSION}, #else {".so", "rb", C_EXTENSION}, {"module.so", "rb", C_EXTENSION}, #endif {0, 0} }; static struct { dev_t dev; ino_t ino; void *handle; } handles[128]; static int nhandles = 0; dl_funcptr _PyImport_GetDynLoadFunc(const char *fqname, const char *shortname, const char *pathname, FILE *fp) { dl_funcptr p; void *handle; char funcname[258]; char pathbuf[260]; int mode; if (strchr(pathname, '/') == NULL) { /* Prefix bare filename with "./" */ sprintf(pathbuf, "./%-.255s", pathname); pathname = pathbuf; } /* ### should there be a leading underscore for some platforms? */ sprintf(funcname, "init%.200s", shortname); if (fp != NULL) { int i; struct stat statb; fstat(fileno(fp), &statb); for (i = 0; i < nhandles; i++) { if (statb.st_dev == handles[i].dev && statb.st_ino == handles[i].ino) { p = (dl_funcptr) dlsym(handles[i].handle, funcname); return p; } } if (nhandles < 128) { handles[nhandles].dev = statb.st_dev; handles[nhandles].ino = statb.st_ino; } } mode = RTLD_GLOBAL; #ifdef RTLD_GROUP mode |= RTLD_GROUP; #endif #ifdef RTLD_PARENT mode |= RTLD_PARENT; #endif #ifdef RTLD_WORLD mode |= RTLD_WORLD; #endif #ifdef RTLD_NOW /* RTLD_NOW: resolve externals now (i.e. core dump now if some are missing) */ if (Py_VerboseFlag) printf("dlopen(\%s\, %d);\n", pathname, RTLD_NOW | mode); handle = dlopen(pathname, RTLD_NOW | mode); #else if (Py_VerboseFlag) printf("dlopen(\%s\, %d);\n", pathname, RTLD_LAZY | mode); handle = dlopen(pathname, RTLD_LAZY | mode); #endif /* RTLD_NOW */ if (handle == NULL) { PyErr_SetString(PyExc_ImportError, dlerror()); return NULL; } if (fp != NULL && nhandles < 128) handles[nhandles++].handle = handle; p = (dl_funcptr) dlsym(handle, funcname); return p; } --- END dynload_shlib.c --- ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 07:52 Message: Logged In: YES user_id=6380 Sorry, your attachment didn't come through. When you wish to attach a file to a tracker item you must check the checkbox before submitting changes. Please try again and check to make sure that it worked. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444797&group_id=5470 From noreply@sourceforge.net Thu Jul 26 20:20:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 12:20:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-444129 ] python20 dll not found Message-ID: Bugs item #444129, was opened at 2001-07-24 08:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 Category: Windows Group: Irreproducible Status: Open Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Mark Hammond (mhammond) Summary: python20 dll not found Initial Comment: after upgrading from 2.0 to 2.1 then to 2.1.1 getting error that cant find python20.dll. I completely removed all traces of python and did a fresh install even modified the registry and removed all instances of python and pywin. It is important to note that I also removed an re-installed win32all and it failed to completely install because this error. Another note though python will still run after the error is given the win32 extensions fail to load. I am running on japaneese version of win2000 but had the same problem on the english version(the steps mentioned fixed the problem on english version). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-26 12:20 Message: Logged In: NO That sounds good to me. I will re-install Windows and try to install python 2.1 anew..........will let you know what happens. It should be interesting. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-26 08:32 Message: Logged In: YES user_id=31435 I'm reopening this, at least until MarkH has a chance to look at it. While some Windows Mysteries never get solved, you can't tell which those are in advance . Anonymous, I also would like to know what's going on, but you have a unique problem (never reported before), and one I can't reproduce. But my experience w/ win32all is trivial. That's why I want MarkH (win32all's author) to see this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 08:13 Message: Logged In: YES user_id=6380 Bugs of this nature almost *always* end up being caused by some local bizarrity of the Windows configuration, not by something the Python installer could have prevented. The fact that others in your company have the same problem (but no-one outside your company has reported this) suggests that it could be some kind of network management problem. Good luck! ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-26 08:07 Message: Logged In: NO True, we may have screwed something up, but this is not what caused the problem in the first place. In other words, there is a bug somewhere that should be fixed. The fact that we may have screwed something up in trying to resolve it is not only irrelevant but it also does not mean the bug is gone. Others in my company have had the same problem but were able to get around the bug. Sure, close the bug report; we will start from scratch and, well, hopefully the mysterious bug will not come up again......... Nevertheless, a big THANK YOU for your gracious intervention and attempts at solving this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 07:57 Message: Logged In: YES user_id=6380 It sounds like you have screwed something over by your manual interventions. I suggest that we close this bug report and you reinstall Windows. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-26 07:52 Message: Logged In: NO No we do not use a PYTHONSTARTUP file. Furthermore, I figured I would quit tryint to use 2.1 and go with 2.0. Well, guess what, when I try to use 2.0, it says it cannot find python21.dll. But when I try to use 2.1 (the reason to write to you guys), it says it cannot find the python20.dll ??????????????????????????????????? Note that I have manually deleted everythinng, checked the registers, etc, etc, etc. But obviously, something is hidden somewhere or there is something else going on. I, too, think that it may have to do with the win32 extension, but the whole thing is a huge mystery. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-25 10:41 Message: Logged In: YES user_id=31435 Assigned to Mark: can you make sense of this? I have to figure it has *something* to do with win32all, because this is the only report of its kind, and the -v output below shows that the base distribution is acting normally in all respects, including getting to the interactive prompt without trouble. Anonymous, do you use a PYTHONSTARTUP file? I asked before, but didn't hear back. That's the only way I know of in the std distribution to execute some Python code at startup that doesn't get mentioned in the -v outpout. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-25 09:49 Message: Logged In: NO Here is the exact output displayed upon executing "python - v" E:\Python21>python -v # E:\Python21\lib\site.pyc matches E:\Python21\lib\site.py import site # precompiled from E:\Python21\lib\site.pyc # E:\Python21\lib\os.pyc matches E:\Python21\lib\os.py import os # precompiled from E:\Python21\lib\os.pyc import nt # builtin # E:\Python21\lib\ntpath.pyc matches E:\Python21 \lib\ntpath.py import ntpath # precompiled from E:\Python21\lib\ntpath.pyc # E:\Python21\lib\stat.pyc matches E:\Python21\lib\stat.py import stat # precompiled from E:\Python21\lib\stat.pyc # E:\Python21\lib\UserDict.pyc matches E:\Python21 \lib\UserDict.py import UserDict # precompiled from E:\Python21 \lib\UserDict.pyc Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> Here is the additional error that appears displayed in a Windows dialog box. I have not typed it in "exactly" as it appears. The dots (...........) below represent a bunch of lines with directory paths: Dialog Box Title: Dynamic Library python20.dll path not found ============================================================ Dynamic Library python20.dll path not found. e:\su5j\security\test\bin................................... ............................................................ .......... ............................................................ ............................................................ ............................... e:\Program Files\Microsoft Visual Studio\Common\msdev98 \BIN\;T:\tools\bin; c:\ATF ============================================================ ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 12:12 Message: Logged In: YES user_id=31435 I can't reproduce this on my system -- I see no problems at all. Can you capture the full output from running python - v and attach it to this report? I know exactly what's on my box, but can only guess about what's on yours. There are lots of clues in -v output that would help me. *Somehow* you're picking up an obsolete component, but there are no such components in the PythonLabs distribution. Note that "I then uninstalled 2.0" will cause registry entries to get restored to what they were at the time you first installed 2.0; that will wipe out the registry entries you created if you installed 2.1.1 before uninstalling 2.0. Anything relying on the registry *may* get screwed by that. Our (PythonLabs) distribution doesn't use the registry for much, but win32all may. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 11:14 Message: Logged In: NO Okay lets get more specific after installing 2.1.1 on top of 2.0 it worked I then uninstalled 2.0 and the error is back "python20.dll not found". I ran with -v option and the last lib to load before the error is UserDict. If I install 2.0 then 2.1.1 I seem to be ok with python then but if I try to install win32all it complains and fails stating incompatible dll message. Starting over I have uninstalled everything and re- installed 2.1.1 and have the same problem. the command I am running is... c:\python21\python.exe -v ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 10:35 Message: Logged In: NO As of my last attempt I was running nothing but BeOpen pyhton 2.1.1 (no third party libraries)on a clean system. The error occurs when I run python from the command line or IDLE. I rolled back to 2.0 then installed 2.1.1 on top of it just now and it seemed to fix python. I then installed win32all 140 and the install script throws a similar error saying "module use of python20.dll conflicts with this version of python". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 10:07 Message: Logged In: YES user_id=31435 Then we need more specific information from you. I've never heard of this and find it difficult to believe that anything in the std Python 2.1 distribution requires python20.dll. I just removed all traces of all Pythons from my Win2K box, installed a fresh 2.1.1, and ran the std test suite to completion without any problems. Exactly what do you do that triggers a msg about python20.dll? If I can't reproduce it (and so far I can't), all we can do is guess. Do you perhaps have your own customizations in a PYTHONSTARTUP file that may be trying to access obsolete stuff? Have you tried running Python with -v to get a trace of what it's trying to import? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-24 10:00 Message: Logged In: YES user_id=6380 Sorry to butt in... Are you perhaps trying to use a third party extension like PIL or Numeric Python? Or your own? Extensions built for one Python version won't work with another. Can you tell us exactly what you did that gave the error message? Preferably with the path to the executable that you are trying to run that gives the exception. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-24 09:54 Message: Logged In: NO I am in fact not using the wrong version of win32all, the problem occurs prior to the install of the extensions. And it is correct that the 2.0 dll's are not installed and python2.1.1 (or 2.1) is complaining about it. I originaly thought the same thing so I removed win32all and python2.1.1 unloaded the dll's and re-installed 2.1.1 prior to re-installing win32all I got the same errors. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 09:34 Message: Logged In: YES user_id=31435 It sounds like you're trying to use Python 2.1.1 with a version of win32all built for 2.0. If so, you can't do that -- Python 2.1.x supplies python21.dll, not python20.dll. Go to ActiveState's site and either install ActivePython from them (which comes with a matched set of components), or get build 140 of win32all.exe from them (which was built to work with Python 2.1 -- but won't work with Python 2.0). Feel free to reopen this bug report if that doesn't solve it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470 From noreply@sourceforge.net Thu Jul 26 20:51:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 12:51:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-444510 ] int() should guarantee truncation Message-ID: Bugs item #444510, was opened at 2001-07-25 09:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444510&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) >Assigned to: Tim Peters (tim_one) Summary: int() should guarantee truncation Initial Comment: The int() function currently warns that it cannot guarantee truncation because C doesn't guarantee it. However, all known (to us) C implementations *do* truncate, and the C99 standard requires it, so we might as well change the code to promise truncation and tighten the docs. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-26 12:51 Message: Logged In: YES user_id=31435 Assigned to me. BTW, note that I wasn't guessing about the behavior of "all known Python platforms": Python's test_b1.py has been checking all along that int(float) truncates, so if there were a platform where that didn't happen, we would have heard about it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444510&group_id=5470 From noreply@sourceforge.net Thu Jul 26 21:05:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 13:05:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-444510 ] int() should guarantee truncation Message-ID: Bugs item #444510, was opened at 2001-07-25 09:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444510&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Tim Peters (tim_one) Summary: int() should guarantee truncation Initial Comment: The int() function currently warns that it cannot guarantee truncation because C doesn't guarantee it. However, all known (to us) C implementations *do* truncate, and the C99 standard requires it, so we might as well change the code to promise truncation and tighten the docs. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-26 13:05 Message: Logged In: YES user_id=31435 Truncation now guaranteed. Doc/lib/libfuncs.tex; new revision: 1.81 Lib/test/test_b1.py; new revision: 1.36 Objects/floatobject.c; new revision: 2.83 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-26 12:51 Message: Logged In: YES user_id=31435 Assigned to me. BTW, note that I wasn't guessing about the behavior of "all known Python platforms": Python's test_b1.py has been checking all along that int(float) truncates, so if there were a platform where that didn't happen, we would have heard about it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444510&group_id=5470 From noreply@sourceforge.net Thu Jul 26 21:10:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 13:10:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-444510 ] int() should guarantee truncation Message-ID: Bugs item #444510, was opened at 2001-07-25 09:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444510&group_id=5470 Category: Python Interpreter Core Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Tim Peters (tim_one) Summary: int() should guarantee truncation Initial Comment: The int() function currently warns that it cannot guarantee truncation because C doesn't guarantee it. However, all known (to us) C implementations *do* truncate, and the C99 standard requires it, so we might as well change the code to promise truncation and tighten the docs. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 13:10 Message: Logged In: YES user_id=6380 Cool. But if that test proved it, why bother change the code? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-26 13:05 Message: Logged In: YES user_id=31435 Truncation now guaranteed. Doc/lib/libfuncs.tex; new revision: 1.81 Lib/test/test_b1.py; new revision: 1.36 Objects/floatobject.c; new revision: 2.83 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-26 12:51 Message: Logged In: YES user_id=31435 Assigned to me. BTW, note that I wasn't guessing about the behavior of "all known Python platforms": Python's test_b1.py has been checking all along that int(float) truncates, so if there were a platform where that didn't happen, we would have heard about it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444510&group_id=5470 From noreply@sourceforge.net Thu Jul 26 21:19:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 13:19:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-444510 ] int() should guarantee truncation Message-ID: Bugs item #444510, was opened at 2001-07-25 09:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444510&group_id=5470 Category: Python Interpreter Core Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Tim Peters (tim_one) Summary: int() should guarantee truncation Initial Comment: The int() function currently warns that it cannot guarantee truncation because C doesn't guarantee it. However, all known (to us) C implementations *do* truncate, and the C99 standard requires it, so we might as well change the code to promise truncation and tighten the docs. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-26 13:19 Message: Logged In: YES user_id=31435 Like your commodities salesman is required to tell you, past behavior is no guarantee of future performance. Heck, for all I know, the Cray T3E may not truncate -- don't know whether they ever *got* that far in the test suite. If you want a guarantee, you need code that makes it so regardless. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 13:10 Message: Logged In: YES user_id=6380 Cool. But if that test proved it, why bother change the code? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-26 13:05 Message: Logged In: YES user_id=31435 Truncation now guaranteed. Doc/lib/libfuncs.tex; new revision: 1.81 Lib/test/test_b1.py; new revision: 1.36 Objects/floatobject.c; new revision: 2.83 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-26 12:51 Message: Logged In: YES user_id=31435 Assigned to me. BTW, note that I wasn't guessing about the behavior of "all known Python platforms": Python's test_b1.py has been checking all along that int(float) truncates, so if there were a platform where that didn't happen, we would have heard about it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444510&group_id=5470 From noreply@sourceforge.net Thu Jul 26 21:21:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 13:21:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-444913 ] cgi.FieldStorage doesn't have __nonzero_ Message-ID: Bugs item #444913, was opened at 2001-07-26 13:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444913&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ian Bicking (ianbicking) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.FieldStorage doesn't have __nonzero_ Initial Comment: In some cases cgi.FieldStorage raises an exception on __len__, which means that if you test for truth it will raise an exception (very confusing!). It should just implement def __nonzero__(self): return 1 or something. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444913&group_id=5470 From noreply@sourceforge.net Thu Jul 26 21:24:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 13:24:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-444510 ] int() should guarantee truncation Message-ID: Bugs item #444510, was opened at 2001-07-25 09:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444510&group_id=5470 Category: Python Interpreter Core Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Tim Peters (tim_one) Summary: int() should guarantee truncation Initial Comment: The int() function currently warns that it cannot guarantee truncation because C doesn't guarantee it. However, all known (to us) C implementations *do* truncate, and the C99 standard requires it, so we might as well change the code to promise truncation and tighten the docs. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 13:24 Message: Logged In: YES user_id=6380 I don't know if you worry that what you coded now is slower, but a config-time test could determine whether it's necessary. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-26 13:19 Message: Logged In: YES user_id=31435 Like your commodities salesman is required to tell you, past behavior is no guarantee of future performance. Heck, for all I know, the Cray T3E may not truncate -- don't know whether they ever *got* that far in the test suite. If you want a guarantee, you need code that makes it so regardless. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 13:10 Message: Logged In: YES user_id=6380 Cool. But if that test proved it, why bother change the code? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-26 13:05 Message: Logged In: YES user_id=31435 Truncation now guaranteed. Doc/lib/libfuncs.tex; new revision: 1.81 Lib/test/test_b1.py; new revision: 1.36 Objects/floatobject.c; new revision: 2.83 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-26 12:51 Message: Logged In: YES user_id=31435 Assigned to me. BTW, note that I wasn't guessing about the behavior of "all known Python platforms": Python's test_b1.py has been checking all along that int(float) truncates, so if there were a platform where that didn't happen, we would have heard about it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444510&group_id=5470 From noreply@sourceforge.net Thu Jul 26 21:31:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 13:31:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-444913 ] cgi.FieldStorage doesn't have __nonzero_ Message-ID: Bugs item #444913, was opened at 2001-07-26 13:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444913&group_id=5470 Category: Python Library >Group: Not a Bug >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Ian Bicking (ianbicking) >Assigned to: Guido van Rossum (gvanrossum) Summary: cgi.FieldStorage doesn't have __nonzero_ Initial Comment: In some cases cgi.FieldStorage raises an exception on __len__, which means that if you test for truth it will raise an exception (very confusing!). It should just implement def __nonzero__(self): return 1 or something. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 13:31 Message: Logged In: YES user_id=6380 You shouldn't be testing for truth. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444913&group_id=5470 From noreply@sourceforge.net Thu Jul 26 21:42:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 13:42:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-444510 ] int() should guarantee truncation Message-ID: Bugs item #444510, was opened at 2001-07-25 09:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444510&group_id=5470 Category: Python Interpreter Core Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Tim Peters (tim_one) Summary: int() should guarantee truncation Initial Comment: The int() function currently warns that it cannot guarantee truncation because C doesn't guarantee it. However, all known (to us) C implementations *do* truncate, and the C99 standard requires it, so we might as well change the code to promise truncation and tighten the docs. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-26 13:42 Message: Logged In: YES user_id=31435 I expect the new code is a little faster, becuase it's simpler, requiring fewer tests+branches. The old code had to call one of {ceil, floor}, the new code always calls modf (), and all of {ceil, floor, modf} should cost about the same (they're all picking "the integer part" out of a double; modf has the extra expense of returning the leftover part too, but ceil and floor have the extra expense of examining the leftover part to figure out whether to adjust the raw integer part). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 13:24 Message: Logged In: YES user_id=6380 I don't know if you worry that what you coded now is slower, but a config-time test could determine whether it's necessary. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-26 13:19 Message: Logged In: YES user_id=31435 Like your commodities salesman is required to tell you, past behavior is no guarantee of future performance. Heck, for all I know, the Cray T3E may not truncate -- don't know whether they ever *got* that far in the test suite. If you want a guarantee, you need code that makes it so regardless. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 13:10 Message: Logged In: YES user_id=6380 Cool. But if that test proved it, why bother change the code? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-26 13:05 Message: Logged In: YES user_id=31435 Truncation now guaranteed. Doc/lib/libfuncs.tex; new revision: 1.81 Lib/test/test_b1.py; new revision: 1.36 Objects/floatobject.c; new revision: 2.83 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-26 12:51 Message: Logged In: YES user_id=31435 Assigned to me. BTW, note that I wasn't guessing about the behavior of "all known Python platforms": Python's test_b1.py has been checking all along that int(float) truncates, so if there were a platform where that didn't happen, we would have heard about it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444510&group_id=5470 From noreply@sourceforge.net Thu Jul 26 21:42:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 13:42:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-444913 ] cgi.FieldStorage doesn't have __nonzero_ Message-ID: Bugs item #444913, was opened at 2001-07-26 13:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444913&group_id=5470 Category: Python Library >Group: None >Status: Open Resolution: Wont Fix Priority: 5 Submitted By: Ian Bicking (ianbicking) >Assigned to: Nobody/Anonymous (nobody) Summary: cgi.FieldStorage doesn't have __nonzero_ Initial Comment: In some cases cgi.FieldStorage raises an exception on __len__, which means that if you test for truth it will raise an exception (very confusing!). It should just implement def __nonzero__(self): return 1 or something. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-26 13:42 Message: Logged In: YES user_id=21627 Adding this nonzero method would break backwards-compatibility: Currently, an object created with cgi.FieldStorage() is logically false, whereas it would be true with this change. Can you give an example where you need to check the truth of a FieldStorage? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 13:31 Message: Logged In: YES user_id=6380 You shouldn't be testing for truth. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444913&group_id=5470 From noreply@sourceforge.net Thu Jul 26 21:50:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 13:50:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-444913 ] cgi.FieldStorage doesn't have __nonzero_ Message-ID: Bugs item #444913, was opened at 2001-07-26 13:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444913&group_id=5470 Category: Python Library Group: None Status: Open Resolution: Wont Fix Priority: 5 Submitted By: Ian Bicking (ianbicking) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.FieldStorage doesn't have __nonzero_ Initial Comment: In some cases cgi.FieldStorage raises an exception on __len__, which means that if you test for truth it will raise an exception (very confusing!). It should just implement def __nonzero__(self): return 1 or something. ---------------------------------------------------------------------- >Comment By: Ian Bicking (ianbicking) Date: 2001-07-26 13:50 Message: Logged In: YES user_id=210337 Logically false or true would be fine -- or just capture the exception and return false (or true) on exception from __len__. I was using some code that returned a string or None, but the FieldStorage object on file upload. I wanted None to be '', so I did: value = value or '' And got what at first seemed like a very weird exception (since the call to __len__ was implicit). It would be nice if the FieldStorage for the file upload was true (as it isn't empty). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-26 13:42 Message: Logged In: YES user_id=21627 Adding this nonzero method would break backwards-compatibility: Currently, an object created with cgi.FieldStorage() is logically false, whereas it would be true with this change. Can you give an example where you need to check the truth of a FieldStorage? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 13:31 Message: Logged In: YES user_id=6380 You shouldn't be testing for truth. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444913&group_id=5470 From noreply@sourceforge.net Thu Jul 26 21:52:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 13:52:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-444797 ] dlopen fails loading shared lib modules Message-ID: Bugs item #444797, was opened at 2001-07-26 06:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444797&group_id=5470 Category: Python Interpreter Core Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: dlopen fails loading shared lib modules Initial Comment: If the python interpreter is embedded in (built as) a shared library that can be dynamically loaded by an application, python shared library modules can not be imported on Solaris and IRIX. This works on HP-UX, AIX, and NT. I have implemented a fix in the attached file 'dynload_shlib.c' (from python 2.0). IRIX requires the additional RTLD_GLOBAL 'mode' flag to be passed to the dlopen calls. Solaris requires the additional RTLD_GLOBAL and RTLD_PARENT 'mode' flags to be passed to the dlopen calls (the RTLD_GROUP and RTLD_WORLD flags were OR'd in to preserve the defaults). Please integrate this fix into future versions of python. I can provide more detailed information about the problem if necessary. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-26 13:52 Message: Logged In: YES user_id=21627 Adding RTLD_GLOBAL is *definitely* the wrong thing to do; it will cause extension modules that happen to use the same symbols to conflict if they are used in the same application. Python 2.2 allows a Python application to specify all the flags used in a dlopen file; an embedded Python interpreter could either set dlopenflags using the C API, or from Python code using sys.setdlopenflags. This seems to allow enough customization for the reported problem, therefore I close this bug as fixed, with no further action. If you think there is still a problem, please provide some mini-application that demonstrates this problem. From your description, it is unclear why exactly RTLD_GLOBAL would be needed if the interpreter is in a shared library. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 10:18 Message: Logged In: YES user_id=6380 I've attached a context diff to make it clearer what you changed. Unfortunately, there have been other changes to this file (to allow user control over the dynload flags) so someone (not me) is going to have to do a merge. ---------------------------------------------------------------------- Comment By: Dave Smith (dts) Date: 2001-07-26 10:10 Message: Logged In: YES user_id=281856 I don't see any way to attach a file to an existing bug#, so i've just cut/pasted the file below. --- BEGIN dynload_shlib.c --- /* Support for dynamic loading of extension modules */ #include "Python.h" #include "importdl.h" #include #include #if defined(__NetBSD__) && (NetBSD < 199712) #include #include #define dlerror() "error in dynamic linking" #else #ifdef HAVE_DLFCN_H #include #endif #endif #ifndef RTLD_LAZY #define RTLD_LAZY 1 #endif const struct filedescr _PyImport_DynLoadFiletab[] = { #ifdef __CYGWIN__ {".pyd", "rb", C_EXTENSION}, {".dll", "rb", C_EXTENSION}, #else {".so", "rb", C_EXTENSION}, {"module.so", "rb", C_EXTENSION}, #endif {0, 0} }; static struct { dev_t dev; ino_t ino; void *handle; } handles[128]; static int nhandles = 0; dl_funcptr _PyImport_GetDynLoadFunc(const char *fqname, const char *shortname, const char *pathname, FILE *fp) { dl_funcptr p; void *handle; char funcname[258]; char pathbuf[260]; int mode; if (strchr(pathname, '/') == NULL) { /* Prefix bare filename with "./" */ sprintf(pathbuf, "./%-.255s", pathname); pathname = pathbuf; } /* ### should there be a leading underscore for some platforms? */ sprintf(funcname, "init%.200s", shortname); if (fp != NULL) { int i; struct stat statb; fstat(fileno(fp), &statb); for (i = 0; i < nhandles; i++) { if (statb.st_dev == handles[i].dev && statb.st_ino == handles[i].ino) { p = (dl_funcptr) dlsym(handles[i].handle, funcname); return p; } } if (nhandles < 128) { handles[nhandles].dev = statb.st_dev; handles[nhandles].ino = statb.st_ino; } } mode = RTLD_GLOBAL; #ifdef RTLD_GROUP mode |= RTLD_GROUP; #endif #ifdef RTLD_PARENT mode |= RTLD_PARENT; #endif #ifdef RTLD_WORLD mode |= RTLD_WORLD; #endif #ifdef RTLD_NOW /* RTLD_NOW: resolve externals now (i.e. core dump now if some are missing) */ if (Py_VerboseFlag) printf("dlopen(\%s\, %d);\n", pathname, RTLD_NOW | mode); handle = dlopen(pathname, RTLD_NOW | mode); #else if (Py_VerboseFlag) printf("dlopen(\%s\, %d);\n", pathname, RTLD_LAZY | mode); handle = dlopen(pathname, RTLD_LAZY | mode); #endif /* RTLD_NOW */ if (handle == NULL) { PyErr_SetString(PyExc_ImportError, dlerror()); return NULL; } if (fp != NULL && nhandles < 128) handles[nhandles++].handle = handle; p = (dl_funcptr) dlsym(handle, funcname); return p; } --- END dynload_shlib.c --- ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-26 07:52 Message: Logged In: YES user_id=6380 Sorry, your attachment didn't come through. When you wish to attach a file to a tracker item you must check the checkbox before submitting changes. Please try again and check to make sure that it worked. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444797&group_id=5470 From noreply@sourceforge.net Thu Jul 26 23:56:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 15:56:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-444842 ] array's buffer_info() -> length in bytes Message-ID: Bugs item #444842, was opened at 2001-07-26 08:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444842&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Guido van Rossum (gvanrossum) Summary: array's buffer_info() -> length in bytes Initial Comment: In arraymodule.c, the array's method buffer_info() is documented to return (address, length), where 'length' is measured in bytes. Unfortunately, it currently returns the number of items instead. It should be fixed. Changing the return value could potentially break code relying on the actual (undocumented) behavior. On the other hand, merely changing the documentation to 'officialize' the bug would be a departure from buffer_info()'s original goal to provide direct raw memory access. I think the bug should be fixed, with a note about the different behavior of previous versions in the docs -- for maximum portability, users can always compute the length in bytes separately as "len(a)*a.itemsize". Current users of buffer_info() may already have noticed the bug and used the above formula to get the length, so their code won't break. Fix: in arraymodule.c: array_buffer_info: PyTuple_SET_ITEM(retval, 1, PyInt_FromLong((long)(self->ob_size * self->ob_descr->itemsize))); The multiplication should not overflow (care was taken about it at resize time). Armin ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-07-26 15:56 Message: Logged In: YES user_id=31435 Assigned to Guido cuz it's a mess. buffer_info() has worked this way since it was first checked in (about 4 years ago). Armin is right that it doesn't match the manual or the docstring, and the docs make more sense than what it actually does. Dare we "break" this? Does buffer_info() even serve a purpose now given that arrays also support the buffer interface? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444842&group_id=5470 From noreply@sourceforge.net Fri Jul 27 06:14:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Jul 2001 22:14:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-434143 ] calendar module broken for 1900 Message-ID: Bugs item #434143, was opened at 2001-06-18 04:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434143&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Alexandre Fayolle (afayolle) Assigned to: Skip Montanaro (montanaro) Summary: calendar module broken for 1900 Initial Comment: Hi there, this is a 'feature' I met on both 1.5.2 and 2.1. >>> import calendar >>> calendar.prcal(1865) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/calendar.py", line 160, in prcal print calendar(year, w, l, c), File "/usr/lib/python2.1/calendar.py", line 179, in calendar cal = monthcalendar(year, amonth) File "/usr/lib/python2.1/calendar.py", line 85, in monthcalendar day1, ndays = monthrange(year, month) File "/usr/lib/python2.1/calendar.py", line 78, in monthrange day1 = weekday(year, month, 1) File "/usr/lib/python2.1/calendar.py", line 69, in weekday secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0)) ValueError: year out of range (00-99, 1900-*) (note that the documentation only refers to 1970 as a possible limit, and does not mention how dates in 00-99 range are processed) Now if I try to get the calendar for year 1900 (which is supposed to work according to the message hereabove), I get >>> calendar.prcal(1900) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/calendar.py", line 160, in prcal print calendar(year, w, l, c), File "/usr/lib/python2.1/calendar.py", line 179, in calendar cal = monthcalendar(year, amonth) File "/usr/lib/python2.1/calendar.py", line 85, in monthcalendar day1, ndays = monthrange(year, month) File "/usr/lib/python2.1/calendar.py", line 78, in monthrange day1 = weekday(year, month, 1) File "/usr/lib/python2.1/calendar.py", line 69, in weekday secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0)) OverflowError: mktime argument out of range I guess this is low priority. Cheers Alexandre Fayolle ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-26 22:14 Message: Logged In: NO I think the limitations actually stem from the time module, which depends on the platform you're running. Notice what I get on linux: >>> import calendar >>> a = calendar.calendar(1902) >>> b = calendar.calendar(1901) Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.1/calendar.py", line 181, in calendar cal = monthcalendar(year, amonth) File "/usr/local/lib/python2.1/calendar.py", line 87, in monthcalendar day1, ndays = monthrange(year, month) File "/usr/local/lib/python2.1/calendar.py", line 80, in monthrange day1 = weekday(year, month, 1) File "/usr/local/lib/python2.1/calendar.py", line 71, in weekday secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0)) OverflowError: mktime argument out of range Investigating further, I tried the following: >>> from time import gmtime, mktime >>> gmtime(sys.maxint * -1) (1901, 12, 13, 20, 45, 53, 4, 347, 0) Right there that's suspicious - calendar.calendar() breaks down in the year generated by gmtime(sys.maxint * -1). It gets a bit weird below that point... >>> gmtime(sys.maxint * -1 - 1) (1901, 12, 13, 20, 45, 52, 4, 347, 0) >>> gmtime(sys.maxint * -1 - 2) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer subtraction >>> >>> # OK, now try coercing the argument to a long. >>> gmtime(sys.maxint * -1 - 2L) (1901, 12, 13, 20, 45, 52, 4, 347, 0) >>> mktime(gmtime(sys.maxint * -1 - 2L)) -2147465648.0 >>> mktime(gmtime(sys.maxint * -1 - 1000000L)) -2147465648.0 Looks like we've hit a lower limit there. It would take a competent C programmer (which I am not) to determine whether anything could be done about this. ---------------------------------------------------------------------- Comment By: Alexandre Fayolle (afayolle) Date: 2001-07-19 00:09 Message: Logged In: YES user_id=116727 sounds good to me. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-07-18 13:14 Message: Logged In: YES user_id=44345 I propose sidestepping this issue by fiddling with the documentation. See the attached file time.diff. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2001-07-06 11:40 Message: Logged In: YES user_id=44345 calendar.py is a *very* old module. Version 1.1 has a date of 13-Oct-90. The message about the ranges almost certainly comes from the days when Guido and his pals at CWI were developing Python on Macs. I just tried: time.mktime((1900,1,1,0,0,0,0,0,0)) on my iMac and it works. If the year is 1899 it generates the traceback. A year of 1 is currently interpreted as 2001. I'm not sure this is worth fixing, other than to document the limitations better. If you want to display calendars perhaps you should look at Marc-Andre Lemburg's mx.DateTime module, which supports a much wider range of dates. Skip ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434143&group_id=5470 From noreply@sourceforge.net Fri Jul 27 10:18:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Jul 2001 02:18:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-445096 ] hasattr does not support name mangling Message-ID: Bugs item #445096, was opened at 2001-07-27 02:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445096&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: asbjorn christensen (asbjorntheman) Assigned to: Nobody/Anonymous (nobody) Summary: hasattr does not support name mangling Initial Comment: ----------------------------------------------- Description = Apparently hasattr() is not aware of the name mangling performed on instance attributes with names "__somename", so that hasattr(self, "__somename") generally gives false I have provided an example below. It is easy to circumvent (e.g. with a try clause), but most programmers will find this behavior of hasattr() unexpected. It would be nice to have it ironed out. I'm not deeply enough into the parser to provide a fix myself, sorry. Unfortunately, I don't have access to platforms running Python version > 1.5.2 I was not able to find this problem mentioned in the bug reports Best wishes, Asbjorn ----------------------------------------------- Version details = Python 1.5.2 (#1, Mar 3 2001, 01:35:43) [GCC 2.96 20000731 (Red Hat Linux 7.1 2 on linux-i386 ----------------------------------------------- Example = class a: def __init__(self, x): self.__dat = x def test(self): print "hasattr(self, '__dat') =", hasattr(self, '__dat') print "hasattr(self, '_a__dat') =", hasattr(self, '_a__dat') print "self.__dat= =", self.__dat an_a = a(77) an_a.test() --------------------------------------------------- Std output = hasattr(self, '__dat') = 0 hasattr(self, '_a__dat') = 1 self.__dat= = 77 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445096&group_id=5470 From noreply@sourceforge.net Fri Jul 27 13:32:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Jul 2001 05:32:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-445096 ] hasattr does not support name mangling Message-ID: Bugs item #445096, was opened at 2001-07-27 02:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445096&group_id=5470 Category: Parser/Compiler >Group: Not a Bug >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: asbjorn christensen (asbjorntheman) >Assigned to: Guido van Rossum (gvanrossum) Summary: hasattr does not support name mangling Initial Comment: ----------------------------------------------- Description = Apparently hasattr() is not aware of the name mangling performed on instance attributes with names "__somename", so that hasattr(self, "__somename") generally gives false I have provided an example below. It is easy to circumvent (e.g. with a try clause), but most programmers will find this behavior of hasattr() unexpected. It would be nice to have it ironed out. I'm not deeply enough into the parser to provide a fix myself, sorry. Unfortunately, I don't have access to platforms running Python version > 1.5.2 I was not able to find this problem mentioned in the bug reports Best wishes, Asbjorn ----------------------------------------------- Version details = Python 1.5.2 (#1, Mar 3 2001, 01:35:43) [GCC 2.96 20000731 (Red Hat Linux 7.1 2 on linux-i386 ----------------------------------------------- Example = class a: def __init__(self, x): self.__dat = x def test(self): print "hasattr(self, '__dat') =", hasattr(self, '__dat') print "hasattr(self, '_a__dat') =", hasattr(self, '_a__dat') print "self.__dat= =", self.__dat an_a = a(77) an_a.test() --------------------------------------------------- Std output = hasattr(self, '__dat') = 0 hasattr(self, '_a__dat') = 1 self.__dat= = 77 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-27 05:32 Message: Logged In: YES user_id=6380 This is intentional behavior. The name mangling implementation is documented, and that is how you are supposed to do it. Besides, hasattr() doesn't have the class name available to do the mangling. Note that getttr(), setattr() and delattr() have the same behavior. Closing this bug, as it's not a bug. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445096&group_id=5470 From noreply@sourceforge.net Fri Jul 27 15:28:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Jul 2001 07:28:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-439710 ] User-defined mime.types file Message-ID: Bugs item #439710, was opened at 2001-07-09 06:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439710&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: User-defined mime.types file Initial Comment: Zope users sometimes asks to add additional mime.types entries to Zope. Zopes mime-types handling is mostly based on mimetypes.py. In such cases users should be able to maintain their own mime.types files. mimetypes.py currently tries to look for mime.types files in 4 hardcoded locations. It would be more convinient to specify additional locations e.g. by an env. var that holds a list of additional locations or by any other mechanism that allows user-defined locations. The hardcoded locations also don't work on Windows. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-27 07:28 Message: Logged In: YES user_id=3066 OK, I really should update the version here to be the fixed one; sorry about the broken versions! If there are no objections, I'll check this in soon. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-23 19:51 Message: Logged In: YES user_id=3066 I've attached a new version of mimetypes.py; something like this should do the trick and be easy to extend as needed. Comments welcome. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2001-07-23 13:12 Message: Logged In: YES user_id=11084 A more OO approach would be nice. At least a possibility to add "somehow" different file locations. I have not special preference for any solution. Andreas ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-23 13:07 Message: Logged In: YES user_id=3066 Sounds like there should be an object which can be configured with a search path at construction time. Applications could then store an appropriate mime.types file in a location that makes sense for them. Would this suite your purposes? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439710&group_id=5470 From noreply@sourceforge.net Fri Jul 27 16:19:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Jul 2001 08:19:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-445196 ] Malformed &entities; break HTMLParser Message-ID: Bugs item #445196, was opened at 2001-07-27 08:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445196&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Malformed &entities; break HTMLParser Initial Comment: This bug affects both the Python standard library and Zope TAL. Input such as this: “Backwards substitution” in a Page Template results in this error: 'foo' def remove_quotation_mark(s): return re.sub('^"(.*)"$', "\1", s) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446136&group_id=5470 From noreply@sourceforge.net Mon Jul 30 22:53:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Jul 2001 14:53:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-443866 ] Evaluating func_code causing core dump Message-ID: Bugs item #443866, was opened at 2001-07-23 10:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443866&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open >Resolution: Later >Priority: 3 Submitted By: Jonathan Hogg (jhogg) Assigned to: Jeremy Hylton (jhylton) Summary: Evaluating func_code causing core dump Initial Comment: Python 2.2a1 (#1, Jul 19 2001, 18:18:51) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)] on linux2 The intepreter dies hard if you directly evaluate the func_code of a function that has a closure. E.g.: ----- def func1(): return lambda: 4 + y f = func1() print "Ugly test 1:", eval( f.func_code, {'y': 38} ) def func2(x): return lambda: x + y f = func2(4) print "Ugly test 2:", eval( f.func_code, {'y': 38} ) ----- The second eval will cause a core dump on UNIX. The offending code is in PyEval_EvalCodeEx() of ceval.c line 2466. This loop attempts to match free vars against the closure, but the closure is NULL if the function is called with eval. I know this is very broken usage of the interpreter, but it should die more cleanly than a core dump ;-) ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-07-30 14:53 Message: Logged In: YES user_id=31392 It might be useful to extend eval() with a means to specify bindings from free variables. It's not at all clear how to do this under the current implementation, which refers to free variables using integer indexes assigned at compile time. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-07-30 14:51 Message: Logged In: YES user_id=31392 Fixed in rev 2.219 of bltinmodule.c ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-07-24 15:35 Message: Logged In: YES user_id=31435 Assigned to Jeremy in the hopes this will speed his return to us . ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443866&group_id=5470 From noreply@sourceforge.net Mon Jul 30 23:40:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Jul 2001 15:40:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-445928 ] UnboundLocalError in httplib.py Message-ID: Bugs item #445928, was opened at 2001-07-30 05:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445928&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Martin v. Löwis (loewis) Summary: UnboundLocalError in httplib.py Initial Comment: Python 2.2a0 (#1, 07/30/01, 13:21:09) [GCC Apple DevKit-based CPP 6.0alpha] on darwin1 Type "help", "copyright", "credits" or "license" for more information. >>> import urllib >>> f = urllib.urlopen("http://www.letterror.com/") Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.2/urllib.py", line 71, in urlopen return _urlopener.open(url) File "/usr/local/lib/python2.2/urllib.py", line 176, in open return getattr(self, name)(url) File "/usr/local/lib/python2.2/urllib.py", line 283, in open_http h.putrequest('GET', selector) File "/usr/local/lib/python2.2/httplib.py", line 449, in putrequest self.send(str) File "/usr/local/lib/python2.2/httplib.py", line 391, in send self.connect() File "/usr/local/lib/python2.2/httplib.py", line 375, in connect raise socket.error, msg UnboundLocalError: local variable 'msg' referenced before assignment >>> ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-07-30 15:40 Message: Logged In: YES user_id=21627 I believe getaddrinfo must never return an empty list. If lookup fails, it shall raise an exception. From the Solaris manpage For getaddrinfo(), if the query is successful, a pointer to a linked list of one or more addrinfo structures is returned by the fourth argument and the function returns 0. If the query fails, a non-zero error code will be returned. So returning a 0 result and an empty list is an implementation bug in getaddrinfo (or an incorrect call to it). If we want to protect us against buggy implementations, we should do BadInternalCall or similar in the C code, instead of dealing with the impossible case in Python. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-30 10:39 Message: Logged In: YES user_id=6380 But even if getaddrinfo() returns an empty list, this error should not occur. You may have to initialize msg to something and do something differently at the end when msg is still None. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-30 08:42 Message: Logged In: YES user_id=21627 It appears that Darwin does provide getaddrinfo. I'm not sure why it doesn't work. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2001-07-30 07:43 Message: Logged In: YES user_id=92689 socketmodule.c: 1.157 getaddrinfo.c: 1.6 socket.getaddrinfo('www.letterror.com',80,0,socket.SOCK_STREA M) indeed returns an empty list. I can try to give you access, but I'll have to fiddle with permissions. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-30 07:16 Message: Logged In: YES user_id=21627 Can you please indicate what version of socketmodule.c and getaddrinfo.c was used for this build? Please report the result of import socket socket.getaddrinfo('www.letterror.com',80,0,socket.SOCK_STREAM) It should be something like [(2, 2, 0, '', ('216.218.226.21', 80))] If it is an empty list (as it appears from the error message), can you please try step through PySocket_getaddrinfo with a debugger and analyse why it doesn't find out the IP address? If not, is there a chance to get access to such a machine to debug it myself remotely? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445928&group_id=5470 From noreply@sourceforge.net Mon Jul 30 23:41:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Jul 2001 15:41:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-420304 ] getattr function w/ default Message-ID: Bugs item #420304, was opened at 2001-04-30 17:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420304&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Greg Chapman (glchapman) Assigned to: Jeremy Hylton (jhylton) Summary: getattr function w/ default Initial Comment: In Python 2.1, when calling the builtin getattr function and supplying the (optional) default argument, this default is returned on any exception raised during PyObject_GetAttr, even if the exception is not an AttributeError. I did not expect this behavior after reading the getattr documentation. Is this the intended behavior? (If so, I think the documentation should be made clearer on this point.) Example (providing a non-string as the attribute name): >>> class Test: ... pass ... >>> t = Test() >>> getattr(t, 1, "hello") 'hello' >>> ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2001-07-30 15:41 Message: Logged In: YES user_id=31392 Don't think there's any actual dissent here. You, Michael, and I all seem to agree. I'll commit Michael's suggestion and live with the duplicated code. Fixed in rev 2.220 of bltinmodule.c ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-05-22 18:18 Message: Logged In: YES user_id=31435 Oh no: getattr hooks can raise any exception whatsoever, and existing code relies on getattr() treating any exception whatsoever as meaning "no attribute of that name". For example, IndexError and KeyError are often raised naturally by getattr hooks that fail to resolve a name via tree or dict structures. The specific complaint here is a different story: the docs say the attribute argument must be a string (Unicode, whatever -- "a string" ), and I agree that calling getattr() with something other than a string argument should raise a TypeError instead of pretending it's a *possible* attribute name and that there simply isn't any attribute with that name (it's not a name at all, so the call doesn't make sense). Jeremy, I see this is assigned to you now. There are enough conflicting opinions here (at least Michael's and mine seem to coincide) that perhaps it's time to dump it on Guido for Pronouncement. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-05-22 13:13 Message: Logged In: YES user_id=38388 I guess the right thing to do here, would be to only mask AttributeErrors in the getattr() builtin. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-05-22 11:42 Message: Logged In: YES user_id=6656 Well, the patch I posted below allows unicode (though admittedly only for strings that can be encoded using the default encoding). Have you read the code to object.c:PyObject_GetAttr? All my code does is hoist some of the error checking out of there into getattr to better decide whether to return the provided default value. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-05-22 11:29 Message: Logged In: YES user_id=89016 But unicode attr arguments should be allowed, because someday in the far future Python might be unicode based. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-05-07 21:26 Message: Logged In: YES user_id=31392 This looks like a bug to me, too. I think a non-string attr argument to getattr() should raise TypeError. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-05-04 04:11 Message: Logged In: YES user_id=6656 But consider this: >>> getattr({},1) Traceback (most recent call last): File "", line 1, in ? TypeError: attribute name must be string >>> getattr({},1,"e") 'e' or >>> getattr(None,u"\343","e") 'e' >>> getattr(None,u"\343") Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range(128) Here's a possible patch: Index: bltinmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/bltinmodule.c,v retrieving revision 2.200 diff -c -r2.200 bltinmodule.c *** bltinmodule.c 2001/05/02 07:39:38 2.200 --- bltinmodule.c 2001/05/04 11:09:35 *************** *** 845,850 **** --- 845,854 ---- The globals and locals are dictionaries, defaulting to the current\n\ globals and locals. If only globals is given, locals defaults to it."; + /* Internal API needed by builtin_getattr(): */ + extern + PyObject *_PyUnicode_AsDefaultEncodedString(PyObject *unicode, + const char *errors); static PyObject * builtin_getattr(PyObject *self, PyObject *args) *************** *** 854,859 **** --- 858,874 ---- if (!PyArg_ParseTuple(args, "OO|O:getattr", &v, &name, &dflt)) return NULL; + if (PyUnicode_Check(name)) { + name = _PyUnicode_AsDefaultEncodedString(name, NULL); + if (name == NULL) + return NULL; + } + else if (!PyString_Check(name)) { + PyErr_Format(PyExc_TypeError, + "getattr: attribute name must be string, not \%.500s\", + name->ob_type->tp_name); + return NULL; + } result = PyObject_GetAttr(v, name); if (result == NULL && dflt != NULL) { PyErr_Clear(); ... though by the time you've done all that, there's not much point in calling PyObject_GetAttr at all... OTOH, this changes behaviour, so maybe one should just clarify this in the docs. ---------------------------------------------------------------------- Comment By: Chris Cogdon (chriscog) Date: 2001-05-03 17:55 Message: Logged In: YES user_id=67116 Looks like an attribute error to me. consider this: >>> getattr (t,fred,"thingy") Traceback (most recent call last): File "", line 1, in ? NameError: There is no variable named 'fred' Ie, in your own example, it couldn't find an attribute '1' in the class, even if its an integer attribute (which is only obtainable using getattr/setattr). That's exactly what AttributeError is ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420304&group_id=5470 From noreply@sourceforge.net Tue Jul 31 03:00:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Jul 2001 19:00:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-445928 ] UnboundLocalError in httplib.py Message-ID: Bugs item #445928, was opened at 2001-07-30 05:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445928&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Martin v. Löwis (loewis) Summary: UnboundLocalError in httplib.py Initial Comment: Python 2.2a0 (#1, 07/30/01, 13:21:09) [GCC Apple DevKit-based CPP 6.0alpha] on darwin1 Type "help", "copyright", "credits" or "license" for more information. >>> import urllib >>> f = urllib.urlopen("http://www.letterror.com/") Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.2/urllib.py", line 71, in urlopen return _urlopener.open(url) File "/usr/local/lib/python2.2/urllib.py", line 176, in open return getattr(self, name)(url) File "/usr/local/lib/python2.2/urllib.py", line 283, in open_http h.putrequest('GET', selector) File "/usr/local/lib/python2.2/httplib.py", line 449, in putrequest self.send(str) File "/usr/local/lib/python2.2/httplib.py", line 391, in send self.connect() File "/usr/local/lib/python2.2/httplib.py", line 375, in connect raise socket.error, msg UnboundLocalError: local variable 'msg' referenced before assignment >>> ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-30 19:00 Message: Logged In: YES user_id=6380 IMO it's still ugly to have code that relies on a variable set in an except clause in a for loop. Any decent compile-time checker would flag this as a potential error. No matter how getaddrinfo() is fixed, I think httplib.py should be made more robust as well. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-30 15:40 Message: Logged In: YES user_id=21627 I believe getaddrinfo must never return an empty list. If lookup fails, it shall raise an exception. From the Solaris manpage For getaddrinfo(), if the query is successful, a pointer to a linked list of one or more addrinfo structures is returned by the fourth argument and the function returns 0. If the query fails, a non-zero error code will be returned. So returning a 0 result and an empty list is an implementation bug in getaddrinfo (or an incorrect call to it). If we want to protect us against buggy implementations, we should do BadInternalCall or similar in the C code, instead of dealing with the impossible case in Python. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-30 10:39 Message: Logged In: YES user_id=6380 But even if getaddrinfo() returns an empty list, this error should not occur. You may have to initialize msg to something and do something differently at the end when msg is still None. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-30 08:42 Message: Logged In: YES user_id=21627 It appears that Darwin does provide getaddrinfo. I'm not sure why it doesn't work. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2001-07-30 07:43 Message: Logged In: YES user_id=92689 socketmodule.c: 1.157 getaddrinfo.c: 1.6 socket.getaddrinfo('www.letterror.com',80,0,socket.SOCK_STREA M) indeed returns an empty list. I can try to give you access, but I'll have to fiddle with permissions. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-07-30 07:16 Message: Logged In: YES user_id=21627 Can you please indicate what version of socketmodule.c and getaddrinfo.c was used for this build? Please report the result of import socket socket.getaddrinfo('www.letterror.com',80,0,socket.SOCK_STREAM) It should be something like [(2, 2, 0, '', ('216.218.226.21', 80))] If it is an empty list (as it appears from the error message), can you please try step through PySocket_getaddrinfo with a debugger and analyse why it doesn't find out the IP address? If not, is there a chance to get access to such a machine to debug it myself remotely? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445928&group_id=5470 From noreply@sourceforge.net Tue Jul 31 04:45:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Jul 2001 20:45:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-446219 ] sndhdr.what() fails on some WAV files Message-ID: Bugs item #446219, was opened at 2001-07-30 20:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446219&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Popplewell (johnnypops) Assigned to: Nobody/Anonymous (nobody) Summary: sndhdr.what() fails on some WAV files Initial Comment: Currently using Python 2.0.1 [final] on Windows 95/98/2K. Bug probably only affects Windows >>>import sndhdr >>>print sndhdr.what('audio.wav') None Should display: ('wav', 44100, 1, -1, 16) Occurs with WAV files that have a header starting : 52 49 46 46 24 1A 01 00 ; RIFF$... I think it is the ^Z that is screwing things up. The fix for the code in "sndhdr.py" is : def whathdr(filename): """Recognize sound headers""" f = open(filename, 'rb') h = f.read(512) ... If the file is opened in binary mode then everything is OK. cheers, John Popplewell ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446219&group_id=5470 From noreply@sourceforge.net Tue Jul 31 07:28:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Jul 2001 23:28:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-446219 ] sndhdr.what() fails on some WAV files Message-ID: Bugs item #446219, was opened at 2001-07-30 20:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446219&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: John Popplewell (johnnypops) >Assigned to: Guido van Rossum (gvanrossum) Summary: sndhdr.what() fails on some WAV files Initial Comment: Currently using Python 2.0.1 [final] on Windows 95/98/2K. Bug probably only affects Windows >>>import sndhdr >>>print sndhdr.what('audio.wav') None Should display: ('wav', 44100, 1, -1, 16) Occurs with WAV files that have a header starting : 52 49 46 46 24 1A 01 00 ; RIFF$... I think it is the ^Z that is screwing things up. The fix for the code in "sndhdr.py" is : def whathdr(filename): """Recognize sound headers""" f = open(filename, 'rb') h = f.read(512) ... If the file is opened in binary mode then everything is OK. cheers, John Popplewell ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-30 23:28 Message: Logged In: YES user_id=6380 Thanks! Fixed in CVS now. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446219&group_id=5470 From noreply@sourceforge.net Tue Jul 31 13:51:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Jul 2001 05:51:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-446375 ] Python 2.2a1 List functionality Message-ID: Bugs item #446375, was opened at 2001-07-31 05:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446375&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: Python 2.2a1 List functionality Initial Comment: a= [1,2,3] b= list([1,2,3]) a == b gives a result of 1 - Good type(a) == type(b) gives a result of 1 - Not good a and b have different methods. Perhaps the list class should be 'List' to (a) distinguish between the two types and (b) to follow the convention that class names start with an upper case letter. ------------------------------------------------------------------------ b.__add__(22) gives a warning - Good b.__radd__(22) crashes W95 OSR2 - Very Bad cjw ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446375&group_id=5470 From noreply@sourceforge.net Tue Jul 31 14:07:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Jul 2001 06:07:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-446375 ] Python 2.2a1 List functionality Message-ID: Bugs item #446375, was opened at 2001-07-31 05:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446375&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) >Assigned to: Guido van Rossum (gvanrossum) Summary: Python 2.2a1 List functionality Initial Comment: a= [1,2,3] b= list([1,2,3]) a == b gives a result of 1 - Good type(a) == type(b) gives a result of 1 - Not good a and b have different methods. Perhaps the list class should be 'List' to (a) distinguish between the two types and (b) to follow the convention that class names start with an upper case letter. ------------------------------------------------------------------------ b.__add__(22) gives a warning - Good b.__radd__(22) crashes W95 OSR2 - Very Bad cjw ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-31 06:07 Message: Logged In: YES user_id=6380 The first result is how it's supposed to be! list() returns a list. I don't know why you expected the type comparison not to return 1. The __radd__ crash is a bug that I'll fix -- Thanks for reporting! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446375&group_id=5470 From noreply@sourceforge.net Tue Jul 31 17:53:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Jul 2001 09:53:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-446375 ] Python 2.2a1 List functionality Message-ID: Bugs item #446375, was opened at 2001-07-31 05:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446375&group_id=5470 >Category: type/class unification >Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Guido van Rossum (gvanrossum) Summary: Python 2.2a1 List functionality Initial Comment: a= [1,2,3] b= list([1,2,3]) a == b gives a result of 1 - Good type(a) == type(b) gives a result of 1 - Not good a and b have different methods. Perhaps the list class should be 'List' to (a) distinguish between the two types and (b) to follow the convention that class names start with an upper case letter. ------------------------------------------------------------------------ b.__add__(22) gives a warning - Good b.__radd__(22) crashes W95 OSR2 - Very Bad cjw ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-31 09:53 Message: Logged In: YES user_id=6380 I've checked in a fix to the __radd__ problem. The solution is to not support __radd__ for sequences, since the sq_concat slot really only dispatches on the first arg. Closing this bug now. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-31 06:07 Message: Logged In: YES user_id=6380 The first result is how it's supposed to be! list() returns a list. I don't know why you expected the type comparison not to return 1. The __radd__ crash is a bug that I'll fix -- Thanks for reporting! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446375&group_id=5470 From noreply@sourceforge.net Tue Jul 31 20:50:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Jul 2001 12:50:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-446525 ] python 2.1 debug library missing _sre? Message-ID: Bugs item #446525, was opened at 2001-07-31 12:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446525&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.1 debug library missing _sre? Initial Comment: I downloaded the most current python 2.1 debug library as follows: Python-2.1-Debug.zip 16-Apr-2001 23:06 1.3M ZIP archive After initialization of the interpreter, a simple call like "PyRun_SimpleString("import re");" will return the following error: Traceback (most recent call last): ... File "c:\python21\lib\sre_compile.py", line 11, in ? import _sre ImportError: No module named _sre By comparision, running the same code using the Python Release library gives no such problem. Is this a bug? Much Thanks, Hugo ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446525&group_id=5470 From noreply@sourceforge.net Tue Jul 31 21:55:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Jul 2001 13:55:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-446551 ] profiler invents error in nested scopes Message-ID: Bugs item #446551, was opened at 2001-07-31 13:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446551&group_id=5470 Category: Python Library Group: Python 2.1.1 Status: Open Resolution: None Priority: 5 Submitted By: W. G. Mitchener (caeshmer) Assigned to: Nobody/Anonymous (nobody) Summary: profiler invents error in nested scopes Initial Comment: I'm trying to use the profiler in the Python 2.1 RPM on Red Hat 7.0. Here's the most reduced form of problem I could come up with. This is the file ProfilerBug.py: from __future__ import nested_scopes class Spam: def __init__(self, x, y, z): eggs = (self, x, y, z) a = 4 b = 5 c = 6 def f(t): return a + b + c + t def _test1(): pr = Spam(1, 2, 3) If I do this: Python 2.1 (#1, Jul 13 2001, 10:27:46) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import ProfilerBug >>> ProfilerBug._test1() >>> there's no error. But here's what I get when I run the profiler: Python 2.1 (#1, Jul 13 2001, 10:27:46) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import profile >>> import ProfilerBug >>> profile.run('ProfilerBug._test1()') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/profile.py", line 71, in run prof = prof.run(statement) File "/usr/lib/python2.1/profile.py", line 356, in run return self.runctx(cmd, dict, dict) File "/usr/lib/python2.1/profile.py", line 362, in runctx exec cmd in globals, locals File "", line 1, in ? File "ProfilerBug.py", line 15, in _test1 pr = Spam(1, 2, 3) File "ProfilerBug.py", line 6, in __init__ eggs = (self, x, y, z) UnboundLocalError: local variable 'self' referenced before assignment It has something to do with nested scopes, because if I comment out the definition of f, the error goes away. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446551&group_id=5470 From noreply@sourceforge.net Tue Jul 31 23:17:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 31 Jul 2001 15:17:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-446588 ] Python-2.2a1 build dies Message-ID: Bugs item #446588, was opened at 2001-07-31 15:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446588&group_id=5470 Category: Build Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Python-2.2a1 build dies Initial Comment: after doing: ./configure --prefix=$HOME/local/STOW make the build bombs in the install phase with: usr/bin/install -c ./install-sh /home/mahler/local/STOW/Python-2.2a1/lib/python2.2/config/install-sh /usr/bin/install -c -m 644 ./Misc/Makefile.pre.in /home/mahler/local/STOW/Python-2.2a1/lib/python2.2/config/Makefile.pre.in PYTHONPATH= ./python ./setup.py install \ --install-platlib=/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/lib-dynload 'import site' failed; use -v for traceback Traceback (most recent call last): File "./setup.py", line 6, in ? import sys, os, getopt ImportError: No module named os make[1]: *** [sharedinstall] Error 1 make[1]: Leaving directory `/mcallister0/home/mahler/local/SRC/Python-2.2a1' make: *** [STOW/Python-2.2a1] Error 2 rm SRC/Python-2.2a1make: unlink: SRC/Python-2.2a1: Is a directory STOW/Python-2.2a1make: unlink: STOW/Python-2.2a1: Is a directory SRC/Python-2.2a1/Makefile ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446588&group_id=5470