From noreply at sourceforge.net Mon Dec 1 00:25:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 00:26:05 2003 Subject: [ python-Bugs-850110 ] Out of order commands excecution? Message-ID: Bugs item #850110, was opened at 2003-11-27 03:54 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850110&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: Invalid Priority: 5 Submitted By: Nadav Horesh (nadavhoresh) Assigned to: Michael Hudson (mwh) Summary: Out of order commands excecution? Initial Comment: Consider the following: >>> import string >>> def test1(): join = string.join >>> def test2(): join = string.join string = string.split >>> test1() >>> test2() Traceback (most recent call last): File "", line 1, in -toplevel- test2() File "", line 2, in test2 join = string.join UnboundLocalError: local variable 'string' referenced before assignment >>> How the second statement in test2 generates an error in first one? Nadav. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-01 00:25 Message: Logged In: YES user_id=33168 If a variable is local in a function, it is local throughout the whole function. It doesn't become local at the first assignment, but from the beginning of the function. Does that help? ---------------------------------------------------------------------- Comment By: Nadav Horesh (nadavhoresh) Date: 2003-11-30 14:26 Message: Logged In: YES user_id=75473 I've looked at the FAQ and it is not seems to sesolve the issue: In test2 "string" becomes a local variable in the second line, while in the first line (join = string.join) "string" should point to the (global) string module. Nadav. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-11-27 07:09 Message: Logged In: YES user_id=6656 Well, that's just how it works. This must be documented somewhere... see if http://www.python.org/doc/faq/programming.html#what-are-the-rules-for-local-and-global-variables-in-python helps (and maybe the question before). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850110&group_id=5470 From noreply at sourceforge.net Mon Dec 1 01:06:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 01:06:10 2003 Subject: [ python-Bugs-850964 ] optparse: OptionParser.__init__'s "prog" argument ignored Message-ID: Bugs item #850964, was opened at 2003-11-29 08:48 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850964&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Mueller (yuurei) Assigned to: Greg Ward (gward) Summary: optparse: OptionParser.__init__'s "prog" argument ignored Initial Comment: optparse uses sys.argv[0] for the program name even if you supply the prog argument to OptionParser.__init__ ie, if you have p = OptionParser(prog='NEW_NAME'), p.print_usage, p.print_help, p.error, etc. don't use NEW_NAME as %prog. This is with Python 2.3.2 ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-12-01 15:06 Message: Logged In: YES user_id=671362 I've submitted a patch. See : http://www.python.org/sf/851902 Please apply the patch and check if "prog" argument works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850964&group_id=5470 From noreply at sourceforge.net Mon Dec 1 05:38:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 05:38:38 2003 Subject: [ python-Bugs-848812 ] Inconsistent list.__add__/__addi__. Message-ID: Bugs item #848812, was opened at 2003-11-25 04:50 Message generated for change (Comment added) made by jemfinch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848812&group_id=5470 Category: None Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent list.__add__/__addi__. Initial Comment: >>> L = [1,2,3] >>> L + (1,2,3) Traceback (most recent call last): File "", line 1, in ? TypeError: can only concatenate list (not "tuple") to list >>> L += (1,2,3) >>> L [1, 2, 3, 1, 2, 3] I've always been somewhat annoyed that list.__add__ didn't accept any iterable (just lists), but to have += accept any iterable but not + is just plain inconsistent. ---------------------------------------------------------------------- >Comment By: Jeremy Fincher (jemfinch) Date: 2003-12-01 05:38 Message: Logged In: YES user_id=99508 Neither google nor the CVS log for Objects/listobject.c turned up any past discussion or pronouncement on this. Which behavior is more desirable may not be up for debate, but it's still highly inconsistent to have += work in places where + does not. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-29 03:44 Message: Logged In: YES user_id=80475 It's a feature, not a bug. The goal is to eliminate unattractive, error prone constructions. Probe the archives for past discussion and pronouncement on this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848812&group_id=5470 From noreply at sourceforge.net Mon Dec 1 05:46:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 05:46:51 2003 Subject: [ python-Bugs-848812 ] Inconsistent list.__add__/__addi__. Message-ID: Bugs item #848812, was opened at 2003-11-25 04:50 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848812&group_id=5470 Category: None Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent list.__add__/__addi__. Initial Comment: >>> L = [1,2,3] >>> L + (1,2,3) Traceback (most recent call last): File "", line 1, in ? TypeError: can only concatenate list (not "tuple") to list >>> L += (1,2,3) >>> L [1, 2, 3, 1, 2, 3] I've always been somewhat annoyed that list.__add__ didn't accept any iterable (just lists), but to have += accept any iterable but not + is just plain inconsistent. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-01 05:46 Message: Logged In: YES user_id=80475 I think Guido said if he had it to do over, += would not be able to take any iterable. However, that behavior has been set in stone for several years now and it would be hard to take away. The rule for new types like set() is that both | and |= require the right hand argument to be of the same type. However, the corresponding spelled out name, set.update() may take any iterable as a argument. The idea is that: s |= 'boom' is more error prone and less clean than s.update('boom') ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-12-01 05:38 Message: Logged In: YES user_id=99508 Neither google nor the CVS log for Objects/listobject.c turned up any past discussion or pronouncement on this. Which behavior is more desirable may not be up for debate, but it's still highly inconsistent to have += work in places where + does not. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-29 03:44 Message: Logged In: YES user_id=80475 It's a feature, not a bug. The goal is to eliminate unattractive, error prone constructions. Probe the archives for past discussion and pronouncement on this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848812&group_id=5470 From noreply at sourceforge.net Mon Dec 1 05:52:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 05:52:18 2003 Subject: [ python-Bugs-851449 ] New-style classes with __eq__ but not __hash__ are hashable Message-ID: Bugs item #851449, was opened at 2003-11-30 00:40 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851449&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Edward Loper (edloper) Assigned to: Nobody/Anonymous (nobody) Summary: New-style classes with __eq__ but not __hash__ are hashable Initial Comment: According to the current reference docs, "If [a class] defines __cmp__() or __eq__() but not __hash__(), its instances will not be usable as dictionary keys. [1] But this doesn't work quite like you'd think for new-style classes: Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> class A(object): ... def __cmp__(self, other): return -1 >>> print {A():1} {<__main__.A object at 0x71cf0>: 1} The problem is that object defines a default __hash__ method: >>> print A.__hash__ So the dictionary class thinks that the object is hashable. But given that we've overridden cmp, there's no reason to believe that __hash__ is still valid. The only workaround I've found is to manually add a __hash__ method that raises the appropriate exception: >>> class A(object): ... def __cmp__(self, other): return -1 ... def __hash__(self): ... raise TypeError, ('%s objects are unhashable' % ... self.__class__) But it seems like this should be fixed in Python itself. I can think of 2 reasonable ways to fix it: - change object.__hash__() to raise a TypeError if __cmp__ or __eq__ is overridden. - change hash() to raise a TypeError if given an object that overrides __cmp__ or __eq__ but not __hash__. So.. Is this a real bug, or am I missing something? And if so, what's the prefered place to fix it? (I'd be happy to try to put together a patch for it, if it is indeed broken.) -Edward [1] http://www.python.org/doc/current/ref/ customization.html ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-01 05:52 Message: Logged In: YES user_id=80475 It has been a subject of debate but the behavior is already cast in stone. Anything inheriting from object is hashable by default. The preferred way to make things unhashable is: def __hash__(self) return NotImplemented ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851449&group_id=5470 From noreply at sourceforge.net Mon Dec 1 07:19:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 07:19:17 2003 Subject: [ python-Bugs-848856 ] couple of new list.sort bugs Message-ID: Bugs item #848856, was opened at 2003-11-25 11:12 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848856&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Michael Hudson (mwh) Summary: couple of new list.sort bugs Initial Comment: I really feel I should apologise for this one: [mwh@pc150 build-debug]$ cat t.py class SortKiller(object): def __init__(self, i): pass def __del__(self): del l[:] l = range(10) l.sort(key=SortKiller) [mwh@pc150 build-debug]$ ./python t.py Segmentation fault This can be fixed by moving the "restoring the objects of the list from the wrappers" code *before* the "put saved_ob_item back in the list" code. The second is less serious but probably more annoying to fix: [mwh@pc150 build-debug]$ cat u.py def k(x): return 1/x l = range(-2,2) try: l.sort(key=k) except ZeroDivisionError: pass print l [mwh@pc150 build-debug]$ ./python u.py [, , 0, 1] [6571 refs] ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-29 01:56 Message: Logged In: YES user_id=80475 The second was easy to fix. The first is defying my attempts to fix it. You're welcome to take a crack at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848856&group_id=5470 From noreply at sourceforge.net Mon Dec 1 07:34:55 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 07:35:03 2003 Subject: [ python-Bugs-850110 ] Out of order commands excecution? Message-ID: Bugs item #850110, was opened at 2003-11-27 08:54 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850110&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: Invalid Priority: 5 Submitted By: Nadav Horesh (nadavhoresh) Assigned to: Michael Hudson (mwh) Summary: Out of order commands excecution? Initial Comment: Consider the following: >>> import string >>> def test1(): join = string.join >>> def test2(): join = string.join string = string.split >>> test1() >>> test2() Traceback (most recent call last): File "", line 1, in -toplevel- test2() File "", line 2, in test2 join = string.join UnboundLocalError: local variable 'string' referenced before assignment >>> How the second statement in test2 generates an error in first one? Nadav. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-12-01 12:34 Message: Logged In: YES user_id=6656 Well, you reopened the bug, so you're obviously not happy. What do you want to see changed? The behaviour? No chance. Better documentation? Feel free to supply a patch (or just suggest wording and a location, others can do the latex). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-01 05:25 Message: Logged In: YES user_id=33168 If a variable is local in a function, it is local throughout the whole function. It doesn't become local at the first assignment, but from the beginning of the function. Does that help? ---------------------------------------------------------------------- Comment By: Nadav Horesh (nadavhoresh) Date: 2003-11-30 19:26 Message: Logged In: YES user_id=75473 I've looked at the FAQ and it is not seems to sesolve the issue: In test2 "string" becomes a local variable in the second line, while in the first line (join = string.join) "string" should point to the (global) string module. Nadav. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-11-27 12:09 Message: Logged In: YES user_id=6656 Well, that's just how it works. This must be documented somewhere... see if http://www.python.org/doc/faq/programming.html#what-are-the-rules-for-local-and-global-variables-in-python helps (and maybe the question before). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850110&group_id=5470 From noreply at sourceforge.net Mon Dec 1 07:37:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 07:37:52 2003 Subject: [ python-Bugs-848856 ] couple of new list.sort bugs Message-ID: Bugs item #848856, was opened at 2003-11-25 11:12 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848856&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: couple of new list.sort bugs Initial Comment: I really feel I should apologise for this one: [mwh@pc150 build-debug]$ cat t.py class SortKiller(object): def __init__(self, i): pass def __del__(self): del l[:] l = range(10) l.sort(key=SortKiller) [mwh@pc150 build-debug]$ ./python t.py Segmentation fault This can be fixed by moving the "restoring the objects of the list from the wrappers" code *before* the "put saved_ob_item back in the list" code. The second is less serious but probably more annoying to fix: [mwh@pc150 build-debug]$ cat u.py def k(x): return 1/x l = range(-2,2) try: l.sort(key=k) except ZeroDivisionError: pass print l [mwh@pc150 build-debug]$ ./python u.py [, , 0, 1] [6571 refs] ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-12-01 12:37 Message: Logged In: YES user_id=6656 I have a feeling that your fix for problem #2 has made problem #1 harder to fix... will have a look later, no time right now. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-29 01:56 Message: Logged In: YES user_id=80475 The second was easy to fix. The first is defying my attempts to fix it. You're welcome to take a crack at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848856&group_id=5470 From noreply at sourceforge.net Mon Dec 1 09:18:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 09:18:57 2003 Subject: [ python-Feature Requests-801847 ] Adding rsplit() to string and unicode objects. Message-ID: Feature Requests item #801847, was opened at 2003-09-06 19:52 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=801847&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: Accepted Priority: 4 Submitted By: Sean Reifschneider (jafo) >Assigned to: Alex Martelli (aleax) Summary: Adding rsplit() to string and unicode objects. Initial Comment: I'm attaching patches to the library and documentation for implementing rsplit() on string and unicode objects. This works like split(), but working from the right. ./python -c 'print u"foo, bar, baz".rsplit(None, 1)' [u'foo, bar,', u'baz'] This was supposed to be against the CVS code, but I've had a heck of a time getting it checked out -- my checkout has been hung for half an hour now. The code patch is against the 2.3 release, the docs patch is against the CVS. My checkout got to docs, but I didn't have the code to a point where I could build and test it. Sean ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-01 09:18 Message: Logged In: YES user_id=80475 Alex said he would take the patch from here. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-25 16:03 Message: Logged In: YES user_id=80475 Okay, I've got it from here! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-11-25 15:47 Message: Logged In: YES user_id=6380 OK, I'm in a generous mood today. I approve the idea. (I'm not going to review the code, that's up to Raymond and others). And Raymond can have a fillchar option to center() as well. I don't know what cook() was supposed to do, but if it's $ substitution, I recommend to keep that in a separate module for now. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-11-25 14:35 Message: Logged In: YES user_id=81797 If you are reading this and are interested in having this functionality in the standard Python library, please step forward and champion the effort. Obviously, I believe this is useful, or I wouldn't have spent the better part of a day building and testing it. However, I simply don't have the time to go through the politics of it. What needs to be done is a case needs to be further built for the presentation to the Python developement team. See Raymond's message below for a good list of what's needed there. Also see the thread on the python developers mailing list that I started in relation to this back in September. I will be happy to help out on this, but I just don't have the time to champion the adoption process. Thanks, Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-25 14:16 Message: Logged In: YES user_id=21627 It's very easy: find somebody with commit privileges to approve and commit the change. Failing to do so, write a library PEP, and ask for pronouncement. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-11-25 11:34 Message: Logged In: YES user_id=81797 Raymond, you've asked Guido about it on September 11, and he (apparently) explicitly stayed out of the discussion. I assumed that you had let him know you wanted his judgement on this and that his response was that he didn't want to be involved, leaving it up to the library "elite guard" instead. Did you actually copy Guido on your earlier request? Personally, I don't see the logic in "if we get only one string method". Python isn't for the Python core developers, it's for the users. If the users have several things that they want added, why the artificial limit on how many to accept? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-24 21:25 Message: Logged In: YES user_id=80475 Get Guido to approve the API change and I will be happy to complete the implementation, documentation, testing, etc. Advice: He will want *compelling* non-toy use cases and reasons why that a person wouldn't just implement it in pure python (saying that they aren't smart enough is not a reason). He is rarely ever persuaded by symmetry/completeness arguments along the lines of "we have an l-this so we have to have an r-that". If that were the case, tuples would have gotten index() and count() long ago. Language growth rate is one issue, the total number of string methods is another, and more importantly he seeks to minimize the number of small API compatabilities between versions which make it difficult to write code for Py2.4 that runs on Py2.2. Also, there are a number of strong competitors vying to be added as string methods. If we only get one new method, why is this one to be preferred over str.cook() for supporting Barry's simplified string substitutions Given only one new str API change, I would personally prefer to add an optional fillchar argument to str.center(). ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-11-24 17:45 Message: Logged In: YES user_id=139309 I'd have to say me too on this one, wake up please :) ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-29 00:38 Message: Logged In: YES user_id=81797 This seems to have generated nothing but positive comment from the folks on python-dev. Thoughts? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-22 13:17 Message: Logged In: YES user_id=80475 I'll review your patch when I get a chance. ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-09-22 08:10 Message: Logged In: YES user_id=99508 As a comment on the ease with which a programmer can get rsplit wrong, note that rhettinger's rsplit implementation is not correct: compare rsplit('foobarbaz', 'bar') with 'foobarbaz'.split('bar'). He forgot to reverse the separator if it's not None. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-11 18:55 Message: Logged In: YES user_id=80475 Guido, do you care to pronounce on this one? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-11 01:07 Message: Logged In: YES user_id=21627 There is PEP 2, which suggests to write a library PEP for proposal to extend the library. Now, this probably would be overkill for a single string method. However, I feel that there are already too many string methods, so I won't accept that patch. I'm not rejecting it, either, because I see that other maintainers might have a different opinion. In short, you should propose your change to python-dev, finding out what "a majority" of the maintainers thinks; you might also propose it on python-list, trying to collect reactions from users. It would then be good to summarize these discussions here (instead of carrying them out here). ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-10 15:40 Message: Logged In: YES user_id=81797 I realize that rsplit() can be implemented, because, well, I implemented it. The standard library is there to provide ready-to-use functionality so that users of python can concentrate on their program instead of concentrate on re-inventing the wheel. find() can be implemented with a short loop, split() can be implemented with find(), join() can be implemented with a short loop. Many things can be implemented with a little additional effort on the part of the user to develop or locate the code they're wanting. These little things can add up quickly and can have quite a dramatic impact on the programming experience in Python. Having to find or implement these functions will cause distraction from the code at hand, time lost while finding, implementing, testing, and maintaining the code in question. One of Python's strengths is a rich standard library. So, what are the guidelines for determining when it's rich enough? Why is it ok to suggest that users should get distracted from their code to go implement something else? Is there a policy that I'm not aware of that new functionality should be put in the cookbook instead of the standard library? Why is it being ignored that some programmers would find implementing rsplit() challenging? I'm not trying to be difficult here, I honestly can't understand the apparent change from having a rich library to a "batteries not included" stance. The response I got from #python when I mentioned having submitted the patch indicates to me that other experienced Python developers expect there to be an rsplit(). So, why is there so much resistance to adding something to the library? What are the guidelines for determining if something should be in the library? Sean ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-10 14:35 Message: Logged In: YES user_id=80475 I would classify this more as a technique than a fundamental string operation implemented by all stringlike objects (including UserString). Accordingly, I recommend that the patch be closed and a recipe posted in the ASPN cookbook - something along the lines of: >>> def rsplit(s, sep=None, maxsplit=-1): ... return [chunk[::-1] for chunk in s[::-1].split(sep, maxsplit)[::-1]] >>> rsplit(u"foo, bar, baz", None, 1) [u'foo, bar,', u'baz'] ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-10 14:15 Message: Logged In: YES user_id=81797 os.path.basename/os.path.dirname is an example of where you could use rsplit. One of the other #python folks said he had recently wanted rsplit for an application where he was getting the domain name and user part from a list of e-mail addresses, but found that some entries contained an "@" in the user part. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-10 12:08 Message: Logged In: YES user_id=21627 I questioned the usefulness because I could not think of a meaningful application. Now I see what a potential application could be, but I doubt its generality, because that approach would break if there could be two fields that have commas in them. I also disagree that symmetry can motivate usefulness: I also doubt that all of the r* functions are useful, but they cannot be removed for backwards compatibility. The fact that rsplit would fit together with the other r* functions indicates that adding rsplit would provide symmetry, not that it would provide usefulness. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-07 19:56 Message: Logged In: YES user_id=81797 Can you provide more details about why the usefulness of this function is in question? First I would like to tell you the story of it coming to be, then I will answer your incomplete question with a (probably) incomplete answer. I had a device which sent me comma-separated fields, but one of the fields in the middle could contain a comma. The answer that seemed obvious to me was to use split with a maxsplit to get the fields up to that field, and then a rsplit with a maxsplit on the remainder. When I mentioned on #python that I was implementing rsplit, 4 other fellow python users replied right away that they had been wanting it. To answer your question, it's useful because people using strings are used to having r*() functions like rfind and rstrip. The lack of rsplit is kind of glaring in this context. Really, though, it's useful because otherwise people have to implement -- often badly. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-07 14:49 Message: Logged In: YES user_id=21627 Why is this function useful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=801847&group_id=5470 From noreply at sourceforge.net Mon Dec 1 09:31:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 09:31:29 2003 Subject: [ python-Bugs-850110 ] Out of order commands excecution? Message-ID: Bugs item #850110, was opened at 2003-11-27 08:54 Message generated for change (Comment added) made by nadavhoresh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850110&group_id=5470 Category: Parser/Compiler Group: Python 2.3 >Status: Closed Resolution: Invalid Priority: 5 Submitted By: Nadav Horesh (nadavhoresh) Assigned to: Michael Hudson (mwh) Summary: Out of order commands excecution? Initial Comment: Consider the following: >>> import string >>> def test1(): join = string.join >>> def test2(): join = string.join string = string.split >>> test1() >>> test2() Traceback (most recent call last): File "", line 1, in -toplevel- test2() File "", line 2, in test2 join = string.join UnboundLocalError: local variable 'string' referenced before assignment >>> How the second statement in test2 generates an error in first one? Nadav. ---------------------------------------------------------------------- >Comment By: Nadav Horesh (nadavhoresh) Date: 2003-12-01 14:31 Message: Logged In: YES user_id=75473 I understand that this is just a documentation issue. I guess that probably the interpreter builds the variables table before executing the first line of code. But, I afraid that I am not familiar with the internal of python to raise such statements. Thank you very much for your help Nadav. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-12-01 12:34 Message: Logged In: YES user_id=6656 Well, you reopened the bug, so you're obviously not happy. What do you want to see changed? The behaviour? No chance. Better documentation? Feel free to supply a patch (or just suggest wording and a location, others can do the latex). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-01 05:25 Message: Logged In: YES user_id=33168 If a variable is local in a function, it is local throughout the whole function. It doesn't become local at the first assignment, but from the beginning of the function. Does that help? ---------------------------------------------------------------------- Comment By: Nadav Horesh (nadavhoresh) Date: 2003-11-30 19:26 Message: Logged In: YES user_id=75473 I've looked at the FAQ and it is not seems to sesolve the issue: In test2 "string" becomes a local variable in the second line, while in the first line (join = string.join) "string" should point to the (global) string module. Nadav. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-11-27 12:09 Message: Logged In: YES user_id=6656 Well, that's just how it works. This must be documented somewhere... see if http://www.python.org/doc/faq/programming.html#what-are-the-rules-for-local-and-global-variables-in-python helps (and maybe the question before). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850110&group_id=5470 From noreply at sourceforge.net Mon Dec 1 09:49:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 09:49:44 2003 Subject: [ python-Bugs-851449 ] New-style classes with __eq__ but not __hash__ are hashable Message-ID: Bugs item #851449, was opened at 2003-11-30 00:40 Message generated for change (Comment added) made by edloper You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851449&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Edward Loper (edloper) Assigned to: Nobody/Anonymous (nobody) Summary: New-style classes with __eq__ but not __hash__ are hashable Initial Comment: According to the current reference docs, "If [a class] defines __cmp__() or __eq__() but not __hash__(), its instances will not be usable as dictionary keys. [1] But this doesn't work quite like you'd think for new-style classes: Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> class A(object): ... def __cmp__(self, other): return -1 >>> print {A():1} {<__main__.A object at 0x71cf0>: 1} The problem is that object defines a default __hash__ method: >>> print A.__hash__ So the dictionary class thinks that the object is hashable. But given that we've overridden cmp, there's no reason to believe that __hash__ is still valid. The only workaround I've found is to manually add a __hash__ method that raises the appropriate exception: >>> class A(object): ... def __cmp__(self, other): return -1 ... def __hash__(self): ... raise TypeError, ('%s objects are unhashable' % ... self.__class__) But it seems like this should be fixed in Python itself. I can think of 2 reasonable ways to fix it: - change object.__hash__() to raise a TypeError if __cmp__ or __eq__ is overridden. - change hash() to raise a TypeError if given an object that overrides __cmp__ or __eq__ but not __hash__. So.. Is this a real bug, or am I missing something? And if so, what's the prefered place to fix it? (I'd be happy to try to put together a patch for it, if it is indeed broken.) -Edward [1] http://www.python.org/doc/current/ref/ customization.html ---------------------------------------------------------------------- >Comment By: Edward Loper (edloper) Date: 2003-12-01 09:49 Message: Logged In: YES user_id=195958 Can you point me to the debate? I searched the python & python-dev mailing lists, and only came up with statements that suggested that people think that it does have the documented behavior. E.g., "A new-style class would NOT become unhashable by implementing __eq__ w/o __hash__, although its INSTANCES would." Using "return NotImplemented" does *not* seem like the right thing to do: if I try to use such an object as a dictionary key, it gives the confusing error "TypeError: an integer is required," since dict expects hash() to return an int. If this behavior is indeed set in stone, then this should be changed to a documentation bug, and the originally referenced page <://www.python.org/doc/current/ref/customization.html> should be updated to describe the actual behavior for new- style classes. -Edward ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-01 05:52 Message: Logged In: YES user_id=80475 It has been a subject of debate but the behavior is already cast in stone. Anything inheriting from object is hashable by default. The preferred way to make things unhashable is: def __hash__(self) return NotImplemented ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851449&group_id=5470 From noreply at sourceforge.net Mon Dec 1 11:05:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 11:05:13 2003 Subject: [ python-Bugs-852150 ] Can't send Apple Events without WindowServer connection Message-ID: Bugs item #852150, was opened at 2003-12-01 11:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852150&group_id=5470 Category: Macintosh Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: Can't send Apple Events without WindowServer connection Initial Comment: [Bob Ippolito] I've read that apple events don't actually need a WindowServer connection, you have any idea why they do from Python? [Jack Jansen] Because of the library that Carbon.AE is linked against. There's a subset of the AE interface in another library (missing all the stuff having to do with events) that you can use in commandline apps. We would need a way to create two similar modules, or somehow do it dynamically. Both are a lot of work ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852150&group_id=5470 From noreply at sourceforge.net Mon Dec 1 12:03:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 12:05:25 2003 Subject: [ python-Bugs-851123 ] shutil.copy destroys hard links Message-ID: Bugs item #851123, was opened at 2003-11-29 07:36 Message generated for change (Comment added) made by greg_ball You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851123&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerald Schlueter (gls62) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copy destroys hard links Initial Comment: Hi, I am using python2.3 on a debian linux (unstable) kernel Version 2.4.20. shell: cd /tmp cp /etc/passwd a ln a b cp a b *** a and b are the same file *** python import shutil shutil.copy("a", "b") The file is destroyed and cut down to 0 Bytes! Thank you, Gerry (gls62) ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2003-12-01 12:03 Message: Logged In: YES user_id=11365 The problem is in function shutil.copyfile(). Unlike cp, it does not check whether the two filenames actually link to the same underlying file. If they do, the act of opening the dst file for writing destroys the src file. This is true for symbolic or hard links. cp notices the link and prints a message. A fix for this would be to replace the lines # check for same pathname; all platforms _src = os.path.normcase(os.path.abspath(src)) _dst = os.path.normcase(os.path.abspath(dst)) if _src == _dst: return with # check for same file if hasattr(os.path,'samefile'): # Macintosh, Unix. try: if os.path.samefile(src,dst): return except OSError: pass else: # check for same pathname; all other platforms _src = os.path.normcase(os.path.abspath(src)) _dst = os.path.normcase(os.path.abspath(dst)) if _src == _dst: return This should fix the bug under Unix (and Mac, I guess) and leave other platforms no worse than before (I guess most other platforms do not have hard or symbolic links anyway?) I have posted a patch at http://tane.cfa.harvard.edu/python/shutil.patch Gerry, could you try it out, then perhaps I can open a patch item. I've included some test code. However, it uses tempfile.mktemp which I see has now been deprecated, so it will need a fix for that. Also, I'm not sure that it properly cleans up in the event of a failure. Perhaps this should be fixed too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851123&group_id=5470 From noreply at sourceforge.net Mon Dec 1 12:33:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 12:34:13 2003 Subject: [ python-Bugs-850964 ] optparse: OptionParser.__init__'s "prog" argument ignored Message-ID: Bugs item #850964, was opened at 2003-11-28 16:48 Message generated for change (Comment added) made by yuurei You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850964&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Mueller (yuurei) Assigned to: Greg Ward (gward) Summary: optparse: OptionParser.__init__'s "prog" argument ignored Initial Comment: optparse uses sys.argv[0] for the program name even if you supply the prog argument to OptionParser.__init__ ie, if you have p = OptionParser(prog='NEW_NAME'), p.print_usage, p.print_help, p.error, etc. don't use NEW_NAME as %prog. This is with Python 2.3.2 ---------------------------------------------------------------------- >Comment By: Paul Mueller (yuurei) Date: 2003-12-01 10:33 Message: Logged In: YES user_id=908814 The patch works perfectly. Thank you. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-11-30 23:06 Message: Logged In: YES user_id=671362 I've submitted a patch. See : http://www.python.org/sf/851902 Please apply the patch and check if "prog" argument works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850964&group_id=5470 From noreply at sourceforge.net Mon Dec 1 12:38:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 12:38:31 2003 Subject: [ python-Bugs-848856 ] couple of new list.sort bugs Message-ID: Bugs item #848856, was opened at 2003-11-25 11:12 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848856&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: couple of new list.sort bugs Initial Comment: I really feel I should apologise for this one: [mwh@pc150 build-debug]$ cat t.py class SortKiller(object): def __init__(self, i): pass def __del__(self): del l[:] l = range(10) l.sort(key=SortKiller) [mwh@pc150 build-debug]$ ./python t.py Segmentation fault This can be fixed by moving the "restoring the objects of the list from the wrappers" code *before* the "put saved_ob_item back in the list" code. The second is less serious but probably more annoying to fix: [mwh@pc150 build-debug]$ cat u.py def k(x): return 1/x l = range(-2,2) try: l.sort(key=k) except ZeroDivisionError: pass print l [mwh@pc150 build-debug]$ ./python u.py [, , 0, 1] [6571 refs] ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-12-01 17:38 Message: Logged In: YES user_id=6656 Here's a much less devious test case: $ cat w.py def k(x): del l[:] return x l = range(10) l.sort(key=k) $ ./python w.py Segmentation fault i think doing the "hide ob_item" swizzle should be just about the first thing list_sort does and undoing it should be about the last. Patch soon (I hope). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-12-01 12:37 Message: Logged In: YES user_id=6656 I have a feeling that your fix for problem #2 has made problem #1 harder to fix... will have a look later, no time right now. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-29 01:56 Message: Logged In: YES user_id=80475 The second was easy to fix. The first is defying my attempts to fix it. You're welcome to take a crack at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848856&group_id=5470 From noreply at sourceforge.net Mon Dec 1 13:13:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 13:13:25 2003 Subject: [ python-Feature Requests-852222 ] builtin save() function available interactively only Message-ID: Feature Requests item #852222, was opened at 2003-12-01 19:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=852222&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: builtin save() function available interactively only Initial Comment: I think that for learning python, it would be nice to save the current namespace to a file using a builtin save() function (and corresponding load(). For beginning programmers, it would be nice to be able to tinker interactively with the shell, defining functions and maybe even classes, with which they can continue later on. save() is easily implemented with pickling locals(); load() is easily implemented with updating locals() while unpickling it. The functions would take a filename (string) as an argument. In Idle, they are in the menu. Like the _ variable, load() and save() are only present in the interactive shell (some global .pythonrc?). I think it would be a useful addition to Python 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=852222&group_id=5470 From noreply at sourceforge.net Mon Dec 1 13:36:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 13:37:34 2003 Subject: [ python-Bugs-848856 ] couple of new list.sort bugs Message-ID: Bugs item #848856, was opened at 2003-11-25 11:12 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848856&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Raymond Hettinger (rhettinger) Summary: couple of new list.sort bugs Initial Comment: I really feel I should apologise for this one: [mwh@pc150 build-debug]$ cat t.py class SortKiller(object): def __init__(self, i): pass def __del__(self): del l[:] l = range(10) l.sort(key=SortKiller) [mwh@pc150 build-debug]$ ./python t.py Segmentation fault This can be fixed by moving the "restoring the objects of the list from the wrappers" code *before* the "put saved_ob_item back in the list" code. The second is less serious but probably more annoying to fix: [mwh@pc150 build-debug]$ cat u.py def k(x): return 1/x l = range(-2,2) try: l.sort(key=k) except ZeroDivisionError: pass print l [mwh@pc150 build-debug]$ ./python u.py [, , 0, 1] [6571 refs] ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-12-01 18:36 Message: Logged In: YES user_id=6656 Boy is this stuff hard to get right! See what you think of the attached patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-12-01 17:38 Message: Logged In: YES user_id=6656 Here's a much less devious test case: $ cat w.py def k(x): del l[:] return x l = range(10) l.sort(key=k) $ ./python w.py Segmentation fault i think doing the "hide ob_item" swizzle should be just about the first thing list_sort does and undoing it should be about the last. Patch soon (I hope). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-12-01 12:37 Message: Logged In: YES user_id=6656 I have a feeling that your fix for problem #2 has made problem #1 harder to fix... will have a look later, no time right now. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-29 01:56 Message: Logged In: YES user_id=80475 The second was easy to fix. The first is defying my attempts to fix it. You're welcome to take a crack at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848856&group_id=5470 From noreply at sourceforge.net Mon Dec 1 15:01:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 15:01:50 2003 Subject: [ python-Bugs-852281 ] test_winreg failing, Win98SE Message-ID: Bugs item #852281, was opened at 2003-12-01 15:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852281&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Guido van Rossum (gvanrossum) Summary: test_winreg failing, Win98SE Initial Comment: Under current CVS, on Win98SE: C:\Code\python\PCbuild>python ../lib/test/test_winreg.p y Traceback (most recent call last): File "../lib/test/test_winreg.py", line 135, in ? TestAll(HKEY_CURRENT_USER) File "../lib/test/test_winreg.py", line 130, in TestAll WriteTestData(root_key) File "../lib/test/test_winreg.py", line 37, in WriteTestData SetValueEx(sub_key, value_name, 0, value_type, value_data) WindowsError: [Errno 87] The parameter is incorrect C:\Code\python\PCbuild> That's all I know now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852281&group_id=5470 From noreply at sourceforge.net Mon Dec 1 15:15:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 15:15:10 2003 Subject: [ python-Bugs-852281 ] test_winreg failing, Win98SE Message-ID: Bugs item #852281, was opened at 2003-12-01 15:01 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852281&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Guido van Rossum (gvanrossum) Summary: test_winreg failing, Win98SE Initial Comment: Under current CVS, on Win98SE: C:\Code\python\PCbuild>python ../lib/test/test_winreg.p y Traceback (most recent call last): File "../lib/test/test_winreg.py", line 135, in ? TestAll(HKEY_CURRENT_USER) File "../lib/test/test_winreg.py", line 130, in TestAll WriteTestData(root_key) File "../lib/test/test_winreg.py", line 37, in WriteTestData SetValueEx(sub_key, value_name, 0, value_type, value_data) WindowsError: [Errno 87] The parameter is incorrect C:\Code\python\PCbuild> That's all I know now. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-01 15:14 Message: Logged In: YES user_id=6380 I bet the Big String and/or Big Binary test values that I added to the test_data table are too long for Win98. I can only test this on Win98. Can you experiment and find out what the largest value is that works on Win98? (The alternative would be to write code that somehow tries to *detect* the longest string that works, using bisection. I don't know if these limits are documented somewhere.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852281&group_id=5470 From noreply at sourceforge.net Mon Dec 1 15:28:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 15:28:43 2003 Subject: [ python-Bugs-852281 ] test_winreg failing, Win98SE Message-ID: Bugs item #852281, was opened at 2003-12-01 15:01 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852281&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Guido van Rossum (gvanrossum) Summary: test_winreg failing, Win98SE Initial Comment: Under current CVS, on Win98SE: C:\Code\python\PCbuild>python ../lib/test/test_winreg.p y Traceback (most recent call last): File "../lib/test/test_winreg.py", line 135, in ? TestAll(HKEY_CURRENT_USER) File "../lib/test/test_winreg.py", line 130, in TestAll WriteTestData(root_key) File "../lib/test/test_winreg.py", line 37, in WriteTestData SetValueEx(sub_key, value_name, 0, value_type, value_data) WindowsError: [Errno 87] The parameter is incorrect C:\Code\python\PCbuild> That's all I know now. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-12-01 15:28 Message: Logged In: YES user_id=31435 Yes, when I reduced the size of Big String to 12, it stopped failing there and failed on Big Binary instead. The docs don't promise that anything larger than 2048 will work ... "x"*(2**14-1) works, "x"*2**14 does not, for Big String. "x"*2**14 works, "x"*(2**14+1) does not, for Big Binary. So 2**14 bytes is the max on my Win98SE, when counting the trailing zero byte in REG_SZ. The limits are not documented (apart from the docs saying you shouldn't use any value exceeding 2**11 bytes). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-01 15:14 Message: Logged In: YES user_id=6380 I bet the Big String and/or Big Binary test values that I added to the test_data table are too long for Win98. I can only test this on Win98. Can you experiment and find out what the largest value is that works on Win98? (The alternative would be to write code that somehow tries to *detect* the longest string that works, using bisection. I don't know if these limits are documented somewhere.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852281&group_id=5470 From noreply at sourceforge.net Mon Dec 1 16:01:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 16:01:33 2003 Subject: [ python-Bugs-852314 ] tkFileDialog.askdirectory returns path objects Message-ID: Bugs item #852314, was opened at 2003-12-01 22:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852314&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. L?wis (loewis) Assigned to: Martin v. L?wis (loewis) Summary: tkFileDialog.askdirectory returns path objects Initial Comment: In askdirectory, conversion from path objects to basestrings is missing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852314&group_id=5470 From noreply at sourceforge.net Mon Dec 1 16:04:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 16:05:31 2003 Subject: [ python-Bugs-852314 ] tkFileDialog.askdirectory returns path objects Message-ID: Bugs item #852314, was opened at 2003-12-01 22:01 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852314&group_id=5470 Category: Tkinter Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martin v. L?wis (loewis) Assigned to: Martin v. L?wis (loewis) Summary: tkFileDialog.askdirectory returns path objects Initial Comment: In askdirectory, conversion from path objects to basestrings is missing. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-12-01 22:04 Message: Logged In: YES user_id=21627 Fixed in tkFileDialog.py 1.11.8.1 1.12 NEWS 1.831.4.80 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852314&group_id=5470 From noreply at sourceforge.net Mon Dec 1 16:08:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 16:09:15 2003 Subject: [ python-Bugs-843999 ] tkFileDialog.Open is broken Message-ID: Bugs item #843999, was opened at 2003-11-17 22:29 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=843999&group_id=5470 Category: Tkinter Group: Python 2.3 >Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Martin v. L?wis (loewis) Summary: tkFileDialog.Open is broken Initial Comment: tkFileDialog.Open is broken, apparently due to the new object interface. Try the following: >>> import Tkinter >>> import tkFileDialog >>> root = Tkinter.Tk() >>> tkFileDialog.askopenfilename() Traceback (most recent call last): File "", line 1, in ? File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib-tk/tkFileDialog.py", line 119, in askopenfilename return Open(**options).show() File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib-tk/tkCommonDialog.py", line 54, in show s = self._fixresult(w, s) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib-tk/tkFileDialog.py", line 89, in _fixresult if not widget.tk.wantobjects() and "multiple" in self.options: TypeError: wantobjects() takes exactly 1 argument (0 given) >>> Looking at the code, tkFileDialog.Open _fixresult is calling widget.tk.wantobjects() and apparently that function always wants an argument (though one would not necessarily think so from the function name, so the bug is not surprising). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-12-01 22:08 Message: Logged In: YES user_id=21627 This has been fixed in _tkinter.c 1.161, so you are probably using some old version. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-18 05:42 Message: Logged In: YES user_id=33168 What version of Python are you using? I just looked at the code for 2.3.2 and tested it. 2.3.2 works fine. Perhaps this bug has already been fixed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=843999&group_id=5470 From noreply at sourceforge.net Mon Dec 1 16:25:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 16:26:42 2003 Subject: [ python-Bugs-850997 ] mbcs encoding ignores errors Message-ID: Bugs item #850997, was opened at 2003-11-29 02:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850997&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: mbcs encoding ignores errors Initial Comment: The following snippet: >>> u'@test-\u5171'.encode("mbcs", "strict") '@test-?' Should raise a UnicodeError. The errors param is completely ignored, and the function always works as though errors='replace'. Attaching a test case, and the start of a patch. The patch has a number of issues: * I'm not sure what errors are considered 'mandatory'. I have handled 'strict', 'ignore' and 'replace' - however, 'ignore' and 'replace' currently are exactly the same (ie, replace) * The Windows functions don't tell us exactly what character failed in the conversion. Thus, the exception I raise implies the first character is the one that failed. For the same reason, I have made no attempt to support error callbacks. Comments/guidance appreciated. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-12-01 22:25 Message: Logged In: YES user_id=21627 The conventional semantics of "ignore" would be "remove the failing characters from the output". This would be difficult to implement if the Microsoft API provides no detailed error indication. You could try to get more detailed error indication by re-encoding the resulting string with a NULL buffer, counting the number of characters that have successfully been encoded, atleast in the .decode case. In the .encode case, you could try using \0 as the default char. To my knowledge, no ACP ever uses \0 in a multi-byte string. What is the meaning of the WC_DEFAULTCHAR flag, in WideCharToMultiByte, and why are you not using it? I'm somewhat concerned with backwards compatibility, since the mbcs codec has never returned errors. So this should be applied to 2.4 only, and listed in whatsnew.tex. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-29 16:18 Message: Logged In: YES user_id=11105 No idea why this was assigned to me - unicode is certainly not one of my strengths. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-11-29 02:31 Message: Logged In: YES user_id=14198 Attaching a patch. This patch also attempts to handle Encode, but I haven't worked out how to exercise this code-path - ie, what mbcs encoded string can I pass that can not be converted to unicode? As I mentioned, patch has a few issues ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850997&group_id=5470 From noreply at sourceforge.net Mon Dec 1 16:39:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 16:39:59 2003 Subject: [ python-Bugs-846133 ] os.chmod/os.utime/shutil do not work with unicode filenames Message-ID: Bugs item #846133, was opened at 2003-11-20 22:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846133&group_id=5470 Category: Unicode Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Eric Meyer (meyeet) Assigned to: Martin v. L?wis (loewis) Summary: os.chmod/os.utime/shutil do not work with unicode filenames Initial Comment: I have a filename that contains Kanji characters and I'm trying change the permissions on the file. I am running Python 2.3.1 on Windows 2000. Also I have the japanese language pack installed so that I can view the kanji characters in Windows explorer. >>> part u'\u5171\u6709\u3055\u308c\u308b.txt' >>> os.chmod(part, 0777) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument: '?????.txt' >>> I attached the above named file for you to test against. Thanks. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-12-01 22:39 Message: Logged In: YES user_id=21627 The patches to posixmodule.c are fine for both 2.3 and 2.4. Can you apply them before 2.3.3 is frozen? The patches to the test suite are fine for 2.4 only, and they probably need to be relaxed. For example, on OSX, there simply is no file name that fails to work for the normal file system API: the file system encoding is UTF-8, so it supports all file names. You should consider changing test_pep277.py instead. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-11-29 02:32 Message: Logged In: YES user_id=14198 I created www.python.org/sf/850997 about the MBCS encoding issue. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-11-28 10:58 Message: Logged In: YES user_id=14198 I opened http://www.python.org/sf/846133 regarding os.utime, which I found via the "shutil" module, via SpamBayes, also on a Japanese system (see that bug for details), but then I saw this and decided to tackle them both. I rolled my fix for that in with a fix for chmod. I also hacked the test suite radically: * Creation of a test_support.TESTFN_UNICODE_UNENCODEABLE variable, which is a Unicode string that can *not* be encoded using the file system encoding. This will cause functions with 'encoding' support but without Unicode support (such as utime/chmod) to fail. * Made functions of all the test cases, so more combinations of unicode/encoded can be tested. Many are redundant, but that is OK. * Added shutil tests of the filenames * While I was there, converted to a unittest test. The new test case blows up with a couple of errors before the posixmodule patch is applied, and passes after. Note that shutil.move/copy etc can not handle being passed one string and one unicode arg, and therefore this combination is skipped. I'd like any opinions on whether this is a bug in shutil or not. Also note that the new comment in test_support.py regarding a potential bug in the 'mbcs' encoding - it appears as if it always works as though errors=ignore. Comments/reviews? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-24 23:21 Message: Logged In: YES user_id=21627 If you look at the source of os.chmod, it is not at all surprising that it does not work for characters outside the file system encoding: it is simply not implemented. Patches are welcome. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-11-22 01:51 Message: Logged In: YES user_id=671362 Hi, Eric. My previous post was maybe wrong. This is the problem of os.chmod. I've confirmed two kinds of exceptions are raised when using os.chmod for unicode filenames. The first one is [Errno 22] Invalid argument. You can read/write a file but cannot use os.chmod. The second one is [Errno 2] No such file or directory. Although there exists a file, Python complains "No such file or directory" test.test_codecs has a bunch of international unicode characters, so I borrowed them for testing. >>> import os >>> from test.test_codecs import punycode_testcases >>> def unicode_test(name): try: f = file(name, 'w') f.close() except IOError, e: print e return try: os.chmod(name, 0777) except OSError, e: print e >>> for i, (uni, puny) in enumerate (punycode_testcases): print i unicode_test(uni) I ran this script on Windows 2000(Japanese edition) using Python 2.3 and got "[Errno 22]" for 0,1,2,3,4,5,7,10 and "[Errno 2]" for 9. ---------------------------------------------------------------------- Comment By: Eric Meyer (meyeet) Date: 2003-11-21 17:18 Message: Logged In: YES user_id=913976 George, I tried the following but I had to specify one of the japanese codecs during the unicode() call. What is your default encoding set to? Below are my results. >>> import os >>> os.listdir('.') [] >>> u1 = unicode('\x82\xa0', 'cp932') >>> u2 = u'\x82\xa0' >>> u1, u2 (u'\u3042', u'\x82\xa0') >>> print >> file(u1, 'w'), "hello world" >>> os.listdir('.') ['?'] >>> os.chmod(u1, 0777) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument: '?' ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-11-21 01:07 Message: Logged In: YES user_id=671362 I'm running Python in almost the same environment. I guess this results from the different bihavior of u'' and unicode(''). If you convert a multi-byte character to a unicode character, u'' and unicode('') don't return the same string. unicode'' works as intended but u'' doesn't. This is probably caused by the bug of Japanese codecs package. Eric, please try the session below and tell me what happens. NOTE: Japanese codecs needs to be installed to test the code below. Otherwise, UnicodeDecodeError will be raised. --- >>> import os >>> os.listdir('.') [] >>> lst = ['\x82', '\xa0'] # japanese character >>> u1 = unicode('\x82\xa0') >>> u2 = u'\x82\xa0' >>> u1 == u2 False >>> u1, u2 (u'\u3042', u'\x82\xa0') # u2 is odd >>> print >> file(u1, 'w'), "hello world" >>> os.listdir('.') ['あ'] >>> os.chmod(u1, 0777) >>> os.chmod(u2, 0777) Traceback (most recent call last): File "", line 1, in -toplevel- os.chmod(u2, 0777) OSError: [Errno 22] Invalid argument: '??' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846133&group_id=5470 From noreply at sourceforge.net Mon Dec 1 16:41:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 16:41:44 2003 Subject: [ python-Bugs-846133 ] os.chmod/os.utime/shutil do not work with unicode filenames Message-ID: Bugs item #846133, was opened at 2003-11-20 22:27 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846133&group_id=5470 Category: Unicode Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Eric Meyer (meyeet) >Assigned to: Mark Hammond (mhammond) Summary: os.chmod/os.utime/shutil do not work with unicode filenames Initial Comment: I have a filename that contains Kanji characters and I'm trying change the permissions on the file. I am running Python 2.3.1 on Windows 2000. Also I have the japanese language pack installed so that I can view the kanji characters in Windows explorer. >>> part u'\u5171\u6709\u3055\u308c\u308b.txt' >>> os.chmod(part, 0777) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument: '?????.txt' >>> I attached the above named file for you to test against. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-12-01 22:39 Message: Logged In: YES user_id=21627 The patches to posixmodule.c are fine for both 2.3 and 2.4. Can you apply them before 2.3.3 is frozen? The patches to the test suite are fine for 2.4 only, and they probably need to be relaxed. For example, on OSX, there simply is no file name that fails to work for the normal file system API: the file system encoding is UTF-8, so it supports all file names. You should consider changing test_pep277.py instead. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-11-29 02:32 Message: Logged In: YES user_id=14198 I created www.python.org/sf/850997 about the MBCS encoding issue. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-11-28 10:58 Message: Logged In: YES user_id=14198 I opened http://www.python.org/sf/846133 regarding os.utime, which I found via the "shutil" module, via SpamBayes, also on a Japanese system (see that bug for details), but then I saw this and decided to tackle them both. I rolled my fix for that in with a fix for chmod. I also hacked the test suite radically: * Creation of a test_support.TESTFN_UNICODE_UNENCODEABLE variable, which is a Unicode string that can *not* be encoded using the file system encoding. This will cause functions with 'encoding' support but without Unicode support (such as utime/chmod) to fail. * Made functions of all the test cases, so more combinations of unicode/encoded can be tested. Many are redundant, but that is OK. * Added shutil tests of the filenames * While I was there, converted to a unittest test. The new test case blows up with a couple of errors before the posixmodule patch is applied, and passes after. Note that shutil.move/copy etc can not handle being passed one string and one unicode arg, and therefore this combination is skipped. I'd like any opinions on whether this is a bug in shutil or not. Also note that the new comment in test_support.py regarding a potential bug in the 'mbcs' encoding - it appears as if it always works as though errors=ignore. Comments/reviews? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-24 23:21 Message: Logged In: YES user_id=21627 If you look at the source of os.chmod, it is not at all surprising that it does not work for characters outside the file system encoding: it is simply not implemented. Patches are welcome. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-11-22 01:51 Message: Logged In: YES user_id=671362 Hi, Eric. My previous post was maybe wrong. This is the problem of os.chmod. I've confirmed two kinds of exceptions are raised when using os.chmod for unicode filenames. The first one is [Errno 22] Invalid argument. You can read/write a file but cannot use os.chmod. The second one is [Errno 2] No such file or directory. Although there exists a file, Python complains "No such file or directory" test.test_codecs has a bunch of international unicode characters, so I borrowed them for testing. >>> import os >>> from test.test_codecs import punycode_testcases >>> def unicode_test(name): try: f = file(name, 'w') f.close() except IOError, e: print e return try: os.chmod(name, 0777) except OSError, e: print e >>> for i, (uni, puny) in enumerate (punycode_testcases): print i unicode_test(uni) I ran this script on Windows 2000(Japanese edition) using Python 2.3 and got "[Errno 22]" for 0,1,2,3,4,5,7,10 and "[Errno 2]" for 9. ---------------------------------------------------------------------- Comment By: Eric Meyer (meyeet) Date: 2003-11-21 17:18 Message: Logged In: YES user_id=913976 George, I tried the following but I had to specify one of the japanese codecs during the unicode() call. What is your default encoding set to? Below are my results. >>> import os >>> os.listdir('.') [] >>> u1 = unicode('\x82\xa0', 'cp932') >>> u2 = u'\x82\xa0' >>> u1, u2 (u'\u3042', u'\x82\xa0') >>> print >> file(u1, 'w'), "hello world" >>> os.listdir('.') ['?'] >>> os.chmod(u1, 0777) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument: '?' ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-11-21 01:07 Message: Logged In: YES user_id=671362 I'm running Python in almost the same environment. I guess this results from the different bihavior of u'' and unicode(''). If you convert a multi-byte character to a unicode character, u'' and unicode('') don't return the same string. unicode'' works as intended but u'' doesn't. This is probably caused by the bug of Japanese codecs package. Eric, please try the session below and tell me what happens. NOTE: Japanese codecs needs to be installed to test the code below. Otherwise, UnicodeDecodeError will be raised. --- >>> import os >>> os.listdir('.') [] >>> lst = ['\x82', '\xa0'] # japanese character >>> u1 = unicode('\x82\xa0') >>> u2 = u'\x82\xa0' >>> u1 == u2 False >>> u1, u2 (u'\u3042', u'\x82\xa0') # u2 is odd >>> print >> file(u1, 'w'), "hello world" >>> os.listdir('.') ['あ'] >>> os.chmod(u1, 0777) >>> os.chmod(u2, 0777) Traceback (most recent call last): File "", line 1, in -toplevel- os.chmod(u2, 0777) OSError: [Errno 22] Invalid argument: '??' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846133&group_id=5470 From noreply at sourceforge.net Mon Dec 1 16:44:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 16:44:05 2003 Subject: [ python-Bugs-851020 ] building on Fedora Core 1 Message-ID: Bugs item #851020, was opened at 2003-11-29 04:17 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851020&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael P. Soulier (msoulier) Assigned to: Nobody/Anonymous (nobody) Summary: building on Fedora Core 1 Initial Comment: I'm trying to build Python 2.3.2 on Fedora Core 1. The configure runs without errors, but I then get an odd error about pyconfig.h during the build. gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/dictobject.o Objects/dictobject.c In file included from Objects/dictobject.c:10: Include/Python.h:8:22: pyconfig.h: No such file or directory Include/Python.h:21:2: #error "limits.h is required by std C -- why isn't HAVE_LIMITS_H defined?" In file included from Include/Python.h:48, from Objects/dictobject.c:10: Include/pyport.h:4:48: pyconfig.h: No such file or directory Include/pyport.h:536:2: #error "could not set LONG_MAX in pyport.h" Objects/dictobject.c: In function `dictresize': Objects/dictobject.c:477: warning: implicit declaration of function `free' make: *** [Objects/dictobject.o] Error 1 [msoulier@tigger Python-2.3.2]$ find . -name pyconfig.h ./Mac/Include/pyconfig.h ./PC/pyconfig.h ./PC/os2emx/pyconfig.h ./PC/os2vacpp/pyconfig.h ./RISCOS/pyconfig.h ./pyconfig.h I'm not sure what the issue is here. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-12-01 22:43 Message: Logged In: YES user_id=21627 Can you pleas invoke the gcc command line manually, passing -v to gcc? This looks like a bug in the gcc installation: If -I. is given, it should find ./pyconfig.h. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851020&group_id=5470 From noreply at sourceforge.net Mon Dec 1 17:05:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 17:05:58 2003 Subject: [ python-Bugs-852347 ] add support for cjkcodecs to Python email Message-ID: Bugs item #852347, was opened at 2003-12-01 15:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852347&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: add support for cjkcodecs to Python email Initial Comment: As discussed last week on the email-sig list, the attached patch adds support for the CJKCodecs package as an alternative to the {Chinese,Japanese,Korean}Codecs packages. CJKCodecs 1.0.2 and above should work with this patch. This is advantageous because the Chinese and KoreanCodecs packages are no longer supported,maintained or available for download. This patch does not break compatibility with {Chinese,Japanese,Korean}Codecs, so they can still be used if desired. Lastly, this patch fixes a small typo that broke GB2312. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852347&group_id=5470 From noreply at sourceforge.net Mon Dec 1 17:08:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 17:08:16 2003 Subject: [ python-Bugs-852347 ] add support for cjkcodecs to Python email Message-ID: Bugs item #852347, was opened at 2003-12-01 15:05 Message generated for change (Settings changed) made by jasonrm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852347&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: add support for cjkcodecs to Python email Initial Comment: As discussed last week on the email-sig list, the attached patch adds support for the CJKCodecs package as an alternative to the {Chinese,Japanese,Korean}Codecs packages. CJKCodecs 1.0.2 and above should work with this patch. This is advantageous because the Chinese and KoreanCodecs packages are no longer supported,maintained or available for download. This patch does not break compatibility with {Chinese,Japanese,Korean}Codecs, so they can still be used if desired. Lastly, this patch fixes a small typo that broke GB2312. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852347&group_id=5470 From noreply at sourceforge.net Mon Dec 1 19:23:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 19:24:16 2003 Subject: [ python-Bugs-852281 ] test_winreg failing, Win98SE Message-ID: Bugs item #852281, was opened at 2003-12-02 07:01 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852281&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Guido van Rossum (gvanrossum) Summary: test_winreg failing, Win98SE Initial Comment: Under current CVS, on Win98SE: C:\Code\python\PCbuild>python ../lib/test/test_winreg.p y Traceback (most recent call last): File "../lib/test/test_winreg.py", line 135, in ? TestAll(HKEY_CURRENT_USER) File "../lib/test/test_winreg.py", line 130, in TestAll WriteTestData(root_key) File "../lib/test/test_winreg.py", line 37, in WriteTestData SetValueEx(sub_key, value_name, 0, value_type, value_data) WindowsError: [Errno 87] The parameter is incorrect C:\Code\python\PCbuild> That's all I know now. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-12-02 11:23 Message: Logged In: YES user_id=29957 Argh. Is this busted on the 2.3 branch as well? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-12-02 07:28 Message: Logged In: YES user_id=31435 Yes, when I reduced the size of Big String to 12, it stopped failing there and failed on Big Binary instead. The docs don't promise that anything larger than 2048 will work ... "x"*(2**14-1) works, "x"*2**14 does not, for Big String. "x"*2**14 works, "x"*(2**14+1) does not, for Big Binary. So 2**14 bytes is the max on my Win98SE, when counting the trailing zero byte in REG_SZ. The limits are not documented (apart from the docs saying you shouldn't use any value exceeding 2**11 bytes). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-02 07:14 Message: Logged In: YES user_id=6380 I bet the Big String and/or Big Binary test values that I added to the test_data table are too long for Win98. I can only test this on Win98. Can you experiment and find out what the largest value is that works on Win98? (The alternative would be to write code that somehow tries to *detect* the longest string that works, using bisection. I don't know if these limits are documented somewhere.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852281&group_id=5470 From noreply at sourceforge.net Mon Dec 1 19:34:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 19:34:36 2003 Subject: [ python-Bugs-852281 ] test_winreg failing, Win98SE Message-ID: Bugs item #852281, was opened at 2003-12-01 15:01 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852281&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Guido van Rossum (gvanrossum) Summary: test_winreg failing, Win98SE Initial Comment: Under current CVS, on Win98SE: C:\Code\python\PCbuild>python ../lib/test/test_winreg.p y Traceback (most recent call last): File "../lib/test/test_winreg.py", line 135, in ? TestAll(HKEY_CURRENT_USER) File "../lib/test/test_winreg.py", line 130, in TestAll WriteTestData(root_key) File "../lib/test/test_winreg.py", line 37, in WriteTestData SetValueEx(sub_key, value_name, 0, value_type, value_data) WindowsError: [Errno 87] The parameter is incorrect C:\Code\python\PCbuild> That's all I know now. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-12-01 19:34 Message: Logged In: YES user_id=31435 Anthony, yes, it is. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-12-01 19:23 Message: Logged In: YES user_id=29957 Argh. Is this busted on the 2.3 branch as well? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-12-01 15:28 Message: Logged In: YES user_id=31435 Yes, when I reduced the size of Big String to 12, it stopped failing there and failed on Big Binary instead. The docs don't promise that anything larger than 2048 will work ... "x"*(2**14-1) works, "x"*2**14 does not, for Big String. "x"*2**14 works, "x"*(2**14+1) does not, for Big Binary. So 2**14 bytes is the max on my Win98SE, when counting the trailing zero byte in REG_SZ. The limits are not documented (apart from the docs saying you shouldn't use any value exceeding 2**11 bytes). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-01 15:14 Message: Logged In: YES user_id=6380 I bet the Big String and/or Big Binary test values that I added to the test_data table are too long for Win98. I can only test this on Win98. Can you experiment and find out what the largest value is that works on Win98? (The alternative would be to write code that somehow tries to *detect* the longest string that works, using bisection. I don't know if these limits are documented somewhere.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852281&group_id=5470 From noreply at sourceforge.net Tue Dec 2 01:52:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 2 01:52:15 2003 Subject: [ python-Bugs-848856 ] couple of new list.sort bugs Message-ID: Bugs item #848856, was opened at 2003-11-25 06:12 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848856&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Raymond Hettinger (rhettinger) Summary: couple of new list.sort bugs Initial Comment: I really feel I should apologise for this one: [mwh@pc150 build-debug]$ cat t.py class SortKiller(object): def __init__(self, i): pass def __del__(self): del l[:] l = range(10) l.sort(key=SortKiller) [mwh@pc150 build-debug]$ ./python t.py Segmentation fault This can be fixed by moving the "restoring the objects of the list from the wrappers" code *before* the "put saved_ob_item back in the list" code. The second is less serious but probably more annoying to fix: [mwh@pc150 build-debug]$ cat u.py def k(x): return 1/x l = range(-2,2) try: l.sort(key=k) except ZeroDivisionError: pass print l [mwh@pc150 build-debug]$ ./python u.py [, , 0, 1] [6571 refs] ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-02 01:52 Message: Logged In: YES user_id=80475 On the code path leading to a dsu_fail, does PyMem_FREE() ever get called? Would there be some added protection value to INCREFing self at the beginning and DECREFing it at the end? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-12-01 13:36 Message: Logged In: YES user_id=6656 Boy is this stuff hard to get right! See what you think of the attached patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-12-01 12:38 Message: Logged In: YES user_id=6656 Here's a much less devious test case: $ cat w.py def k(x): del l[:] return x l = range(10) l.sort(key=k) $ ./python w.py Segmentation fault i think doing the "hide ob_item" swizzle should be just about the first thing list_sort does and undoing it should be about the last. Patch soon (I hope). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-12-01 07:37 Message: Logged In: YES user_id=6656 I have a feeling that your fix for problem #2 has made problem #1 harder to fix... will have a look later, no time right now. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-28 20:56 Message: Logged In: YES user_id=80475 The second was easy to fix. The first is defying my attempts to fix it. You're welcome to take a crack at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848856&group_id=5470 From noreply at sourceforge.net Tue Dec 2 02:17:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 2 02:17:44 2003 Subject: [ python-Bugs-851449 ] New-style classes with __eq__ but not __hash__ are hashable Message-ID: Bugs item #851449, was opened at 2003-11-30 00:40 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851449&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Edward Loper (edloper) Assigned to: Nobody/Anonymous (nobody) Summary: New-style classes with __eq__ but not __hash__ are hashable Initial Comment: According to the current reference docs, "If [a class] defines __cmp__() or __eq__() but not __hash__(), its instances will not be usable as dictionary keys. [1] But this doesn't work quite like you'd think for new-style classes: Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> class A(object): ... def __cmp__(self, other): return -1 >>> print {A():1} {<__main__.A object at 0x71cf0>: 1} The problem is that object defines a default __hash__ method: >>> print A.__hash__ So the dictionary class thinks that the object is hashable. But given that we've overridden cmp, there's no reason to believe that __hash__ is still valid. The only workaround I've found is to manually add a __hash__ method that raises the appropriate exception: >>> class A(object): ... def __cmp__(self, other): return -1 ... def __hash__(self): ... raise TypeError, ('%s objects are unhashable' % ... self.__class__) But it seems like this should be fixed in Python itself. I can think of 2 reasonable ways to fix it: - change object.__hash__() to raise a TypeError if __cmp__ or __eq__ is overridden. - change hash() to raise a TypeError if given an object that overrides __cmp__ or __eq__ but not __hash__. So.. Is this a real bug, or am I missing something? And if so, what's the prefered place to fix it? (I'd be happy to try to put together a patch for it, if it is indeed broken.) -Edward [1] http://www.python.org/doc/current/ref/ customization.html ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-02 02:17 Message: Logged In: YES user_id=80475 I should have been clearer. The bug has been discussed several times before (SF 475877, 660098, and 730087) and while unresolved leaves us in a workable position of explicitly defining a nohash function. I rechecked my notes, the right way to implement such a function is to raise a TypeError. I misrememberes returning NotImplemented which is the technique for overcoming certain issues related to __cmp__. ---------------------------------------------------------------------- Comment By: Edward Loper (edloper) Date: 2003-12-01 09:49 Message: Logged In: YES user_id=195958 Can you point me to the debate? I searched the python & python-dev mailing lists, and only came up with statements that suggested that people think that it does have the documented behavior. E.g., "A new-style class would NOT become unhashable by implementing __eq__ w/o __hash__, although its INSTANCES would." Using "return NotImplemented" does *not* seem like the right thing to do: if I try to use such an object as a dictionary key, it gives the confusing error "TypeError: an integer is required," since dict expects hash() to return an int. If this behavior is indeed set in stone, then this should be changed to a documentation bug, and the originally referenced page <://www.python.org/doc/current/ref/customization.html> should be updated to describe the actual behavior for new- style classes. -Edward ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-01 05:52 Message: Logged In: YES user_id=80475 It has been a subject of debate but the behavior is already cast in stone. Anything inheriting from object is hashable by default. The preferred way to make things unhashable is: def __hash__(self) return NotImplemented ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851449&group_id=5470 From noreply at sourceforge.net Tue Dec 2 06:01:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 2 06:01:49 2003 Subject: [ python-Bugs-852532 ] ^$ won't split on empty line Message-ID: Bugs item #852532, was opened at 2003-12-02 06:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852532&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jan Burgy (jburgy) Assigned to: Fredrik Lundh (effbot) Summary: ^$ won't split on empty line Initial Comment: Python 2.3.2 (#49, Oct 2 2003, 20:02:00) [MSC v.1200 32 bit (Intel)] on win32 >>> import re >>> re.compile('^$', re.MULTILINE).split('foo\n\nbar') ['foo\n\nbar'] I expect ['foo\n', '\nbar'], since, according to the documentation $ "in MULTILINE mode also matches before a newline". Thanks, Jan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852532&group_id=5470 From noreply at sourceforge.net Tue Dec 2 07:13:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 2 07:13:44 2003 Subject: [ python-Bugs-848856 ] couple of new list.sort bugs Message-ID: Bugs item #848856, was opened at 2003-11-25 11:12 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848856&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Raymond Hettinger (rhettinger) Summary: couple of new list.sort bugs Initial Comment: I really feel I should apologise for this one: [mwh@pc150 build-debug]$ cat t.py class SortKiller(object): def __init__(self, i): pass def __del__(self): del l[:] l = range(10) l.sort(key=SortKiller) [mwh@pc150 build-debug]$ ./python t.py Segmentation fault This can be fixed by moving the "restoring the objects of the list from the wrappers" code *before* the "put saved_ob_item back in the list" code. The second is less serious but probably more annoying to fix: [mwh@pc150 build-debug]$ cat u.py def k(x): return 1/x l = range(-2,2) try: l.sort(key=k) except ZeroDivisionError: pass print l [mwh@pc150 build-debug]$ ./python u.py [, , 0, 1] [6571 refs] ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-12-02 12:13 Message: Logged In: YES user_id=6656 > On the code path leading to a dsu_fail, does > PyMem_FREE() ever get called? Good catch. New patch attached. > Would there be some added protection value to INCREFing self > at the beginning and DECREFing it at the end? Um, I don't think so, as the calling machinery holds a reference to self (and all the other arguments) during the call. Or did you mean something else? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-02 06:52 Message: Logged In: YES user_id=80475 On the code path leading to a dsu_fail, does PyMem_FREE() ever get called? Would there be some added protection value to INCREFing self at the beginning and DECREFing it at the end? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-12-01 18:36 Message: Logged In: YES user_id=6656 Boy is this stuff hard to get right! See what you think of the attached patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-12-01 17:38 Message: Logged In: YES user_id=6656 Here's a much less devious test case: $ cat w.py def k(x): del l[:] return x l = range(10) l.sort(key=k) $ ./python w.py Segmentation fault i think doing the "hide ob_item" swizzle should be just about the first thing list_sort does and undoing it should be about the last. Patch soon (I hope). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-12-01 12:37 Message: Logged In: YES user_id=6656 I have a feeling that your fix for problem #2 has made problem #1 harder to fix... will have a look later, no time right now. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-29 01:56 Message: Logged In: YES user_id=80475 The second was easy to fix. The first is defying my attempts to fix it. You're welcome to take a crack at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848856&group_id=5470 From noreply at sourceforge.net Tue Dec 2 07:16:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 2 07:16:54 2003 Subject: [ python-Bugs-849097 ] Request: getpos() for sgmllib Message-ID: Bugs item #849097, was opened at 2003-11-25 17:47 Message generated for change (Comment added) made by d98dzone You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=849097&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Wiklund (d98dzone) Assigned to: Nobody/Anonymous (nobody) Summary: Request: getpos() for sgmllib Initial Comment: During the process of making my masters thesis I discovered the need for a working getpos() in sgmllib.py. As it is now you can successfully call it since it is inherited from markupbase.py but you will always get the answer (1,0) since it is never updated. To fix this one needs to change the goahead function. This is my own implementation of this change, in part influenced by the "sister" goahead-function in HTLMParser.py: ************************************ def goahead(self, end): rawdata = self.rawdata i = 0 k = 0 n = len(rawdata) tmp=0 while i < n: if self.nomoretags: self.handle_data(rawdata[i:n]) i = n break match = interesting.search(rawdata, i) if match: j = match.start() else: j = n if i < j: self.handle_data(rawdata[i:j]) tmp = self.updatepos(i, j) i = j if i == n: break startswith = rawdata.startswith if rawdata[i] == '<': if starttagopen.match(rawdata, i): if self.literal: self.handle_data(rawdata[i]) tmp = self.updatepos(i, i+1) i = i+1 continue k = self.parse_starttag(i) if k < 0: break tmp = self.updatepos(i, k) i = k continue if rawdata.startswith(" (i + 1): self.handle_data("<") i = i+1 tmp = self.updatepos(i, k) else: # incomplete break continue if rawdata.startswith("<------------------------><------------ (gotti@gglinux 534) PYTHONPATH=../../../COMMON.DEVEL/Tools/python/lib.linux- i686-2.3 python Konvertierung/entsch_pass2.py HI69228 x HR all_idx2.shelve Bugs item #855819, was opened at 2003-12-07 16:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=855819&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Fleiter (fleiter) Assigned to: Nobody/Anonymous (nobody) Summary: urllib does not handle Connection reset Initial Comment: Python 2.2.3+ (#1, Nov 18 2003, 01:16:59) [GCC 3.3.2 (Debian)] on linux2 and Python 2.3.3c1 (#2, Dec 6 2003, 16:44:56) [GCC 3.3.3 20031203 (prerelease) (Debian)] on linux2 Server which does reset Connection: ===================== import SocketServer class RequestHandler(SocketServer.BaseRequestHandler): def handle(self): self.request.send("") server = SocketServer.TCPServer(("localhost", 2000), RequestHandler) server.serve_forever() urllib-Code: ======= import urllib f = urllib.urlopen("http://localhost:2000") Traceback: ======= Traceback (most recent call last): File "url.py", line 4, in ? f = urllib.urlopen("http://localhost:2000") File "/usr/lib/python2.2/urllib.py", line 73, in urlopen return _urlopener.open(url) File "/usr/lib/python2.2/urllib.py", line 178, in open return getattr(self, name)(url) File "/usr/lib/python2.2/urllib.py", line 301, in open_http return self.http_error(url, fp, errcode, errmsg, headers) File "/usr/lib/python2.2/urllib.py", line 318, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "/usr/lib/python2.2/urllib.py", line 546, in http_error_default return addinfourl(fp, headers, "http:" + url) File "/usr/lib/python2.2/urllib.py", line 824, in __init__ addbase.__init__(self, fp) File "/usr/lib/python2.2/urllib.py", line 778, in __init__ self.read = self.fp.read The cause seems to be that urllib.addbase depends on the fp argument beeing a valid socket while fp = h.getfile() in open_http sets it to None because in httplib.HTTP.getreply() the BadStatusLine-Exception-Handling was triggered. urllib2 does handle this right. Thanks for reading all of this. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=855819&group_id=5470 From noreply at sourceforge.net Sun Dec 7 12:55:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 7 13:00:39 2003 Subject: [ python-Bugs-853800 ] No documentation for zipimport module Message-ID: Bugs item #853800, was opened at 2003-12-04 04:35 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853800&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: No documentation for zipimport module Initial Comment: It doesn't appear that the zipimport module is documented in Python 2.3.2, apart from a note in the "what's new in Python 2.3" section. It should really be in the list of all standard modules. Presumably the help(zipimport) contents could form the basis of this documentation. I'd be willing to put a patch together for this if someone gives me clear guidelines about what should be there. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-12-07 18:55 Message: Logged In: YES user_id=92689 The doc strings should indeed be a good start. See also http:// python.org/peps/pep-0273.html and http://python.org/peps/pep- 0302.html for way more details than neccesary for the docs. Feel free to concact me off line if you have more questions; your offer is most welcome! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853800&group_id=5470 From noreply at sourceforge.net Sun Dec 7 17:33:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 7 17:33:13 2003 Subject: [ python-Bugs-823672 ] os.strerror doesn't understand windows error codes Message-ID: Bugs item #823672, was opened at 2003-10-14 22:04 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823672&group_id=5470 Category: None Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: os.strerror doesn't understand windows error codes Initial Comment: For example, os.strerror(errno.EWOULDBLOCK) returns 'unknown error'. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-12-07 23:33 Message: Logged In: YES user_id=45365 That depends: if the C library returns EWOULDBLOCK in errno and then refuses to understand it in strerror() this is indeed not Python's problem. But if the C library never set errno to EWOULDBLOCK but we somehow generate it (and grepping on EWOULDBLOCK seems to indicate there could be something fishy going on with EWOULDBLOCK and WSAEWOULDBLOCK) we should have the courtesy to understand it in strerror(). I'll leave it to someone else to decide whether this makes sense and the bug should be reopened. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-24 22:15 Message: Logged In: YES user_id=21627 Why is this a bug in Python? os.strerror just calls the system's strerror(3). If that doesn't know its own errors, how should Python know? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823672&group_id=5470 From noreply at sourceforge.net Sun Dec 7 17:40:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 7 17:41:18 2003 Subject: [ python-Bugs-853558 ] new _Launch module includes useless deprecated functions Message-ID: Bugs item #853558, was opened at 2003-12-03 21:22 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853558&group_id=5470 Category: Macintosh Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: new _Launch module includes useless deprecated functions Initial Comment: You should blacklist LSInit and LSTerm, both are deprecated and should never be used. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-12-07 23:40 Message: Logged In: YES user_id=45365 Bob, please keep bug reports to exactly one topic per report. I'm not going to implement the suggestion of allowing None for OSType '\0\0\0\0' right now, but feel free to add a feature request. I think the original bug and your followon are now both fixed, if not please reopen the bug and provide details. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-12-03 22:38 Message: Logged In: YES user_id=139309 _Launch.LSGetApplicationForInfo should allow None (translated to NULL) for inType and inCreator (both are OSType). Currently you need to pass '\x00'*4 .. which sucks. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-12-03 22:14 Message: Logged In: YES user_id=139309 It seems that Universal Headers 3.4 is also missing a bunch of useful constants, like kLSItemInfoExtensionIsHidden Hopefully you'll move the scanner over to OS X headers sooner than later ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-12-03 21:52 Message: Logged In: YES user_id=45365 LSInit and LSTerm are gone in 1.2. The others will have to wait until we switch from parsing Universal Headers 3.4 to parsing native OSX headers (bug 779153). ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-12-03 21:36 Message: Logged In: YES user_id=139309 It's also missing: LSGetExtensionInfo [mostly a dupe of os.path.splitext, but might be nice to have] LSCopyDisplayNameForRef [these are a must have] LSCopyDisplayNameForURL LSSetExtensionHiddenForRef [these would be nice] LSSetExtensionHiddenForURL LSCopyKindStringForTypeInfo [these are a must have] LSCopyKindStringForMIMEType LSCopyApplicationForMIMEType LSFindApplicationForInfo [nice to have have, I think it's a subset of LSGetApplicationForInfo though] -- new things in 10.3 that might be nice to have -- LSRegisterURL LSRegisterFSRef LSCopyApplicationURLsForURL everything in UTType.h ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853558&group_id=5470 From noreply at sourceforge.net Sun Dec 7 19:17:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 7 19:17:14 2003 Subject: [ python-Bugs-844336 ] urllib2 fails its builtin test Message-ID: Bugs item #844336, was opened at 2003-11-18 12:32 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844336&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 fails its builtin test Initial Comment: >python -u "ftplib.py" Traceback (most recent call last): File "ftplib.py", line 803, in ? test() File "ftplib.py", line 762, in test while sys.argv[1] == '-d': IndexError: list index out of range >Exit code: 1 >python -u "urllib2.py" gopher://gopher.lib.ncsu.edu/11/library/stacks/Alex socket.error: (7, 'getaddrinfo failed') gopher://gopher.vt.edu:10010/10/33 socket.error: (7, 'getaddrinfo failed') file:/etc/passwd Traceback (most recent call last): File "urllib2.py", line 1154, in ? f = urlopen(url, req) File "urllib2.py", line 136, in urlopen return _opener.open(url, data) File "urllib2.py", line 333, in open '_open', req) File "urllib2.py", line 313, in _call_chain result = func(*args) File "urllib2.py", line 928, in file_open return self.open_local_file(req) File "urllib2.py", line 943, in open_local_file stats = os.stat(localfile) OSError: [Errno 2] No such file or directory: '\etc\passwd' >Exit code: 1 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-08 00:17 Message: Logged In: YES user_id=261020 Sorry, last comment not very useful. I think this should be closed. Two real problems: 1. urllib2.urlopen incorrectly raises OSError instead of URLError. This is already detected by my unit tests (852995), and I'll file a separate bug for this later (when/if 852995 is resolved). 2. Would be nice if urllib2's functional tests used PyUnit (so it is clear which tests are passing or failing), and worked on Windows. Again, I'll submit a separate patch. To the bug poster: 0. ftplib is not urllib2, please report bugs separately. 1. You're not invoking ftplib's test program correctly. It seems to work, at least partially: python ftplib.py ftp.python.org /pub/www.python.org/index.html 2. It seems you're using Windows, so you shouldn't expect opening /etc/password to work (though the test shouldn't crash as it does, of course, and it should work on Windows, and it should give an indication of pass/fail). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-03 19:40 Message: Logged In: YES user_id=261020 It is broken. I'd like to know where functional tests officially live before fixing it. I'll ask on python-dev... ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2003-11-18 22:04 Message: Logged In: YES user_id=285587 This is a response to quiver. Thanks for pointing out the correct usage of ftlib, I am slowly sorting out how to use ftplib from a script. Unfortunately my report did not make it clear that there is a problem with the operation of the test function. Usually, a test function gives some assurance that the main code of the module is functional. In this case, the test fails. That, I suggest, indicates a bug. The bug could be in test function or the module being exercised. You are probably right that a host needs to be specified. I suggest that the test function should be responsible for this. Incidentally, it would be very helpful to the potential user if the documentation made the names and roles of the various cmds's clearer. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-11-18 15:48 Message: Logged In: YES user_id=671362 For the first one, you need to specify a host to run the test. For expample, >python ftplib.py ftp.python.org -l This gives drwxrwxr-x 5 webmaster webmaster 512 Jan 25 2003 pub There is a usage on the test in the script: '''Test program. Usage: ftp [-d] [-r[file]] host [-l[dir]] [-d[dir]] [-p] [file] ...''' I think this is not a bug. For the second one, catching OSError along with IOError might be needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844336&group_id=5470 From noreply at sourceforge.net Sun Dec 7 20:22:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 7 20:22:18 2003 Subject: [ python-Bugs-851020 ] Missing BuildRequires in src rpm specfile Message-ID: Bugs item #851020, was opened at 2003-11-29 03:17 Message generated for change (Comment added) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851020&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael P. Soulier (msoulier) Assigned to: Nobody/Anonymous (nobody) Summary: Missing BuildRequires in src rpm specfile Initial Comment: I'm trying to build Python 2.3.2 on Fedora Core 1. The configure runs without errors, but I then get an odd error about pyconfig.h during the build. gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/dictobject.o Objects/dictobject.c In file included from Objects/dictobject.c:10: Include/Python.h:8:22: pyconfig.h: No such file or directory Include/Python.h:21:2: #error "limits.h is required by std C -- why isn't HAVE_LIMITS_H defined?" In file included from Include/Python.h:48, from Objects/dictobject.c:10: Include/pyport.h:4:48: pyconfig.h: No such file or directory Include/pyport.h:536:2: #error "could not set LONG_MAX in pyport.h" Objects/dictobject.c: In function `dictresize': Objects/dictobject.c:477: warning: implicit declaration of function `free' make: *** [Objects/dictobject.o] Error 1 [msoulier@tigger Python-2.3.2]$ find . -name pyconfig.h ./Mac/Include/pyconfig.h ./PC/pyconfig.h ./PC/os2emx/pyconfig.h ./PC/os2vacpp/pyconfig.h ./RISCOS/pyconfig.h ./pyconfig.h I'm not sure what the issue is here. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-12-08 01:22 Message: Logged In: YES user_id=81797 Please go ahead and close this. See patch #855999, which includes a patch for the .spec file which seems to work with Fedora Core 1. I've also uploaded a new SRPM and Fedora binaries to the FTP site, and will be updating the web-page in a bit. Sean ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-12-05 01:08 Message: Logged In: YES user_id=81797 I guess I can't attach files to this bug. I've uploaded the patch and the patched .spec file to ftp://ftp.tummy.com/pub/tummy/Python/patches/ Let me know how this looks, and I'll either fix it or submit it as a patch. Thanks, Sean ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-12-05 01:03 Message: Logged In: YES user_id=81797 Ugh, sorry, I wasn't logged in. The last message was from me. Sean ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-12-05 01:02 Message: Logged In: NO I'm attaching a patch and a patched version of the spec-file which adds the tcl and tk prerequesites for building if tkinter is enabled. I'm running into a problem when building with these on Fedora, but I'm not sure if it's an environment problem or a .spec problem. I'd appreciate feedback on wether this spec file works for anyone. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-12-04 07:20 Message: Logged In: YES user_id=21627 Can you contribute a patch for the spec files (in Misc/RPM)? ---------------------------------------------------------------------- Comment By: Michael P. Soulier (msoulier) Date: 2003-12-04 02:18 Message: Logged In: YES user_id=470843 > Building now... It worked! Cool. Changing Summary: Was: building on Fedora Core 1 Is: Missing BuildRequires in src rpm specfile ---------------------------------------------------------------------- Comment By: Michael P. Soulier (msoulier) Date: 2003-12-04 01:53 Message: Logged In: YES user_id=470843 > Make sure you have the tcl-devel and tk-devel RPMs installed. I did not have tcl-devel installed. I'll try again now. Note that if tk-devel and tcl-devel are required to build this src rpm, then they should be listed in the BuildRequires section of the specfile. Building now... ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-12-03 22:59 Message: Logged In: YES user_id=29957 Note that I build the 23-maint and HEAD on FC1 frequently, and haven't had any problems like this at all. Make sure you have the tcl-devel and tk-devel RPMs installed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-12-03 06:49 Message: Logged In: YES user_id=21627 It would be good if you could add print statements to setup.py:detect_tkinter, to find out why it gives up. Alternatively, you can edit Modules/Setup to force _tkinter being built. ---------------------------------------------------------------------- Comment By: Michael P. Soulier (msoulier) Date: 2003-12-03 01:20 Message: Logged In: YES user_id=470843 Well, this is quite odd, but I rebuilt and the error didn't happen this time. I'm not sure why. However, I'm having a problem getting Tkinter built. I'm trying to port the src rpm currently, but when I do the --rebuild, I get this in post-processing. RPM build errors: File not found by glob: /var/tmp/python2.3-2.3.2-root/usr/lib/python2.3/lib-dynload/_tkinter.so* Looks like it was never built. [msoulier@tigger msoulier]$ cd rpms [msoulier@tigger rpms]$ cd BUILD/ [msoulier@tigger BUILD]$ ls Python-2.3.2 [msoulier@tigger BUILD]$ find Python-2.3.2/ -name "_tkinter*" Python-2.3.2/Modules/_tkinter.c Python-2.3.2/PC/os2vacpp/_tkinter.def Python-2.3.2/PCbuild/_tkinter.dsp I logged the entire build, if you'd like me to attach it. [msoulier@tigger msoulier]$ rpm -q tk-devel tk-devel-8.3.5-93 Thanks. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-12-01 21:43 Message: Logged In: YES user_id=21627 Can you pleas invoke the gcc command line manually, passing -v to gcc? This looks like a bug in the gcc installation: If -I. is given, it should find ./pyconfig.h. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851020&group_id=5470 From noreply at sourceforge.net Sun Dec 7 23:15:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 7 23:15:16 2003 Subject: [ python-Bugs-856047 ] urllib.py does not use "no_proxy" Message-ID: Bugs item #856047, was opened at 2003-12-08 15:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856047&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Donovan Baarda (abo) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.py does not use "no_proxy" Initial Comment: urllib.py uses "*_proxy" variables to identify proxies to use in the "getproxies()" function. However, it does not use the corresponding "no_proxy" variable in the "proxy_bypass()" method. This affects any platform that can use "*_proxy" environment variables to specify proxies. This includes win32, which will use environment variables before the registry if they are defined. On win32 this causes the confusing behaviour of using the registry for "proxy_bypass()" checking when "*_proxy" environment variables are used to identify the proxies. Attached is a patch against python-2.3.2 that adds support for "no_proxy". Note that win32 will correctly favor using "no_proxy" over using the registry if any "*_proxy" variables are defined. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856047&group_id=5470 From noreply at sourceforge.net Sun Dec 7 23:27:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 7 23:27:33 2003 Subject: [ python-Bugs-856047 ] urllib.py does not use "no_proxy" Message-ID: Bugs item #856047, was opened at 2003-12-08 15:15 Message generated for change (Comment added) made by abo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856047&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Donovan Baarda (abo) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.py does not use "no_proxy" Initial Comment: urllib.py uses "*_proxy" variables to identify proxies to use in the "getproxies()" function. However, it does not use the corresponding "no_proxy" variable in the "proxy_bypass()" method. This affects any platform that can use "*_proxy" environment variables to specify proxies. This includes win32, which will use environment variables before the registry if they are defined. On win32 this causes the confusing behaviour of using the registry for "proxy_bypass()" checking when "*_proxy" environment variables are used to identify the proxies. Attached is a patch against python-2.3.2 that adds support for "no_proxy". Note that win32 will correctly favor using "no_proxy" over using the registry if any "*_proxy" variables are defined. ---------------------------------------------------------------------- >Comment By: Donovan Baarda (abo) Date: 2003-12-08 15:27 Message: Logged In: YES user_id=10273 Whups... failed to attach patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856047&group_id=5470 From noreply at sourceforge.net Mon Dec 8 01:19:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 8 01:19:35 2003 Subject: [ python-Bugs-856072 ] UserDict.DictMixin's comments should be a docstring Message-ID: Bugs item #856072, was opened at 2003-12-08 17:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856072&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Bennetts (spiv) Assigned to: Nobody/Anonymous (nobody) Summary: UserDict.DictMixin's comments should be a docstring Initial Comment: DictMixin in the UserDict module has no docstring -- but it has a comment that reads like one. I think the comment should probably be changed to a docstring so that interactive use of e.g. "help(UserDict.DictMixin)" explains how it works (override _getitem__(), __setitem__(), __delitem__(), and keys(), and the rest is done for you). If the existing comment is considered too cryptic, the text in the Library Reference for DictMixin would be a good basis for a docstring. (This is a really minor bug, but it's a shame to see such a useful class not being perfectly documented! :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856072&group_id=5470 From noreply at sourceforge.net Mon Dec 8 03:48:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 8 03:48:38 2003 Subject: [ python-Bugs-856103 ] reload() fails with modules from zips Message-ID: Bugs item #856103, was opened at 2003-12-08 21:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: reload() fails with modules from zips Initial Comment: If you call reload() with a module that was imported from a zip, it fails with a "no such module" error. Although zips are typically read-only, it is possible that a zip could be modified during a run, and a reload be necessary. If this is considered unnecessary, then I think a more informative "can't reload from zip" error would be better than a 'no such module" one. """ >set PYTHONPATH=path/to/spambayes.zip >python >>> from spambayes import Options >>> Options >>> reload(Options) Traceback (most recent call last): File "", line 1, in ? ImportError: No module named Options """ This is with Python 2.3.2 and WinXP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&group_id=5470 From noreply at sourceforge.net Mon Dec 8 14:07:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 8 14:07:37 2003 Subject: [ python-Bugs-856387 ] PyMac_GetOSErrException hack for 2.3.0 compatibility? Message-ID: Bugs item #856387, was opened at 2003-12-08 14:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856387&group_id=5470 Category: Macintosh Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: PyMac_GetOSErrException hack for 2.3.0 compatibility? Initial Comment: I'd like to be able to backport modules from Python CVS to 2.3.0, such as _Launch, without changing source if possible. The older pymactoolbox.h did not have PyMac_GetOSErrException. I guess this was in macglue.h previously? distutils always puts the installed Python's include dir first, so I can't use my CVS include dir. Would it be reasonable to put a hack in the sources for these modules such that they can work around the pymactoolbox.h differences, or should I replace my system pymactoolbox.h? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856387&group_id=5470 From noreply at sourceforge.net Mon Dec 8 14:31:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 8 14:31:31 2003 Subject: [ python-Bugs-856401 ] Definitive way to link to the correct Python.framework Message-ID: Bugs item #856401, was opened at 2003-12-08 14:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856401&group_id=5470 Category: Macintosh Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: Definitive way to link to the correct Python.framework Initial Comment: The link target for Python should be specified by introspecting the Python framework itself and linking directly to the framework dylib, rather than using -framework and overriding the framework search path with -F. Using -F may have undesirable side-effects. Example: User has Python at /Library/Frameworks and wants to build an extension module that links to ~/Library/ Frameworks/FooFramework.framework. User also has a / Library/Frameworks/FooFramework.framework that they do not want to link against. Solution: Rather than -framework Python, Python should link directly to NSBundle.bundleWithIdentifier_('org.python.Python.framewor k').executablePath(). Stock 10.3 has this located at: u'/System/Library/Frameworks/Python.framework/Python'. The value of this is entirely dependent on the current running version of Python that the extension module will be linked against. The dylib identifier will of course be expanded to the full /System/Library/Frameworks/Python.framework/ Versions/2.3/Python by the linker. Caveats: Example requires PyObjC, however these APIs are available in CoreFoundation's CFBundle and could easily be put into an extension module if PyObjC is not to be distributed with the next version of Python. It will likely require a platform specific patch to distutils. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856401&group_id=5470 From noreply at sourceforge.net Mon Dec 8 14:40:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 8 14:40:15 2003 Subject: [ python-Bugs-856407 ] Framework Info.plist is out of date Message-ID: Bugs item #856407, was opened at 2003-12-08 14:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856407&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: Framework Info.plist is out of date Initial Comment: Version 2.3.0 through CVS HEAD of Python still has CFBundleShortVersionString and CFBundleVersion of 2.2 in python/dist/src/Mac/OSXResources/framework/Info.plist. Here is a breakdown: Python 2.3.0 (distrib with OS X 10.3): - framework Info.plist : out of date - framework version.plist : out of date - app version.plist : out of date + app Info.plist : correct Python CVS HEAD (Dec 8 2003, anon CVS): - framework Info.plist : out of date - framework version.plist : correct + app Info.plist : correct ? app version.plist : probably correct? (I don't have a built version, there is not a separate version.plist sitting around in CVS) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856407&group_id=5470 From noreply at sourceforge.net Mon Dec 8 14:47:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 8 14:48:07 2003 Subject: [ python-Bugs-856387 ] PyMac_GetOSErrException hack for 2.3.0 compatibility? Message-ID: Bugs item #856387, was opened at 2003-12-08 14:07 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856387&group_id=5470 Category: Macintosh Group: Feature Request Status: Open Resolution: None >Priority: 1 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: PyMac_GetOSErrException hack for 2.3.0 compatibility? Initial Comment: I'd like to be able to backport modules from Python CVS to 2.3.0, such as _Launch, without changing source if possible. The older pymactoolbox.h did not have PyMac_GetOSErrException. I guess this was in macglue.h previously? distutils always puts the installed Python's include dir first, so I can't use my CVS include dir. Would it be reasonable to put a hack in the sources for these modules such that they can work around the pymactoolbox.h differences, or should I replace my system pymactoolbox.h? ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2003-12-08 14:47 Message: Logged In: YES user_id=139309 This is the method I'm currently using: I have a folder build_launch sitting next to my checkout of Python CVS. In it, I have a folder src/launch that was cp -r'ed from the Python CVS tree. Also inside src/launch, I have symlink to ../../../ python/dist/src/Include/pythonmac.h. This builds correctly, as the additions to pythonmac.h reflect functions that are actually exported from the Python.framework, but were not in the older version of pythonmac.h. This seems to work alright, because I can still (separately though) cvs up in my copied launch folder, and the pythonmac.h will be updated whenever I cvs up python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856387&group_id=5470 From noreply at sourceforge.net Mon Dec 8 14:51:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 8 14:52:34 2003 Subject: [ python-Bugs-856407 ] Framework Info.plist is out of date Message-ID: Bugs item #856407, was opened at 2003-12-08 20:40 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856407&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: Framework Info.plist is out of date Initial Comment: Version 2.3.0 through CVS HEAD of Python still has CFBundleShortVersionString and CFBundleVersion of 2.2 in python/dist/src/Mac/OSXResources/framework/Info.plist. Here is a breakdown: Python 2.3.0 (distrib with OS X 10.3): - framework Info.plist : out of date - framework version.plist : out of date - app version.plist : out of date + app Info.plist : correct Python CVS HEAD (Dec 8 2003, anon CVS): - framework Info.plist : out of date - framework version.plist : correct + app Info.plist : correct ? app version.plist : probably correct? (I don't have a built version, there is not a separate version.plist sitting around in CVS) ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-12-08 20:51 Message: Logged In: YES user_id=45365 These should have been fixed in the 2.3maint branch (could you check)? I haven't changed it yet on the head, because I hope to generate these files before 2.4final. I did add a note to the readme file about updating this version number. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856407&group_id=5470 From noreply at sourceforge.net Mon Dec 8 14:53:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 8 14:53:33 2003 Subject: [ python-Bugs-856387 ] PyMac_GetOSErrException hack for 2.3.0 compatibility? Message-ID: Bugs item #856387, was opened at 2003-12-08 20:07 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856387&group_id=5470 Category: Macintosh Group: Feature Request Status: Open Resolution: None Priority: 1 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: PyMac_GetOSErrException hack for 2.3.0 compatibility? Initial Comment: I'd like to be able to backport modules from Python CVS to 2.3.0, such as _Launch, without changing source if possible. The older pymactoolbox.h did not have PyMac_GetOSErrException. I guess this was in macglue.h previously? distutils always puts the installed Python's include dir first, so I can't use my CVS include dir. Would it be reasonable to put a hack in the sources for these modules such that they can work around the pymactoolbox.h differences, or should I replace my system pymactoolbox.h? ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-12-08 20:53 Message: Logged In: YES user_id=45365 Including macglue.h will also include pymactoolbox.h, so moving the declaration there in 2.3maint looks safe enough (and, indeed, it should have been there in the first place). ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-12-08 20:47 Message: Logged In: YES user_id=139309 This is the method I'm currently using: I have a folder build_launch sitting next to my checkout of Python CVS. In it, I have a folder src/launch that was cp -r'ed from the Python CVS tree. Also inside src/launch, I have symlink to ../../../ python/dist/src/Include/pythonmac.h. This builds correctly, as the additions to pythonmac.h reflect functions that are actually exported from the Python.framework, but were not in the older version of pythonmac.h. This seems to work alright, because I can still (separately though) cvs up in my copied launch folder, and the pythonmac.h will be updated whenever I cvs up python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856387&group_id=5470 From noreply at sourceforge.net Mon Dec 8 21:47:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 8 21:47:45 2003 Subject: [ python-Bugs-856617 ] HTMLParser parsers AT&T to AT Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Bugs item #856617, was opened at 2003-12-09 10:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856617&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hammer Lee (lhy719) Assigned to: Nobody/Anonymous (nobody) Summary: HTMLParser parsers AT&T to AT Initial Comment: I use HTMLParser to parse HTML files. There is an mistake when HTML contents have '&', like
AT&T Research Labs Cambridge - WinVNC Version 3, 3, 3, 7. HTMLParser parses "AT&T Research" to "AT Research". It happens on "ETTC&P EpSCTWeb_Fr Application Version 1, 0, 0, 1" also. I'm a newbie in Python, I don't know how to solve it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856617&group_id=5470 From noreply at sourceforge.net Mon Dec 8 22:15:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 8 22:15:04 2003 Subject: [ python-Bugs-856623 ] Erroneous code objects created with PyCode_New Message-ID: Bugs item #856623, was opened at 2003-12-09 16:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856623&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim McLennan (timmcl) Assigned to: Nobody/Anonymous (nobody) Summary: Erroneous code objects created with PyCode_New Initial Comment: If you copy a code object by calling say new.code with just the members of an existing code object with free/cell variables - such as the following nested example: def null(): return None def wrapfunc(func): def _inner(*args): return func(*args) return _inner wrapped = wrapfunc(null) code_object = wrapped.func_code new_code_object = new.code(< code_object >) then the new_code_object will not have had its free/cell vars removed and will thus not disassemble correctly. Furthermore if you create a function out of it, then calling the function will raise - SystemError: R:Python23srcPython-2.3.2Objectscellobject.c: 22: bad argument to internal function Looking at the code in PyCode_New I can't see why this should happen. (Bug noticed on Python 2.3.2 on windows) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856623&group_id=5470 From noreply at sourceforge.net Mon Dec 8 23:39:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 8 23:39:10 2003 Subject: [ python-Bugs-856656 ] Problem in calling kpathsea library from Python extension Message-ID: Bugs item #856656, was opened at 2003-12-09 13:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856656&group_id=5470 Category: None Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jin-Hwan Cho (chofchof) Assigned to: Nobody/Anonymous (nobody) Summary: Problem in calling kpathsea library from Python extension Initial Comment: 1. Environment: System: FreeBSD 5.1-RELEASE Packages: python-2.2.2_2, teTeX-2.0.2_2 (kpathsea library version 3.4.5) 2. Description: Recently I was trying to write a Python extension using the kpathsea library. It was simple and everying went smoothly. But I got a severe problem in FreeBSD. Even simple code did not work in FreeBSD. After trying some tests, I found where the problem occurred. That was "cnf.c" in the kpathsea library (contained in teTeX-2.0.2_2 package). There is a place in "cnf.c" calling "hash_create()" function (defined in hash.c). However, in FreeBSD, the "hash_create()" was not called properly. After changing the name "hash_create()" to another one, for example, "hash_create2()", everything worked fine. I'd like to know exact reason why this kind of problem occurs in FreeBSD. 3. How-To-Repeat: On FreeBSD system with python-2.2.2_2 and teTeX- 2.0.2_2 installed, using the attached three files, run the following command python setup.py install and then run python kpse_test.py The result was "Segmentation fault (core dumped)". 4. Fix: The problem above can be fixed by modifying the kpathsea library itself as follows: Change the name of "hash_create" function (defined in hash.c) to another name, for example, "hash_create2" from several files, cnf.c, db.c, dir.c, fontname.c, hash.c, and hash.h. It seems quite curious because there was no problem in cygwin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856656&group_id=5470 From noreply at sourceforge.net Tue Dec 9 02:08:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 9 02:08:56 2003 Subject: [ python-Bugs-856706 ] popen3 under threads reports different stderr results Message-ID: Bugs item #856706, was opened at 2003-12-08 23:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856706&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Steven Howe (stevenhowe) Assigned to: Nobody/Anonymous (nobody) Summary: popen3 under threads reports different stderr results Initial Comment: Using os.popen3 inside a thread (start_new_thread) returns different results from the stderr file dev. I discovered this while trying to trap badblocks program output. I have usb floppy I am trying to format, after a badblock check. My floppy is on /dev/sdb. code: import thread import os def dd( outfilename ): cmd='/sbin/badblocks -n -s -v -c 16 -b 512 /dev/sdb' channels = os.popen3( cmd ) ch = ' ' ff = '/tmp/%s' % outfilename out=open( ff ,'w') while ch != '': ch = channels[2].read(1) out.write( ch ) Run two ways. First as a stand alone code. Then as a threaded program. def( 'nothread.err' ) thead.start_new_thread( def, ( 'thread.err' ) ) --------------- Now view the results with od -ta. You will see that the results are very different. All the the verbose data, on current blocks completed, are missing. Steven Howe ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856706&group_id=5470 From noreply at sourceforge.net Tue Dec 9 07:20:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 9 07:20:57 2003 Subject: [ python-Bugs-856387 ] PyMac_GetOSErrException hack for 2.3.0 compatibility? Message-ID: Bugs item #856387, was opened at 2003-12-08 20:07 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856387&group_id=5470 Category: Macintosh Group: Feature Request Status: Open Resolution: None Priority: 1 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: PyMac_GetOSErrException hack for 2.3.0 compatibility? Initial Comment: I'd like to be able to backport modules from Python CVS to 2.3.0, such as _Launch, without changing source if possible. The older pymactoolbox.h did not have PyMac_GetOSErrException. I guess this was in macglue.h previously? distutils always puts the installed Python's include dir first, so I can't use my CVS include dir. Would it be reasonable to put a hack in the sources for these modules such that they can work around the pymactoolbox.h differences, or should I replace my system pymactoolbox.h? ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-12-09 13:20 Message: Logged In: YES user_id=45365 Coming to think of it: the solution of moving the definition to pymactoolbox.h isn't good enough for distributing source modules to Python 2.3.0, which we also want. I will adapt the sources to compile both under 2.3.0 and 2.4. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-12-08 20:53 Message: Logged In: YES user_id=45365 Including macglue.h will also include pymactoolbox.h, so moving the declaration there in 2.3maint looks safe enough (and, indeed, it should have been there in the first place). ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-12-08 20:47 Message: Logged In: YES user_id=139309 This is the method I'm currently using: I have a folder build_launch sitting next to my checkout of Python CVS. In it, I have a folder src/launch that was cp -r'ed from the Python CVS tree. Also inside src/launch, I have symlink to ../../../ python/dist/src/Include/pythonmac.h. This builds correctly, as the additions to pythonmac.h reflect functions that are actually exported from the Python.framework, but were not in the older version of pythonmac.h. This seems to work alright, because I can still (separately though) cvs up in my copied launch folder, and the pythonmac.h will be updated whenever I cvs up python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856387&group_id=5470 From noreply at sourceforge.net Tue Dec 9 07:34:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 9 07:34:29 2003 Subject: [ python-Bugs-212317 ] os.rename transparent handling of cross-filesystem issues Message-ID: Bugs item #212317, was opened at 2000-08-19 19:09 Message generated for change (Comment added) made by tibi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=212317&group_id=5470 Category: Python Library Group: Feature Request Status: Closed Resolution: Later Priority: 3 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: os.rename transparent handling of cross-filesystem issues Initial Comment: On some systems (specifically, Linux), the rename system call will throw an EXDEV error if rename is used across filesystems. It would be convenient for the user if os.rename were extended to handle this transparently (like most mv commands do). The benefits of this. . .getting rid of code like the following: try: os.rename('ff','/tmp/ff') except: open('/tmp/ff','w').write(open('ff','r').read()) os.unlink('ff') Actually, the real benefit is that code (written by morons like myself) using os.rename will continue to work even after the administrator moves the target directory to another filesystem. I took a quick look at posixmodule.c. A quick hack changes posix_2str's signature to the following: PyObject *args char *format int (*func)(const char*, const char *) int (*special_handler)(const char *, const char *) and the inner function to: if (res != 0) if ((! special_handler) || (*special_handler)(path1,path2)) return posix_error() Of course, then a smart copy routine (includes an unlink step). The most unclear thing at this point is what to do with the errno. Would a failure in the errorhandler report the original errno or its own errno??? Personally, a more general solution would allow the user (python-level) to optionally pass in *their own* error handling function/method. ---------------------------------------------------------------------- Comment By: Thi?baut Champenier (tibi) Date: 2003-12-09 13:34 Message: Logged In: YES user_id=25413 Since Python 2.3 the shutil module has a move function that implements this functionality. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-03-08 18:03 Message: Logged In: NO also unix weenies expect rename() to be atomic. making it non-atomic can break lots of code that is carefully crafted to survive nfs, or do locking with rename(), etc. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-30 19:43 Message: Copying files (and directories) properly is a very platform specific task -- there are lots of pitfalls that the copying code has to watch out for, e.g. copying files with "holes", properly copying all metadata, copying special files... I think that the os.rename() call is not the proper place to implement all this. But it's a useful feature nevertheless, and could perhaps be accommodated by a higher level function in the shutil module (which has the basic copying primitives). ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2000-09-15 22:01 Message: Moved to PEP 42 as a feature request for a post-2.0 version of Python. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2000-09-08 00:05 Message: Please do triage on this bug. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2000-08-25 16:44 Message: revisit this after 2.0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=212317&group_id=5470 From noreply at sourceforge.net Tue Dec 9 07:57:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 9 07:57:43 2003 Subject: [ python-Bugs-856841 ] a exception ocurrs when compiling a Python file Message-ID: Bugs item #856841, was opened at 2003-12-09 09:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856841&group_id=5470 Category: Parser/Compiler Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Pablo Yabo (pablo_yabo) Assigned to: Nobody/Anonymous (nobody) Summary: a exception ocurrs when compiling a Python file Initial Comment: a exception ocurrs when compiling some big python files (more than 250kb) using the debug library (python22_d.dll). When using the release library in the release version of my application the files compile succesfully. Attached is the stack trace. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856841&group_id=5470 From noreply at sourceforge.net Tue Dec 9 08:11:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 9 08:12:02 2003 Subject: [ python-Bugs-856401 ] Definitive way to link to the correct Python.framework Message-ID: Bugs item #856401, was opened at 2003-12-08 20:31 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856401&group_id=5470 Category: Macintosh Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: Definitive way to link to the correct Python.framework Initial Comment: The link target for Python should be specified by introspecting the Python framework itself and linking directly to the framework dylib, rather than using -framework and overriding the framework search path with -F. Using -F may have undesirable side-effects. Example: User has Python at /Library/Frameworks and wants to build an extension module that links to ~/Library/ Frameworks/FooFramework.framework. User also has a / Library/Frameworks/FooFramework.framework that they do not want to link against. Solution: Rather than -framework Python, Python should link directly to NSBundle.bundleWithIdentifier_('org.python.Python.framewor k').executablePath(). Stock 10.3 has this located at: u'/System/Library/Frameworks/Python.framework/Python'. The value of this is entirely dependent on the current running version of Python that the extension module will be linked against. The dylib identifier will of course be expanded to the full /System/Library/Frameworks/Python.framework/ Versions/2.3/Python by the linker. Caveats: Example requires PyObjC, however these APIs are available in CoreFoundation's CFBundle and could easily be put into an extension module if PyObjC is not to be distributed with the next version of Python. It will likely require a platform specific patch to distutils. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-12-09 14:11 Message: Logged In: YES user_id=45365 Bob, I'm not convinced. First, the problem you sketch seems a bit academic (the user linking a Python extension against a framework for which one system-wide copy and one per-user copy exists), and there is a workaround too (the user adds another -F just before their own framework). Second, I'm not convinced that "-framework Python" doesn't do more than just linking against the dylib inside the framework, or that it may do so in the future. Finally, with the current distutils we cannot easily use introspection to get the real location of the framework that python is running from: distutils picks up this value from the Makefile LDSHARED variable, so the only thing we can do without distutils surgery is replace LDSHARED= $(CC) $(LDFLAGS) -bundle -Wl,- F$(PYTHONFRAMEWORKPREFIX) -framework $(PYTHONFRAMEWORK) with LDSHARED= $(CC) $(LDFLAGS) -bundle $(PYTHONFRAMEWORKINSTALLDIR)/$(PYTHONFRAMEWORK) All in all I'm tempted to close this as "won't fix", but I'll give you another couple of days to convince me otherwise:-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856401&group_id=5470 From noreply at sourceforge.net Tue Dec 9 09:49:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 9 09:49:42 2003 Subject: [ python-Bugs-856401 ] Definitive way to link to the correct Python.framework Message-ID: Bugs item #856401, was opened at 2003-12-08 14:31 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856401&group_id=5470 Category: Macintosh Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: Definitive way to link to the correct Python.framework Initial Comment: The link target for Python should be specified by introspecting the Python framework itself and linking directly to the framework dylib, rather than using -framework and overriding the framework search path with -F. Using -F may have undesirable side-effects. Example: User has Python at /Library/Frameworks and wants to build an extension module that links to ~/Library/ Frameworks/FooFramework.framework. User also has a / Library/Frameworks/FooFramework.framework that they do not want to link against. Solution: Rather than -framework Python, Python should link directly to NSBundle.bundleWithIdentifier_('org.python.Python.framewor k').executablePath(). Stock 10.3 has this located at: u'/System/Library/Frameworks/Python.framework/Python'. The value of this is entirely dependent on the current running version of Python that the extension module will be linked against. The dylib identifier will of course be expanded to the full /System/Library/Frameworks/Python.framework/ Versions/2.3/Python by the linker. Caveats: Example requires PyObjC, however these APIs are available in CoreFoundation's CFBundle and could easily be put into an extension module if PyObjC is not to be distributed with the next version of Python. It will likely require a platform specific patch to distutils. ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2003-12-09 09:49 Message: Logged In: YES user_id=139309 1) Yeah, it's a little academic, but it solves a problem we have without changing the normal link order that a user will probably expect. -F can be wrong too, if PYTHONFRAMEWORKPREFIX is compile time. 2) Trust me, it doesn't do more than linking against the dylib inside the framework. There is nothing in the mach-o spec it *could* do, unless they add framework specific load commands in OS X 10.4+ (doubtful). I know those header files pretty well and have looked at bits and pieces of related darwin source (nm, otool, install_name_tool, etc). 3) Yeah the current distutils is a pain in the butt. I don't like the easy change to distutils. Maybe it fails for a user install version of Python if PYTHONFRAMEWORKPREFIX is set at compile time? I'd MUCH rather have this dir come from introspection because then it will be correct, for example from a 10.3 SDK on 10.4. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-12-09 08:11 Message: Logged In: YES user_id=45365 Bob, I'm not convinced. First, the problem you sketch seems a bit academic (the user linking a Python extension against a framework for which one system-wide copy and one per-user copy exists), and there is a workaround too (the user adds another -F just before their own framework). Second, I'm not convinced that "-framework Python" doesn't do more than just linking against the dylib inside the framework, or that it may do so in the future. Finally, with the current distutils we cannot easily use introspection to get the real location of the framework that python is running from: distutils picks up this value from the Makefile LDSHARED variable, so the only thing we can do without distutils surgery is replace LDSHARED= $(CC) $(LDFLAGS) -bundle -Wl,- F$(PYTHONFRAMEWORKPREFIX) -framework $(PYTHONFRAMEWORK) with LDSHARED= $(CC) $(LDFLAGS) -bundle $(PYTHONFRAMEWORKINSTALLDIR)/$(PYTHONFRAMEWORK) All in all I'm tempted to close this as "won't fix", but I'll give you another couple of days to convince me otherwise:-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856401&group_id=5470 From noreply at sourceforge.net Tue Dec 9 14:19:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 9 14:20:09 2003 Subject: [ python-Bugs-779976 ] docs missing 'trace' module Message-ID: Bugs item #779976, was opened at 2003-07-29 21:05 Message generated for change (Comment added) made by phansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779976&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Jeremy Hylton (jhylton) Summary: docs missing 'trace' module Initial Comment: The 'trace' module is new in Python 2.3. There is no mention of it in the module listing at http://www.python.org/ doc/2.3/modindex.html nor is it documented in the "undocumented modules" chapter at http://www.python.org/ doc/2.3/lib/undoc.html . (You would think as one of the coauthors for that module that I could be of help, but it's been about 4 years since I looked at it. :) ---------------------------------------------------------------------- Comment By: Peter Hansen (phansen) Date: 2003-12-09 14:19 Message: Logged In: YES user_id=567267 A trivial related note: Tools/Scripts/README.txt still lists trace.py as though it were still there and not in Lib instead. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-16 08:17 Message: Logged In: YES user_id=6656 Armin and I were talking about factoring out the co_lnotab-frobbing code and were being hampered by not knowing what the code was trying to do... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-09-09 16:00 Message: Logged In: YES user_id=3066 Jeremy made this a module, so he's volunteered to write the LaTeX docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779976&group_id=5470 From noreply at sourceforge.net Tue Dec 9 17:59:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 9 17:59:32 2003 Subject: [ python-Feature Requests-841728 ] urllib and cookie module improvements Message-ID: Feature Requests item #841728, was opened at 2003-11-13 20:56 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=841728&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: urllib and cookie module improvements Initial Comment: 1. The Cookie module should do a better job parsing real- world cookies (the stuff that comes from http servers following Set-cookie: headers) and should also have a documented way to emit a client-side cookie (i.e. generate a correct Cookie: header from a cookie object). 2. Urllib or urllib2 should be enhanced to read incoming cookie headers and send back the appropriate cookies in the event of an HTTP redirect. Many sites set a cookie then redirect to some other location which tries to read the cookie; if the cookie isn't there, the new location bounces back to the original one to set the cookie, so you get a redirection loop. 3. The scheme of having urllib.urlopen() return the http headers in a dictionary-like object doesn't quite work: for example, there can be several Set-cookie headers in a single http response. I don't know if the opener currently combines them or discards some; neither way is really satisfactory. There really should be a list for each header type, but that would mess up the existing published interface, so maybe a new 'urllib3' is needed. I'm just starting to explore this stuff but it seems to me like a serious urllib module needs to do quite a bit more than the existing ones do. The Perl LWP documentation might be a good place to look for inspiration. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-09 22:59 Message: Logged In: YES user_id=261020 Hmm, on 3., it's true that there is no documented way of getting at multiple headers (and in fact, at the moment the object returned by urlopen(url).info() is a subclass of mimetools.Message, which is deprecated, so .getallmatchingheaders() might well disappear soon). CVS rev 1.57 of httplib attempted to fix this (bug 432621), but the solution (making headers available joined with commas) is not sufficient, thanks to the nonstandard behaviour of Set-Cookie headers (Netscape cookie values may contain unquoted commas, in violation of RFC 2616). I suppose in future, HTTP response objects will be implemented using email.Message objects (since mimetools is deprecated), so it seems reasonable to add and document a .get_all(hdr_name) method to httplib.HTTPMessage (perhaps by going ahead and reimplementing it using email.Message). I'll put it on my list to write a patch. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-03 19:08 Message: Logged In: YES user_id=261020 1. and 2. are dealt with in another tracker items, 3. is incorrect, so this should be closed. It's better if you submit different issues separately if possible. 1. See http://wwwsearch.sf.net/ClientCookie. It doesn't use the Cookie module, since the code in the two modules is almost disjoint, and it would just obfuscate ClientCookie, really. (Oh, it's Paul Rubin... I see from your recent c.l.py message you've just noticed this module :-) 2. As for 1. I'm working on getting ClientCookie into a state suitable for the standard library. See also patches 852995, which makes it possible to implement cookie handling in a urllib2 handler, and 548197, which is somebody else's old cookie-handling patch. 3. You can already get the separate headers too: response.info().getallmatchingheaders("Set-Cookie"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=841728&group_id=5470 From noreply at sourceforge.net Tue Dec 9 21:22:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 9 21:22:49 2003 Subject: [ python-Bugs-857297 ] Tarfile and hard-links Message-ID: Bugs item #857297, was opened at 2003-12-10 02:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857297&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ricardo Martins (aggression) Assigned to: Nobody/Anonymous (nobody) Summary: Tarfile and hard-links Initial Comment: The attachment has a tar.gz file which contains a file and an hard-link to that file. The Python script unpacks the tar file to 3 locations: the current directory, the current directory specified by absolute path and /tmp). In the machines I've tested it, when unpacking to /tmp (or any other directory that does not belongs to the same branch as the current) the hard-link is not created. Am I missing something ? I have tested it with the tarfile module that ships with Python 2.3.2, and with the CVS tarfile module, the behavior is the same. Regards Ricardo Martins ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857297&group_id=5470 From noreply at sourceforge.net Wed Dec 10 06:38:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 10 06:38:36 2003 Subject: [ python-Bugs-848871 ] Windows installer halts Message-ID: Bugs item #848871, was opened at 2003-11-25 12:38 Message generated for change (Comment added) made by morr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848871&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jens Olsson (morr) Assigned to: Thomas Heller (theller) Summary: Windows installer halts Initial Comment: The Windows installer halts when starting to install files, more exactly when installing the file "UNWISE.EXE" and the progress bar reads "1%". Python versions tested: 2.2.3 2.3.1 2.3.2 2.3.2-1 All tested versions behave the same. Since I don't believe it's a common bug I attach selected computer specs for the system in question. I find it hard to believe it is the python windows installer by itself that contains the bug but since I haven't experienced this with any other installer I submit the bug anyway. It can't be my system by itself either. - Varying the installation options does not seem to help (non exhaustive testing done). - Running install on on specific processor (Hyper Threading is enabled) does not change things Test system summary (see attachment for full specs): Gigabyte 8KNXP motherboard, intel Northwood 3.0GHz HT, 2x512MB Corsair 3500, Radeon 9700 AIW, Seagate Barracuda 160GB, Windows XP Pro SP1a. Reproduction steps: 1. Launch installer 2. Click 'next' when asked for directory 3. Click 'next' when asked about backups 4. Click 'next' when asked for component selection 5. Click 'next' when asked for start menu group selection 6. Click 'next' when prompted with the "ready to install" screen 7. Observere bug ---------------------------------------------------------------------- >Comment By: Jens Olsson (morr) Date: 2003-12-10 12:38 Message: Logged In: YES user_id=917179 I couldn't update comments and didn't have time to figure out how I should do it so I hope this attached file will do. Follow up: I ran the installer with the suggested /m1 option. The install asked for the following directories (in order): windows system system32 temp source All input boxes had default values which seemed reasonable so I left them unchanged. Then the actual installer window showed (as without /m1). After submitting the requested information (as reported in the inital bugreport) the installer halted when the small window titled "installing" showed, at 1% and the file unwise.exe... just as before. No question about registring files (besides the five windows promting for manual input of directories as described above). No error messages. Just the same behaviour as before with some additional directory prompting dialoges at the beginning. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-12-05 20:49 Message: Logged In: YES user_id=11105 Here is advice I got from a Wise rep: """ This sounds like it is hanging at the point that the install is trying to self register files. You can test this by running the setup.exe with a /m1. This will run the install in manual mode, and prompt when each file is trying to self register. This will indicate which file it is trying to self register, and then the error message. """ Can you try this, please, and report the result? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-12-03 21:58 Message: Logged In: YES user_id=11105 I've asked in the WISE support news group for help, I've also seen similar behaviour in other software built with WISE. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848871&group_id=5470 From noreply at sourceforge.net Wed Dec 10 08:53:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 10 08:53:53 2003 Subject: [ python-Bugs-857566 ] tempfile.mktemp() omits pid from name Message-ID: Bugs item #857566, was opened at 2003-12-10 13:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857566&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gottfried Gan?auge (ganssauge) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile.mktemp() omits pid from name Initial Comment: In python2.2 names created using tempfile.mktemp() contained the current pid as a prefix. This behaviour has changed and now processes running concurrently are prone to races. 1.) In my application which forks a few thousand sub processes over time sometimes tempfiles created by one subprocess are deleted by another. 2.) Also this probably leads to longer creation times when two processes want to create a temp file at the same time on multiprocessor machines because both processes are using the same rng with the same seed to generate names. Sorry, no code here, because 1. happens only a few times when running with huge amounts of data and because 2. is only a speculation. I would propose to reinstate the former behaviour. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857566&group_id=5470 From noreply at sourceforge.net Wed Dec 10 09:04:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 10 09:04:57 2003 Subject: [ python-Bugs-857566 ] tempfile.mktemp() omits pid from name Message-ID: Bugs item #857566, was opened at 2003-12-10 14:53 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857566&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gottfried Gan?auge (ganssauge) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile.mktemp() omits pid from name Initial Comment: In python2.2 names created using tempfile.mktemp() contained the current pid as a prefix. This behaviour has changed and now processes running concurrently are prone to races. 1.) In my application which forks a few thousand sub processes over time sometimes tempfiles created by one subprocess are deleted by another. 2.) Also this probably leads to longer creation times when two processes want to create a temp file at the same time on multiprocessor machines because both processes are using the same rng with the same seed to generate names. Sorry, no code here, because 1. happens only a few times when running with huge amounts of data and because 2. is only a speculation. I would propose to reinstate the former behaviour. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-12-10 15:04 Message: Logged In: YES user_id=11105 mktemp() is deprecated in 2.3, to prevent exactly the problems you have. Read the docs, and use mkstemp() instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857566&group_id=5470 From noreply at sourceforge.net Wed Dec 10 09:17:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 10 09:17:20 2003 Subject: [ python-Bugs-857566 ] tempfile.mktemp() omits pid from name Message-ID: Bugs item #857566, was opened at 2003-12-10 13:53 Message generated for change (Comment added) made by ganssauge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857566&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gottfried Gan?auge (ganssauge) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile.mktemp() omits pid from name Initial Comment: In python2.2 names created using tempfile.mktemp() contained the current pid as a prefix. This behaviour has changed and now processes running concurrently are prone to races. 1.) In my application which forks a few thousand sub processes over time sometimes tempfiles created by one subprocess are deleted by another. 2.) Also this probably leads to longer creation times when two processes want to create a temp file at the same time on multiprocessor machines because both processes are using the same rng with the same seed to generate names. Sorry, no code here, because 1. happens only a few times when running with huge amounts of data and because 2. is only a speculation. I would propose to reinstate the former behaviour. ---------------------------------------------------------------------- >Comment By: Gottfried Gan?auge (ganssauge) Date: 2003-12-10 14:17 Message: Logged In: YES user_id=792746 This is no option. In our system we need to spawn another program which doesn't accept file handles but wants to have a filename instead. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-12-10 14:04 Message: Logged In: YES user_id=11105 mktemp() is deprecated in 2.3, to prevent exactly the problems you have. Read the docs, and use mkstemp() instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857566&group_id=5470 From noreply at sourceforge.net Wed Dec 10 10:49:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 10 10:50:04 2003 Subject: [ python-Bugs-827963 ] Registry key CurrentVersion not set Message-ID: Bugs item #827963, was opened at 2003-10-22 04:54 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827963&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jimm Domingo (jimm_domingo) >Assigned to: Nobody/Anonymous (nobody) Summary: Registry key CurrentVersion not set Initial Comment: According to the documentation for Python's use of the Windows registry, the version number of most recently installed version is in the key HKEY_LOCAL_MACHINE\Software\Python\PythonCore\CurrentVersion. But this key does not exist on my system. My configuration: Python 2.2.3 (#42, May 30 2003, 18:12:08) on Windows XP Professional, Version 2002, SP1. FWIW, I downloaded most recent revision (1.133.4.4) of the Wise installation script (python20.wse) from CVS. I then opened it with an evaluation copy of Wise Installation System. I've never used that product, but it appears that the above key isn't assigned a value. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-12-10 16:49 Message: Logged In: YES user_id=11105 I'm unassigning this, since I neither maintain the python.org web pages nor would I want to. I would suggest to either remove these pages completely, or mark them as hopefully outdated. ---------------------------------------------------------------------- Comment By: Jimm Domingo (jimm_domingo) Date: 2003-12-05 22:16 Message: Logged In: YES user_id=860120 The document "Python Registry" is at http://www.python.org/windows/python/registry.html The page "Python support for Windows" (http://www.python.org/windows/) has a link to that document, but it is classified as an old link. Seems to confirm your thinking that the documentation no longer describes the way things are done. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-12-05 21:52 Message: Logged In: YES user_id=11105 I think this is a documentation bug. Can you point me to where it is documented? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827963&group_id=5470 From noreply at sourceforge.net Wed Dec 10 10:51:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 10 10:51:35 2003 Subject: [ python-Feature Requests-582728 ] py-find-module for python-mode.el Message-ID: Feature Requests item #582728, was opened at 2002-07-17 10:42 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=582728&group_id=5470 Category: Demos and Tools Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Barry A. Warsaw (bwarsaw) Summary: py-find-module for python-mode.el Initial Comment: I would like a function that finds and opens a python module (or submodule) in the standard python search path. I have an implementation which shells out to python to find the library, print the filename, and lets emacs capture the output and load the file, but only because I don't know how to do it in elisp. This function could probably look for the symbol near the point and use this as the module name to search for if called interactively. If needed, I can upload the code I have. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-12-10 16:51 Message: Logged In: YES user_id=11105 Some day I'll either do this myself or request a feature in the python-mode project. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-07-17 10:59 Message: Logged In: YES user_id=11105 Uploaded my files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=582728&group_id=5470 From noreply at sourceforge.net Wed Dec 10 10:56:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 10 10:56:15 2003 Subject: [ python-Bugs-857566 ] tempfile.mktemp() omits pid from name Message-ID: Bugs item #857566, was opened at 2003-12-10 14:53 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857566&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gottfried Gan?auge (ganssauge) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile.mktemp() omits pid from name Initial Comment: In python2.2 names created using tempfile.mktemp() contained the current pid as a prefix. This behaviour has changed and now processes running concurrently are prone to races. 1.) In my application which forks a few thousand sub processes over time sometimes tempfiles created by one subprocess are deleted by another. 2.) Also this probably leads to longer creation times when two processes want to create a temp file at the same time on multiprocessor machines because both processes are using the same rng with the same seed to generate names. Sorry, no code here, because 1. happens only a few times when running with huge amounts of data and because 2. is only a speculation. I would propose to reinstate the former behaviour. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-12-10 16:56 Message: Logged In: YES user_id=11105 Well, you could close the file (or even remove it, depending on your requirements), and pass the filename to the spawned program. Or, if you insist on using mktemp(), pass a prefix argument yourself? But I'm not really sure if this is what you need, so this is my last comment. ---------------------------------------------------------------------- Comment By: Gottfried Gan?auge (ganssauge) Date: 2003-12-10 15:17 Message: Logged In: YES user_id=792746 This is no option. In our system we need to spawn another program which doesn't accept file handles but wants to have a filename instead. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-12-10 15:04 Message: Logged In: YES user_id=11105 mktemp() is deprecated in 2.3, to prevent exactly the problems you have. Read the docs, and use mkstemp() instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857566&group_id=5470 From noreply at sourceforge.net Wed Dec 10 11:21:55 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 10 11:21:59 2003 Subject: [ python-Bugs-857676 ] RE engine internal error with LARGE RE: scalability bug Message-ID: Bugs item #857676, was opened at 2003-12-10 17:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857676&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Francisco Dellatorre Borges (fdborges) Assigned to: Fredrik Lundh (effbot) Summary: RE engine internal error with LARGE RE: scalability bug Initial Comment: I lot's of lines with the format: (d+@w[^|]+|)+ I'll call the last bit after the @ of /features/. I need to delete some of these, so I have this code that would produce a list matching what I would /not/ use, pass it over re.escape and them build a re using a concatenation of the list and delete this from the text before actually doing any parsing. Problem is: I have about 220.000 different features and I need to delete some 200.000 different ones from my files before doing something. So I tried to use a list of the 20.000 I want and then delete anything that matches the of it: #--------------- # ftrlist is the stuff I *want* to keep: ftrlist = [re.escape(i) for i in ftrlist ] re.compile(r'(?!(%s))' %( '|'.join(ftrlist)) ) #-------------- but when I apply it I get something like: RuntimeError: internal error in regular expression engine I tried the same thing but with a smaller number of elements, say 1000 ftrlist[:1000], and then it worked. So I guess there is a bug on the scalability of the re engine when doing alternative searches. Attached I'm sending a tar ball that reproduces this. I'm gzipping it (hope sourceforge does not have a problem with the resulting binary file). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857676&group_id=5470 From noreply at sourceforge.net Wed Dec 10 11:24:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 10 11:24:49 2003 Subject: [ python-Bugs-857676 ] RE engine internal error with LARGE RE: scalability bug Message-ID: Bugs item #857676, was opened at 2003-12-10 17:21 Message generated for change (Comment added) made by fdborges You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857676&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Francisco Dellatorre Borges (fdborges) Assigned to: Fredrik Lundh (effbot) Summary: RE engine internal error with LARGE RE: scalability bug Initial Comment: I lot's of lines with the format: (d+@w[^|]+|)+ I'll call the last bit after the @ of /features/. I need to delete some of these, so I have this code that would produce a list matching what I would /not/ use, pass it over re.escape and them build a re using a concatenation of the list and delete this from the text before actually doing any parsing. Problem is: I have about 220.000 different features and I need to delete some 200.000 different ones from my files before doing something. So I tried to use a list of the 20.000 I want and then delete anything that matches the of it: #--------------- # ftrlist is the stuff I *want* to keep: ftrlist = [re.escape(i) for i in ftrlist ] re.compile(r'(?!(%s))' %( '|'.join(ftrlist)) ) #-------------- but when I apply it I get something like: RuntimeError: internal error in regular expression engine I tried the same thing but with a smaller number of elements, say 1000 ftrlist[:1000], and then it worked. So I guess there is a bug on the scalability of the re engine when doing alternative searches. Attached I'm sending a tar ball that reproduces this. I'm gzipping it (hope sourceforge does not have a problem with the resulting binary file). ---------------------------------------------------------------------- >Comment By: Francisco Dellatorre Borges (fdborges) Date: 2003-12-10 17:24 Message: Logged In: YES user_id=576554 Problem with the file name the first time. Here is the file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857676&group_id=5470 From noreply at sourceforge.net Wed Dec 10 11:31:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 10 11:31:48 2003 Subject: [ python-Bugs-857676 ] RE engine internal error with LARGE RE: scalability bug Message-ID: Bugs item #857676, was opened at 2003-12-10 17:21 Message generated for change (Comment added) made by fdborges You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857676&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Francisco Dellatorre Borges (fdborges) Assigned to: Fredrik Lundh (effbot) Summary: RE engine internal error with LARGE RE: scalability bug Initial Comment: I lot's of lines with the format: (d+@w[^|]+|)+ I'll call the last bit after the @ of /features/. I need to delete some of these, so I have this code that would produce a list matching what I would /not/ use, pass it over re.escape and them build a re using a concatenation of the list and delete this from the text before actually doing any parsing. Problem is: I have about 220.000 different features and I need to delete some 200.000 different ones from my files before doing something. So I tried to use a list of the 20.000 I want and then delete anything that matches the of it: #--------------- # ftrlist is the stuff I *want* to keep: ftrlist = [re.escape(i) for i in ftrlist ] re.compile(r'(?!(%s))' %( '|'.join(ftrlist)) ) #-------------- but when I apply it I get something like: RuntimeError: internal error in regular expression engine I tried the same thing but with a smaller number of elements, say 1000 ftrlist[:1000], and then it worked. So I guess there is a bug on the scalability of the re engine when doing alternative searches. Attached I'm sending a tar ball that reproduces this. I'm gzipping it (hope sourceforge does not have a problem with the resulting binary file). ---------------------------------------------------------------------- >Comment By: Francisco Dellatorre Borges (fdborges) Date: 2003-12-10 17:31 Message: Logged In: YES user_id=576554 apparently sf does not want me to load tar balls... or I'm too dumb to do it. ---------------------------------------------------------------------- Comment By: Francisco Dellatorre Borges (fdborges) Date: 2003-12-10 17:24 Message: Logged In: YES user_id=576554 Problem with the file name the first time. Here is the file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857676&group_id=5470 From noreply at sourceforge.net Wed Dec 10 11:35:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 10 11:35:25 2003 Subject: [ python-Bugs-857676 ] RE engine internal error with LARGE RE: scalability bug Message-ID: Bugs item #857676, was opened at 2003-12-10 17:21 Message generated for change (Comment added) made by fdborges You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857676&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Francisco Dellatorre Borges (fdborges) Assigned to: Fredrik Lundh (effbot) Summary: RE engine internal error with LARGE RE: scalability bug Initial Comment: I lot's of lines with the format: (d+@w[^|]+|)+ I'll call the last bit after the @ of /features/. I need to delete some of these, so I have this code that would produce a list matching what I would /not/ use, pass it over re.escape and them build a re using a concatenation of the list and delete this from the text before actually doing any parsing. Problem is: I have about 220.000 different features and I need to delete some 200.000 different ones from my files before doing something. So I tried to use a list of the 20.000 I want and then delete anything that matches the of it: #--------------- # ftrlist is the stuff I *want* to keep: ftrlist = [re.escape(i) for i in ftrlist ] re.compile(r'(?!(%s))' %( '|'.join(ftrlist)) ) #-------------- but when I apply it I get something like: RuntimeError: internal error in regular expression engine I tried the same thing but with a smaller number of elements, say 1000 ftrlist[:1000], and then it worked. So I guess there is a bug on the scalability of the re engine when doing alternative searches. Attached I'm sending a tar ball that reproduces this. I'm gzipping it (hope sourceforge does not have a problem with the resulting binary file). ---------------------------------------------------------------------- >Comment By: Francisco Dellatorre Borges (fdborges) Date: 2003-12-10 17:35 Message: Logged In: YES user_id=576554 Ok, I give up on loading the file the size is restricted as one might have expected. If you want download the tar ball that would reproduce the error from www.let.rug.nl/~borges/ScalabilityREBug.tar.gz ---------------------------------------------------------------------- Comment By: Francisco Dellatorre Borges (fdborges) Date: 2003-12-10 17:31 Message: Logged In: YES user_id=576554 apparently sf does not want me to load tar balls... or I'm too dumb to do it. ---------------------------------------------------------------------- Comment By: Francisco Dellatorre Borges (fdborges) Date: 2003-12-10 17:24 Message: Logged In: YES user_id=576554 Problem with the file name the first time. Here is the file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857676&group_id=5470 From noreply at sourceforge.net Wed Dec 10 16:16:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 10 16:16:45 2003 Subject: [ python-Bugs-857857 ] pprint should handle subtypes of dict/list/tuple Message-ID: Bugs item #857857, was opened at 2003-12-10 16:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857857&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: pprint should handle subtypes of dict/list/tuple Initial Comment: I often implement subclasses of dict, list, tuple, etc and it's annoying that I can't use pprint on them. I suggest that instead of using this pattern: type(something) is dict it should use: type(something).__repr__ is dict.__repr__ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857857&group_id=5470 From noreply at sourceforge.net Wed Dec 10 17:00:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 10 17:00:56 2003 Subject: [ python-Bugs-857881 ] ConfigParser bug Message-ID: Bugs item #857881, was opened at 2003-12-10 17:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857881&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michel Martin (mrsmile) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser bug Initial Comment: Python Version: 2.3.2c1 OS: Windows 2000 ----------------------- Hello, I was trying to use the ConfigParser provided with Python when I realized that there is a problem with the case in the string passed in the Interpolation feature. Explicitely, test1 works but test2 doesn't. You can see by yourself with the attachment. =========================== [Test1] logFullPath: c:/logs/%(logfilename)s logFilename=test.log [Test2] logFullPath: c:/logs/%(logFilename)s logFilename=test.log =========================== Using a capital letter in %('string')s doesn't work, even if the key is declared with a capital letter. How could we fix this? Thanks for your help, Best regards, Michel Martin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857881&group_id=5470 From noreply at sourceforge.net Wed Dec 10 17:11:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 10 17:11:21 2003 Subject: [ python-Bugs-857888 ] Modules/Setup needs a suppress flag? Message-ID: Bugs item #857888, was opened at 2003-12-10 17:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857888&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: Modules/Setup needs a suppress flag? Initial Comment: Could there be a keyword in Modules/Setup to say 'Don't even try to build the following modules?' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857888&group_id=5470 From noreply at sourceforge.net Wed Dec 10 17:41:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 10 17:41:38 2003 Subject: [ python-Bugs-857909 ] bsddb craps out sporadically Message-ID: Bugs item #857909, was opened at 2003-12-10 12:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857909&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Predrag Miocinovic (predragm) Assigned to: Nobody/Anonymous (nobody) Summary: bsddb craps out sporadically Initial Comment: I get following from Python2.3.2 with BerkeleyDB 3.3.11 running on linux RH7.3; ------------------------ Traceback (most recent call last): File "/raid/ANITA-lite/gse/unpackd.py", line 702, in ? PacketObject.shelve() File "/raid/ANITA-lite/gse/unpackd.py", line 78, in shelve wvShelf[shelfKey] = self File "/usr/local/lib/python2.3/shelve.py", line 130, in __setitem__ self.dict[key] = f.getvalue() File "/usr/local/lib/python2.3/bsddb/__init__.py", line 120, in __setitem__ self.db[key] = value bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: Invalid argument') Exception bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery') in ignored Exception bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery') in ignored ---------------------------------- The server reporting this is running at relatively heavy load and the error occurs several times per day (this call occurs roughly 100,000 per day, but only 42 times per any given shelve instance). It reminds be of bug report #775414, but this is a non-threaded application. That said, another process is accessing the same shelve, but I've implemented a lockout system which should make sure they don't have simultaneous access. The lockout seems to work fine. The same application is running on different machine using Python2.3.2 with BerkeleyDB 4.0.14 on linux RH9 and the same error occured once (to my knowledge), but with "30987" replaced by "30981" in the traceback above, if it makes any difference. Finally, a third system, python2.3.2 with BerkeleyDB 4.0.14 on linux RH9 (but quite a bit faster, and thus lighter load) runs w/o reporting this problem so far. I don't have a convenient code snipet to exemplify the problem, but I don't do anything more than open (or re-open) a shelve and write a single python object instance to it per opening. If necessary, I can provide the code in question. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857909&group_id=5470 From noreply at sourceforge.net Wed Dec 10 22:13:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 10 22:13:08 2003 Subject: [ python-Bugs-858016 ] Pathological case segmentation fault Message-ID: Bugs item #858016, was opened at 2003-12-10 21:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Eric M. Hopper (omnifarious) Assigned to: Nobody/Anonymous (nobody) Summary: Pathological case segmentation fault Initial Comment: This works for the PowerPC Python compiled with gcc 3.3 on OS X using fink. I suspect it's broader based than that, but I don't have the ability to check properly. Here's how to make it segment fault: x = (basestring,) for i in xrange(0, 1000000): x = (x,) issubclass(str, x) At least, it segment faults at the interactive prompt this way. I don't know if it does when it's executed from a file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470 From noreply at sourceforge.net Wed Dec 10 22:16:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 10 22:17:06 2003 Subject: [ python-Bugs-858016 ] Pathological case segmentation fault in issubclass Message-ID: Bugs item #858016, was opened at 2003-12-10 21:13 Message generated for change (Comment added) made by omnifarious You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Eric M. Hopper (omnifarious) Assigned to: Nobody/Anonymous (nobody) >Summary: Pathological case segmentation fault in issubclass Initial Comment: This works for the PowerPC Python compiled with gcc 3.3 on OS X using fink. I suspect it's broader based than that, but I don't have the ability to check properly. Here's how to make it segment fault: x = (basestring,) for i in xrange(0, 1000000): x = (x,) issubclass(str, x) At least, it segment faults at the interactive prompt this way. I don't know if it does when it's executed from a file. ---------------------------------------------------------------------- >Comment By: Eric M. Hopper (omnifarious) Date: 2003-12-10 21:16 Message: Logged In: YES user_id=313 I forgot this: Python 2.3.2 (#1, Dec 4 2003, 09:13:58) [GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin Type "help", "copyright", "credits" or "license" for more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470 From noreply at sourceforge.net Wed Dec 10 23:28:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 10 23:28:10 2003 Subject: [ python-Bugs-858016 ] Pathological case segmentation fault in issubclass Message-ID: Bugs item #858016, was opened at 2003-12-10 19:13 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Eric M. Hopper (omnifarious) Assigned to: Nobody/Anonymous (nobody) Summary: Pathological case segmentation fault in issubclass Initial Comment: This works for the PowerPC Python compiled with gcc 3.3 on OS X using fink. I suspect it's broader based than that, but I don't have the ability to check properly. Here's how to make it segment fault: x = (basestring,) for i in xrange(0, 1000000): x = (x,) issubclass(str, x) At least, it segment faults at the interactive prompt this way. I don't know if it does when it's executed from a file. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-12-10 20:28 Message: Logged In: YES user_id=357491 If you look at Object/abstract.c (line 2119 or so) for 2.4 CVS you will notice that PyObject_IsSubclass goes into a 'for' loop for each item in the tuple passed in and calls PyObject_IsSubclass . Unfortunately it makes no check for whether the argument it is passing is a class itself or not. This allows it to keep making calls as long as the second argument is either a class or a tuple. This is what is leads to the stack being blown and the subsequent segfault. Obvious solution is to put in a check that the argument about to be passed is a class itself so as to not have such a deep call chain. But since ``help(issubclass)`` actually makes the above use legit (it says using a tuple as a second argument is equivalent as passing each item to issubclass which is what it is doing, albeit in a rather uncommon and pointless way), is it worth putting the check in? Since this is such an obvious mis-use, I say no. But if someone else on python-dev steps in and says otherwise I will patch it. ---------------------------------------------------------------------- Comment By: Eric M. Hopper (omnifarious) Date: 2003-12-10 19:16 Message: Logged In: YES user_id=313 I forgot this: Python 2.3.2 (#1, Dec 4 2003, 09:13:58) [GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin Type "help", "copyright", "credits" or "license" for more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470 From noreply at sourceforge.net Wed Dec 10 23:28:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 10 23:28:52 2003 Subject: [ python-Feature Requests-857888 ] Modules/Setup needs a suppress flag? Message-ID: Feature Requests item #857888, was opened at 2003-12-10 14:11 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=857888&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: Modules/Setup needs a suppress flag? Initial Comment: Could there be a keyword in Modules/Setup to say 'Don't even try to build the following modules?' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=857888&group_id=5470 From noreply at sourceforge.net Wed Dec 10 23:33:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 10 23:33:28 2003 Subject: [ python-Bugs-857821 ] Remove notion of deprecated string.{atol, atof} functions Message-ID: Bugs item #857821, was opened at 2003-12-10 12:08 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857821&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Remove notion of deprecated string.{atol,atof} functions Initial Comment: In the documentation of the builtin functions long and float, a mention was made of the functions atof and atol in the string module: string.atof and string.atol. Since these have been deprecated for a long time, this is incorrect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857821&group_id=5470 From noreply at sourceforge.net Thu Dec 11 05:29:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 05:29:38 2003 Subject: [ python-Bugs-857566 ] tempfile.mktemp() omits pid from name Message-ID: Bugs item #857566, was opened at 2003-12-10 13:53 Message generated for change (Comment added) made by ganssauge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857566&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gottfried Gan?auge (ganssauge) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile.mktemp() omits pid from name Initial Comment: In python2.2 names created using tempfile.mktemp() contained the current pid as a prefix. This behaviour has changed and now processes running concurrently are prone to races. 1.) In my application which forks a few thousand sub processes over time sometimes tempfiles created by one subprocess are deleted by another. 2.) Also this probably leads to longer creation times when two processes want to create a temp file at the same time on multiprocessor machines because both processes are using the same rng with the same seed to generate names. Sorry, no code here, because 1. happens only a few times when running with huge amounts of data and because 2. is only a speculation. I would propose to reinstate the former behaviour. ---------------------------------------------------------------------- >Comment By: Gottfried Gan?auge (ganssauge) Date: 2003-12-11 10:29 Message: Logged In: YES user_id=792746 It is already hard to keep a system working in a changing world, so I see no necessity to needlessly introduce incompatibilities. Your comments are apreciated nonetheless. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-12-10 15:56 Message: Logged In: YES user_id=11105 Well, you could close the file (or even remove it, depending on your requirements), and pass the filename to the spawned program. Or, if you insist on using mktemp(), pass a prefix argument yourself? But I'm not really sure if this is what you need, so this is my last comment. ---------------------------------------------------------------------- Comment By: Gottfried Gan?auge (ganssauge) Date: 2003-12-10 14:17 Message: Logged In: YES user_id=792746 This is no option. In our system we need to spawn another program which doesn't accept file handles but wants to have a filename instead. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-12-10 14:04 Message: Logged In: YES user_id=11105 mktemp() is deprecated in 2.3, to prevent exactly the problems you have. Read the docs, and use mkstemp() instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857566&group_id=5470 From noreply at sourceforge.net Thu Dec 11 06:40:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 06:40:55 2003 Subject: [ python-Bugs-857857 ] pprint should handle subtypes of dict/list/tuple Message-ID: Bugs item #857857, was opened at 2003-12-10 22:16 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857857&group_id=5470 Category: Python Library Group: Feature Request >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: pprint should handle subtypes of dict/list/tuple Initial Comment: I often implement subclasses of dict, list, tuple, etc and it's annoying that I can't use pprint on them. I suggest that instead of using this pattern: type(something) is dict it should use: type(something).__repr__ is dict.__repr__ ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2003-12-11 12:40 Message: Logged In: YES user_id=89016 This is a duplicate of http://www.python.org/sf/750542. In Python 2.4 subclasses of dict/list/tuple will be pretty printed as long as they don't overwrite __repr__. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857857&group_id=5470 From noreply at sourceforge.net Thu Dec 11 07:14:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 07:14:26 2003 Subject: [ python-Bugs-549081 ] test_signal hangs -- signal broken on OpenBSD? Message-ID: Bugs item #549081, was opened at 2002-04-26 13:54 Message generated for change (Comment added) made by frallan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549081&group_id=5470 Category: Installation Group: Python 2.2.1 candidate Status: Open Resolution: None Priority: 5 Submitted By: Noah Spurrier (noah) Assigned to: Nobody/Anonymous (nobody) Summary: test_signal hangs -- signal broken on OpenBSD? Initial Comment: This appears to be similar to bug as PR#288, [ 210635 ] test_signal hangs when running as part of testall (PR#288) except that I have this problem on a fresh install of OpenBSD 3.0 while trying to build Python-2.2.1. I did a generic build running as root: ./configure ./make ./make test Yours, Noah ---------------------------------------------------------------------- Comment By: Frallan the master Jedi (frallan) Date: 2003-12-11 12:14 Message: Logged In: YES user_id=639616 My test program now works. It both terminates and prints the 'got signal' message. Current Platform is: OpenBSD somewhere 3.3 GENERIC#44 i386 Python 2.3.2 (#1, Dec 1 2003, 11:20:01) [GCC 2.95.3 20010125 (prerelease, propolice)] on openbsd3 I should receive my OpenBSD 3.4 CDs soon. Then I'll test that too. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-31 10:49 Message: Logged In: YES user_id=6656 As far as I am aware (not very) Python signals have always been broken on OpenBSD. None of the Python core developers use OpenBSD, though, so it's always remained a mystery. frallan, does the C equivalent of your Python test work? Do you have any idea what Python (or OpenBSD, maybe) is doing wrong? signals are pain. ---------------------------------------------------------------------- Comment By: Frallan the master Jedi (frallan) Date: 2002-10-31 09:48 Message: Logged In: YES user_id=639616 I get the exact same behavior on OpenBSD 3.1 with Python- 2.2.2. Also this simple test program from the "Python Standard Library" book - fails. The program terminates but the "got signal" message is never printed. import signal import time def handler (signo, frame): print 'got signal', signo signal.signal(signal.SIGALRM, handler) # wake me up in two seconds signal.alarm(2) now = time.time() time.sleep(200) print 'slept for', time.time() - now, "seconds" ---------------------------------------------------------------------- Comment By: Noah Spurrier (noah) Date: 2002-04-27 15:40 Message: Logged In: YES user_id=59261 Below is the output of test_signal.py. I ran it manually. I modified it slightly to print out the pid; the return values from the signal calls; and to print a count of the loop iteration (starting at 1). You can see that after Count 4 it just sits there. After about a minute I hit Ctrl- Z. I have uploaded the modified version of test_signal.py. ... bash-2.05# python test_signal.py pid: 8606 signal.alarm(20): 0 signal.signal(5, handlerA): 0 signal.signal(2, handlerB): signal.signal(3, signal.SIG_IGN): 0 signal.signal(signal.SIGALRM, signal.default_int_handler): 0 starting pause() loop... + sleep 2 count: 1 call pause()... + kill -5 8606 pause() returned + sleep 2 count: 2 call pause()... + kill -2 8606 pause() returned + sleep 2 count: 3 call pause()... + kill -3 8606 pause() returned count: 4 call pause()... ^Z [1]+ Stopped python test_signal.py bash-2.05# ps -p 8606 PID TT STAT TIME COMMAND 8606 p0 T 0:00.09 python test_signal.py bash-2.05# uname -a OpenBSD nobot 3.0 GENERIC#94 i386 bash-2.05# python Python 2.2.1 (#4, Apr 26 2002, 23:06:40) [GCC 2.95.3 20010125 (prerelease)] on openbsd3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549081&group_id=5470 From noreply at sourceforge.net Thu Dec 11 08:12:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 08:12:27 2003 Subject: [ python-Bugs-858253 ] EAGAIN when sys.stdin.readline() Message-ID: Bugs item #858253, was opened at 2003-12-11 13:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858253&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Frallan the master Jedi (frallan) Assigned to: Nobody/Anonymous (nobody) Summary: EAGAIN when sys.stdin.readline() Initial Comment: $ cat test.py import sys print sys.stdin.readline() $ python test.py | python test.py Traceback (most recent call last): File "test.py", line 2, in ? print sys.stdin.readline() IOError: [Errno 35] Resource temporarily unavailable This happens about 3 times out of 5. It happens under FreeBSD 5.1-RELEASE (SMP) and: python-2.1.3 python-2.2.3 python-2.3.2 python-2.3.3c1 It does _not_ happen under Debian 3.0 or FreeBSD 4.7-RELEASE (SMP). According to read(2) this "error" should occur only when the descriptor is in non-blocking mode. However as you can see from the program it isn't. Further I have caught the IOError and run fcntl(F_GETFL) on sys.stdin.fileno() and the only flag set is O_RDWR. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858253&group_id=5470 From noreply at sourceforge.net Thu Dec 11 08:42:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 08:42:18 2003 Subject: [ python-Bugs-852532 ] ^$ won't split on empty line Message-ID: Bugs item #852532, was opened at 2003-12-02 12:01 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852532&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open >Resolution: Postponed Priority: 5 Submitted By: Jan Burgy (jburgy) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ^$ won't split on empty line Initial Comment: Python 2.3.2 (#49, Oct 2 2003, 20:02:00) [MSC v.1200 32 bit (Intel)] on win32 >>> import re >>> re.compile('^$', re.MULTILINE).split('foo\n\nbar') ['foo\n\nbar'] I expect ['foo\n', '\nbar'], since, according to the documentation $ "in MULTILINE mode also matches before a newline". Thanks, Jan ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2003-12-11 14:42 Message: Logged In: YES user_id=38376 Split never splits on empty substrings; see Tim's answer for a brief discussion. Fred, can you perhaps add something to the documentation? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-12-02 16:20 Message: Logged In: YES user_id=31435 Confirmed on Pythons 2.1.3, 2.2.3, 2.3.2, and current CVS. More generally, split() doesn't appear to split on any empty (0-length) match. For example, >>> pat = re.compile(r'\b') >>> pat.split('(a b)') ['(a b)'] >>> pat.findall('(a b)') # but the pattern matches 4 places ['', '', '', ''] >>> That's probably a design constraint, but isn't documented. For example, if you split "abc" by the pattern x*, what do you expect? The pattern matches (with length 0) at 4 places, but I bet most people would be surprised to get ['', 'a', 'b', 'c', ''] back instead of (as they do get) ['abc'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852532&group_id=5470 From noreply at sourceforge.net Thu Dec 11 08:43:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 08:43:58 2003 Subject: [ python-Bugs-753711 ] Infinite Loop in RE Message-ID: Bugs item #753711, was opened at 2003-06-13 05:27 Message generated for change (Settings changed) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753711&group_id=5470 Category: Regular Expressions Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix >Priority: 3 Submitted By: Matthew Bogosian (mbogosian) Assigned to: Fredrik Lundh (effbot) Summary: Infinite Loop in RE Initial Comment: This *may* be similar to , but I don't think the current behavior (infinite loop/unbound execution) is correct. Here's the python version: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - #!/usr/bin/python import re pattern = '^UPDATE\s+\w+\s+SET\s+locked_until\s*=\s*(\S+\s*)+,' # This won't match (missing ',' at end str = 'UPDATE arena_teams SET locked_until = CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP)' re.search(pattern, str, re.I) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - When run, this script just pegs the CPU and hangs (I'm running RedHat 8.0). Note: if I change the pattern slightly it still doesn't work: pattern = '^UPDATE\s+\w+\s+SET\s+locked_until\s*=\s*([^ =,]+\s*)+,' It's not until the pattern actually matches that things get better (with both the original and modified patterns): # Pattern now matches (added a ',' at the end) str = 'UPDATE arena_teams SET locked_until = CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP),' I tried doing the same thing in Perl: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - #!/usr/bin/perl 'UPDATE arena_teams SET locked_until = CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP)' =~ '/UPDATE\s+\w+\s+SET\s+locked_until\s*=\s*(\S+\s*)+,/i'; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This of course runs just fine. Any ideas? ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2003-06-16 20:44 Message: Logged In: YES user_id=86307 FWIW, one way to efficiently match this sort of pattern (where you have literal text at the end of something complex) would be to use the match once and don't backtrack operator ('(?>pattern)'). SRE doesn't have the (?> operator, but it can be emulated by '(?=(pattern))\1'. So one way to avoid the exponential time would be to use something like this: rx = re.compile( r'''^UPDATE\s+\w+\s+SET\s+locked_until\s*=\s* (?=( ([^=,]+\s*)+ ))\1 , #trailing literal ''', re.I | re.X ) By the way, it would be fairly easy to add the (?> operator to SRE; it's almost identical to a postive lookahead assertion. The only difference is that, upon successfully matching the subexpression inside the parentheses, the position in the string being matched is advanced to the end of the text matched by the subexpression. Also, in case anyone's interested in why Perl is able to fail so quickly here, it appears that the Perl engine keeps track of positions (in the target text) where something like '(pattern)+' has already been tried and has failed, so it can quickly fail if backtracking causes an attempt to match again at that position (at least that's my interpretation of the numerous "already tried at this position..." messages in the trace from running the supplied pattern and text with "use re 'debug';"). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-15 06:28 Message: Logged In: YES user_id=357491 sjones is right about it taking exponential time. A regex engine works with greedy quantifiers by sucking up all that it can and then trying the next part of the regex and continues until it fails or succeeds. If it fails, though, it backtracks one regex character, gives up a character it claimed, and tries again. It does this for a long time. How long did you wait for the regex to complete? I bet if you left it for a *very* long time it would complete. ---------------------------------------------------------------------- Comment By: Shannon Jones (sjones) Date: 2003-06-13 23:42 Message: Logged In: YES user_id=589306 If you change your regex and sample data to the following simpler forms, you get the same problem: pattern = '(\S+\s*)+,' str = 'CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP)' If you remove some letters from str, the search does finish but it takes several seconds. I believe the problem is that your regex takes exponential time to execute based on the length of str. Here is a recent python-dev post that talks about the problem: http://mail.python.org/pipermail/python-dev/2003-May/035916.html The link you provided in the bug report talks about this as well. You can also do a web search for "regular expression exponential" to see more information. I believe that any regex engine (that has similar features to Python's engine) will have some regular expressions that take exponential time or space. Perl has some cases as well (search for "exponential" in perldoc perlre). This is just how regular expressions are and IMHO does not indicate a bug in Python. As far as how to fix the regular expression, I can't say. I'm sure there is a way to "rephrase" what you want to get it to work. Maybe try asking in the comp.lang.python newsgroup. Good luck! ---------------------------------------------------------------------- Comment By: Shannon Jones (sjones) Date: 2003-06-13 14:15 Message: Logged In: YES user_id=589306 If you change your regex and sample data to the following simpler forms, you get the same problem: pattern = '(\S+\s*)+,' str = 'CAST(EXTRACT(EPOCH FROM CURRENT_TIMESTAMP)' If you remove some letters from str, the search does finish but it takes several seconds. I believe the problem is that your regex takes exponential time to execute based on the length of str. Here is a recent python-dev post that talks about the problem: http://mail.python.org/pipermail/python-dev/2003-May/035916.html The link you provided in the bug report talks about this as well. You can also do a web search for "regular expression exponential" to see more information. I believe that any regex engine (that has similar features to Python's engine) will have some regular expressions that take exponential time or space. Perl has some cases as well (search for "exponential" in perldoc perlre). This is just how regular expressions are and IMHO does not indicate a bug in Python. As far as how to fix the regular expression, I can't say. I'm sure there is a way to "rephrase" what you want to get it to work. Maybe try asking in the comp.lang.python newsgroup. Good luck! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753711&group_id=5470 From noreply at sourceforge.net Thu Dec 11 08:39:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 12:02:38 2003 Subject: [ python-Bugs-857676 ] RE engine internal error with LARGE RE: scalability bug Message-ID: Bugs item #857676, was opened at 2003-12-10 17:21 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857676&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None >Priority: 3 Submitted By: Francisco Dellatorre Borges (fdborges) Assigned to: Fredrik Lundh (effbot) Summary: RE engine internal error with LARGE RE: scalability bug Initial Comment: I lot's of lines with the format: (d+@w[^|]+|)+ I'll call the last bit after the @ of /features/. I need to delete some of these, so I have this code that would produce a list matching what I would /not/ use, pass it over re.escape and them build a re using a concatenation of the list and delete this from the text before actually doing any parsing. Problem is: I have about 220.000 different features and I need to delete some 200.000 different ones from my files before doing something. So I tried to use a list of the 20.000 I want and then delete anything that matches the of it: #--------------- # ftrlist is the stuff I *want* to keep: ftrlist = [re.escape(i) for i in ftrlist ] re.compile(r'(?!(%s))' %( '|'.join(ftrlist)) ) #-------------- but when I apply it I get something like: RuntimeError: internal error in regular expression engine I tried the same thing but with a smaller number of elements, say 1000 ftrlist[:1000], and then it worked. So I guess there is a bug on the scalability of the re engine when doing alternative searches. Attached I'm sending a tar ball that reproduces this. I'm gzipping it (hope sourceforge does not have a problem with the resulting binary file). ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2003-12-11 14:39 Message: Logged In: YES user_id=38376 The SRE engine is usually compiled with 16-bit opcodes, which places a limit on the size of the compiled engine. Changing that to 32 bits might solve your problem... But in this case, I don't think one huge RE is really the best tool for the task; it's as easy (and much more efficient) to use an RE to *extract* the feature code, and use a dictionary to keep track of the ones you want to keep. (example: use re.sub("d+@(w[^|]+)|", callback, data) and let the callback look m.group(1) up in the dictionary; return m.group(0) if you want to keep the feature, "" if you don't). Hope this helps! ---------------------------------------------------------------------- Comment By: Francisco Dellatorre Borges (fdborges) Date: 2003-12-10 17:35 Message: Logged In: YES user_id=576554 Ok, I give up on loading the file the size is restricted as one might have expected. If you want download the tar ball that would reproduce the error from www.let.rug.nl/~borges/ScalabilityREBug.tar.gz ---------------------------------------------------------------------- Comment By: Francisco Dellatorre Borges (fdborges) Date: 2003-12-10 17:31 Message: Logged In: YES user_id=576554 apparently sf does not want me to load tar balls... or I'm too dumb to do it. ---------------------------------------------------------------------- Comment By: Francisco Dellatorre Borges (fdborges) Date: 2003-12-10 17:24 Message: Logged In: YES user_id=576554 Problem with the file name the first time. Here is the file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857676&group_id=5470 From noreply at sourceforge.net Thu Dec 11 12:54:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 12:54:40 2003 Subject: [ python-Bugs-858016 ] Pathological case segmentation fault in issubclass Message-ID: Bugs item #858016, was opened at 2003-12-10 21:13 Message generated for change (Comment added) made by omnifarious You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Eric M. Hopper (omnifarious) Assigned to: Nobody/Anonymous (nobody) Summary: Pathological case segmentation fault in issubclass Initial Comment: This works for the PowerPC Python compiled with gcc 3.3 on OS X using fink. I suspect it's broader based than that, but I don't have the ability to check properly. Here's how to make it segment fault: x = (basestring,) for i in xrange(0, 1000000): x = (x,) issubclass(str, x) At least, it segment faults at the interactive prompt this way. I don't know if it does when it's executed from a file. ---------------------------------------------------------------------- >Comment By: Eric M. Hopper (omnifarious) Date: 2003-12-11 11:54 Message: Logged In: YES user_id=313 Well, I think any case where the system segment faults unexpectedly is bad, regardless of how pathological it is. Personally, I think that issubclass should either have a recursion limit after which it throws an exception, or it shouldn't go into sub-tuples at all. The reason I made this test is that I read the description of the behavior of issublcass and found it rather strange, so I decided to push it to see how far it would go. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-12-10 22:28 Message: Logged In: YES user_id=357491 If you look at Object/abstract.c (line 2119 or so) for 2.4 CVS you will notice that PyObject_IsSubclass goes into a 'for' loop for each item in the tuple passed in and calls PyObject_IsSubclass . Unfortunately it makes no check for whether the argument it is passing is a class itself or not. This allows it to keep making calls as long as the second argument is either a class or a tuple. This is what is leads to the stack being blown and the subsequent segfault. Obvious solution is to put in a check that the argument about to be passed is a class itself so as to not have such a deep call chain. But since ``help(issubclass)`` actually makes the above use legit (it says using a tuple as a second argument is equivalent as passing each item to issubclass which is what it is doing, albeit in a rather uncommon and pointless way), is it worth putting the check in? Since this is such an obvious mis-use, I say no. But if someone else on python-dev steps in and says otherwise I will patch it. ---------------------------------------------------------------------- Comment By: Eric M. Hopper (omnifarious) Date: 2003-12-10 21:16 Message: Logged In: YES user_id=313 I forgot this: Python 2.3.2 (#1, Dec 4 2003, 09:13:58) [GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin Type "help", "copyright", "credits" or "license" for more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470 From noreply at sourceforge.net Thu Dec 11 13:32:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 13:32:27 2003 Subject: [ python-Bugs-856617 ] HTMLParser parsers AT&T to AT Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Bugs item #856617, was opened at 2003-12-08 21:47 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856617&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hammer Lee (lhy719) Assigned to: Nobody/Anonymous (nobody) Summary: HTMLParser parsers AT&T to AT Initial Comment: I use HTMLParser to parse HTML files. There is an mistake when HTML contents have '&', like
AT&T Research Labs Cambridge - WinVNC Version 3, 3, 3, 7. HTMLParser parses "AT&T Research" to "AT Research". It happens on "ETTC&P EpSCTWeb_Fr Application Version 1, 0, 0, 1" also. I'm a newbie in Python, I don't know how to solve it. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2003-12-11 13:32 Message: Logged In: YES user_id=764593 Technically, that isn't legal html; they're supposed to write & (follow the & with the word "amp;"), because & is an escape character. That said, it is a pretty common error in web pages. The parser already recovers at the next space (instead of waiting for a ";", and I think it would be reasonable to just return the "&T" when T doesn't turn out to be a known entity. You would do this by overriding handle_entityref -- but to be honest, I suspect that you're "really" using some other library (or local code) which already does this, so you may have to make the modification there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856617&group_id=5470 From noreply at sourceforge.net Thu Dec 11 15:50:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 15:50:21 2003 Subject: [ python-Bugs-411881 ] Use of "except:" in modules Message-ID: Bugs item #411881, was opened at 2001-03-28 04:58 Message generated for change (Comment added) made by gmonroe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 2 Submitted By: Itamar Shtull-Trauring (itamar) Assigned to: Skip Montanaro (montanaro) 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: Grant Monroe (gmonroe) Date: 2003-12-11 12:50 Message: Logged In: YES user_id=929204 A good example of an incorrect use of a blanket "except:" clause is in __init__.py in the logging module. The emit method of the StreamHandler class should special case KeyboardInterrupt. Something like this: try: .... except KeyboardInterrupt: raise except: self.handleError(record) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 19:47 Message: Logged In: YES user_id=80475 Some efforts were made to remove many bare excepts prior to Py2.3a1. Briefly scanning those that remain, it looks like many of them are appropriate or best left alone. I recommend that this bug be closed unless someone sees something specific that demands a change. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 16:30 Message: Logged In: YES user_id=357491 threading.py is clear. It's blanket exceptions are for printing debug output since exceptions in threads don't get passed back to the original frame anyway. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-13 20:15 Message: Logged In: YES user_id=44345 checked in fileinput.py (v 1.15) with three except:'s tightened up. The comment in the code about IOError notwithstanding, I don't see how any of the three situations would have caught anything other than OSError. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-12 12:58 Message: Logged In: YES user_id=44345 Note that this particular item was expected to be an ongoing item, with no obvious closure. Some of the bare excepts will have subtle ramifications, and it's not always obvious what specific exceptions should be caught. I've made a few changes to my local source tree which I should check in. Rather than opening new tracker items, I believe those with checkin privileges should correct those flaws they identify and attach a comment which will alert those monitoring the item. Those people without checkin privileges should just attach a patch with a note. Skip ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-08-12 00:22 Message: Logged In: YES user_id=21627 My proposal would be to track this under a different issue: Terry, if you volunteer, please produce a new list of offenders (perhaps in an attachment to the report so it can be updated), and attach any fixes that you have to that report. People with CVS write access can then apply those patches and delete them from the report. If you do so, please post the new issue number in this report, so we have a link. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2002-08-11 11:16 Message: Logged In: YES user_id=593130 Remove types.py from the list. As distributed with 2.2.1, it has 5 'except xxxError:' statements but no offending bare except:'s. Skip (or anyone else): if/when you pursue this, I volunteer to do occasional sleuthing and send reports with suggestions and/or questions. Example: getpass.py has one 'offense': try: fd = sys.stdin.fileno() except: return default_getpass(prompt) According to lib doc 2.2.8 File Objects (as I interpret) fileno () should either work without exception or *not* be implemented. Suggestion: insert AttributeError . Question: do we protect against pseudofile objects that ignore doc and have fake .fileno() that raises NotImplementedError or whatever? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-03-22 22:02 Message: Logged In: YES user_id=44345 as partial fix, checked in changes for the following modules: mimetools.py (1.24) popen2.py (1.23) quopripy (1.19) CGIHTTPServer.py (1.22) ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-03-20 13:24 Message: Logged In: YES user_id=44345 Here is a context diff with proposed changes for the following modules: CGIHTTPServer, cgi, cmd, code, fileinput, httplib, inspect, locale, mimetools, popen2, quopri ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2001-08-11 08:06 Message: Logged In: YES user_id=21627 Fixed urllib in 1.131 and types in 1.19. ---------------------------------------------------------------------- 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: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470 From noreply at sourceforge.net Thu Dec 11 15:54:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 15:54:53 2003 Subject: [ python-Bugs-411881 ] Use of "except:" in modules Message-ID: Bugs item #411881, was opened at 2001-03-28 07:58 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 2 Submitted By: Itamar Shtull-Trauring (itamar) Assigned to: Skip Montanaro (montanaro) 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: Guido van Rossum (gvanrossum) Date: 2003-12-11 15:54 Message: Logged In: YES user_id=6380 You're right. The logging module uses more blank except: clauses than I'm comfortable with. Anyone want to upload a patch set? ---------------------------------------------------------------------- Comment By: Grant Monroe (gmonroe) Date: 2003-12-11 15:50 Message: Logged In: YES user_id=929204 A good example of an incorrect use of a blanket "except:" clause is in __init__.py in the logging module. The emit method of the StreamHandler class should special case KeyboardInterrupt. Something like this: try: .... except KeyboardInterrupt: raise except: self.handleError(record) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 22:47 Message: Logged In: YES user_id=80475 Some efforts were made to remove many bare excepts prior to Py2.3a1. Briefly scanning those that remain, it looks like many of them are appropriate or best left alone. I recommend that this bug be closed unless someone sees something specific that demands a change. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 19:30 Message: Logged In: YES user_id=357491 threading.py is clear. It's blanket exceptions are for printing debug output since exceptions in threads don't get passed back to the original frame anyway. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-13 23:15 Message: Logged In: YES user_id=44345 checked in fileinput.py (v 1.15) with three except:'s tightened up. The comment in the code about IOError notwithstanding, I don't see how any of the three situations would have caught anything other than OSError. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-12 15:58 Message: Logged In: YES user_id=44345 Note that this particular item was expected to be an ongoing item, with no obvious closure. Some of the bare excepts will have subtle ramifications, and it's not always obvious what specific exceptions should be caught. I've made a few changes to my local source tree which I should check in. Rather than opening new tracker items, I believe those with checkin privileges should correct those flaws they identify and attach a comment which will alert those monitoring the item. Those people without checkin privileges should just attach a patch with a note. Skip ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-08-12 03:22 Message: Logged In: YES user_id=21627 My proposal would be to track this under a different issue: Terry, if you volunteer, please produce a new list of offenders (perhaps in an attachment to the report so it can be updated), and attach any fixes that you have to that report. People with CVS write access can then apply those patches and delete them from the report. If you do so, please post the new issue number in this report, so we have a link. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2002-08-11 14:16 Message: Logged In: YES user_id=593130 Remove types.py from the list. As distributed with 2.2.1, it has 5 'except xxxError:' statements but no offending bare except:'s. Skip (or anyone else): if/when you pursue this, I volunteer to do occasional sleuthing and send reports with suggestions and/or questions. Example: getpass.py has one 'offense': try: fd = sys.stdin.fileno() except: return default_getpass(prompt) According to lib doc 2.2.8 File Objects (as I interpret) fileno () should either work without exception or *not* be implemented. Suggestion: insert AttributeError . Question: do we protect against pseudofile objects that ignore doc and have fake .fileno() that raises NotImplementedError or whatever? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-03-23 01:02 Message: Logged In: YES user_id=44345 as partial fix, checked in changes for the following modules: mimetools.py (1.24) popen2.py (1.23) quopripy (1.19) CGIHTTPServer.py (1.22) ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-03-20 16:24 Message: Logged In: YES user_id=44345 Here is a context diff with proposed changes for the following modules: CGIHTTPServer, cgi, cmd, code, fileinput, httplib, inspect, locale, mimetools, popen2, quopri ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2001-08-11 11:06 Message: Logged In: YES user_id=21627 Fixed urllib in 1.131 and types in 1.19. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-04 03: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 15: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 04: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 03: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 10: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 05: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 11: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 13: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 13: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 13: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 11: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 05: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-30 01: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: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470 From noreply at sourceforge.net Thu Dec 11 16:33:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 16:33:56 2003 Subject: [ python-Bugs-856387 ] PyMac_GetOSErrException hack for 2.3.0 compatibility? Message-ID: Bugs item #856387, was opened at 2003-12-08 20:07 Message generated for change (Settings changed) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856387&group_id=5470 Category: Macintosh Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 1 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: PyMac_GetOSErrException hack for 2.3.0 compatibility? Initial Comment: I'd like to be able to backport modules from Python CVS to 2.3.0, such as _Launch, without changing source if possible. The older pymactoolbox.h did not have PyMac_GetOSErrException. I guess this was in macglue.h previously? distutils always puts the installed Python's include dir first, so I can't use my CVS include dir. Would it be reasonable to put a hack in the sources for these modules such that they can work around the pymactoolbox.h differences, or should I replace my system pymactoolbox.h? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-12-09 13:20 Message: Logged In: YES user_id=45365 Coming to think of it: the solution of moving the definition to pymactoolbox.h isn't good enough for distributing source modules to Python 2.3.0, which we also want. I will adapt the sources to compile both under 2.3.0 and 2.4. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-12-08 20:53 Message: Logged In: YES user_id=45365 Including macglue.h will also include pymactoolbox.h, so moving the declaration there in 2.3maint looks safe enough (and, indeed, it should have been there in the first place). ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-12-08 20:47 Message: Logged In: YES user_id=139309 This is the method I'm currently using: I have a folder build_launch sitting next to my checkout of Python CVS. In it, I have a folder src/launch that was cp -r'ed from the Python CVS tree. Also inside src/launch, I have symlink to ../../../ python/dist/src/Include/pythonmac.h. This builds correctly, as the additions to pythonmac.h reflect functions that are actually exported from the Python.framework, but were not in the older version of pythonmac.h. This seems to work alright, because I can still (separately though) cvs up in my copied launch folder, and the pythonmac.h will be updated whenever I cvs up python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856387&group_id=5470 From noreply at sourceforge.net Fri Dec 12 05:03:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 12 05:03:22 2003 Subject: [ python-Bugs-856706 ] popen3 under threads reports different stderr results Message-ID: Bugs item #856706, was opened at 2003-12-09 01:08 Message generated for change (Comment added) made by gaul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856706&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Steven Howe (stevenhowe) Assigned to: Nobody/Anonymous (nobody) Summary: popen3 under threads reports different stderr results Initial Comment: Using os.popen3 inside a thread (start_new_thread) returns different results from the stderr file dev. I discovered this while trying to trap badblocks program output. I have usb floppy I am trying to format, after a badblock check. My floppy is on /dev/sdb. code: import thread import os def dd( outfilename ): cmd='/sbin/badblocks -n -s -v -c 16 -b 512 /dev/sdb' channels = os.popen3( cmd ) ch = ' ' ff = '/tmp/%s' % outfilename out=open( ff ,'w') while ch != '': ch = channels[2].read(1) out.write( ch ) Run two ways. First as a stand alone code. Then as a threaded program. def( 'nothread.err' ) thead.start_new_thread( def, ( 'thread.err' ) ) --------------- Now view the results with od -ta. You will see that the results are very different. All the the verbose data, on current blocks completed, are missing. Steven Howe ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-12-12 04:03 Message: Logged In: YES user_id=139865 Confirmed with Python CVS and Fedora on x86. e2fsprogs/misc/badblocks:alarm_intr sets a SIGALRM handler and calls alarm(1), but it is not getting fired. I will look into this further. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856706&group_id=5470 From noreply at sourceforge.net Fri Dec 12 07:00:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 12 07:01:02 2003 Subject: [ python-Bugs-858253 ] EAGAIN when sys.stdin.readline() Message-ID: Bugs item #858253, was opened at 2003-12-11 07:12 Message generated for change (Comment added) made by gaul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858253&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Frallan the master Jedi (frallan) Assigned to: Nobody/Anonymous (nobody) Summary: EAGAIN when sys.stdin.readline() Initial Comment: $ cat test.py import sys print sys.stdin.readline() $ python test.py | python test.py Traceback (most recent call last): File "test.py", line 2, in ? print sys.stdin.readline() IOError: [Errno 35] Resource temporarily unavailable This happens about 3 times out of 5. It happens under FreeBSD 5.1-RELEASE (SMP) and: python-2.1.3 python-2.2.3 python-2.3.2 python-2.3.3c1 It does _not_ happen under Debian 3.0 or FreeBSD 4.7-RELEASE (SMP). According to read(2) this "error" should occur only when the descriptor is in non-blocking mode. However as you can see from the program it isn't. Further I have caught the IOError and run fcntl(F_GETFL) on sys.stdin.fileno() and the only flag set is O_RDWR. ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-12-12 06:00 Message: Logged In: YES user_id=139865 Same on OpenBSD: $ uname -a OpenBSD owl 3.2 GENERIC#25 i386 $ python -V Python 2.2.1 $ python test.py | python test.py Traceback (most recent call last): File "test.py", line 2, in ? print sys.stdin.readline() IOError: [Errno 35] Resource temporarily unavailable ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858253&group_id=5470 From noreply at sourceforge.net Fri Dec 12 14:02:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 12 14:02:29 2003 Subject: [ python-Bugs-856706 ] popen3 under threads reports different stderr results Message-ID: Bugs item #856706, was opened at 2003-12-08 23:08 Message generated for change (Comment added) made by stevenhowe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856706&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Steven Howe (stevenhowe) Assigned to: Nobody/Anonymous (nobody) Summary: popen3 under threads reports different stderr results Initial Comment: Using os.popen3 inside a thread (start_new_thread) returns different results from the stderr file dev. I discovered this while trying to trap badblocks program output. I have usb floppy I am trying to format, after a badblock check. My floppy is on /dev/sdb. code: import thread import os def dd( outfilename ): cmd='/sbin/badblocks -n -s -v -c 16 -b 512 /dev/sdb' channels = os.popen3( cmd ) ch = ' ' ff = '/tmp/%s' % outfilename out=open( ff ,'w') while ch != '': ch = channels[2].read(1) out.write( ch ) Run two ways. First as a stand alone code. Then as a threaded program. def( 'nothread.err' ) thead.start_new_thread( def, ( 'thread.err' ) ) --------------- Now view the results with od -ta. You will see that the results are very different. All the the verbose data, on current blocks completed, are missing. Steven Howe ---------------------------------------------------------------------- >Comment By: Steven Howe (stevenhowe) Date: 2003-12-12 11:02 Message: Logged In: YES user_id=916892 Hello Gaul. Well I found a work around. Using threading.Thread, I init a routine that forks and execv's a script (execv has no method to accept redirects '> 2>') that runs the badblocks program and route output to files. Then I the a thread that uses open() to attach the to a progress reading routine and when complete for the badblock list (if any). This method created another problem. Popen3 does not return an end of file ( '' ) until the process has ended. With badblocks forked, there is no syncronization between my script and the badblocks output. So I can and do overrun the output, which then returns an EOF. Another workaround: I wrote a routine to make sure I never read to the end of file: readsize = os.stat(fname)[stat.ST_SIZE] - fptr.tell() - BIAS All this so I can using threading. No doubt you're asking why use threading? I'm making a pygtk app similar to 'gfloppy' that can handle USB floppies. I need to make a progress meter. Using threading allows a GTK call back to examine the current status of badblocks. But a fix would be preferable. Thanks, Steven Howe ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-12-12 02:03 Message: Logged In: YES user_id=139865 Confirmed with Python CVS and Fedora on x86. e2fsprogs/misc/badblocks:alarm_intr sets a SIGALRM handler and calls alarm(1), but it is not getting fired. I will look into this further. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856706&group_id=5470 From noreply at sourceforge.net Fri Dec 12 14:40:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 12 14:40:48 2003 Subject: [ python-Bugs-859113 ] inconsistency in string.split() Message-ID: Bugs item #859113, was opened at 2003-12-12 11:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=859113&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: damon fasching (damon3937) Assigned to: Nobody/Anonymous (nobody) Summary: inconsistency in string.split() Initial Comment: Hi, Bug is a strong word for this. I'll call this an inconsistency in string. split(). Python 2.3.2 (#2, Nov 12 2003, 02:20:08) [GCC 3.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import string >>> blah = '' >>> string.split(blah) [] >>> string.split(blah, '\t') [''] >>> >>> string.split(blah, ' ') [''] The NULL string has the same relationship to any character as it has to any other, so it seems that string.split('', anything) should always give the same result. Damon ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=859113&group_id=5470 From noreply at sourceforge.net Fri Dec 12 15:29:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 12 15:29:45 2003 Subject: [ python-Bugs-859113 ] inconsistency in string.split() Message-ID: Bugs item #859113, was opened at 2003-12-13 04:40 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=859113&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: damon fasching (damon3937) Assigned to: Nobody/Anonymous (nobody) Summary: inconsistency in string.split() Initial Comment: Hi, Bug is a strong word for this. I'll call this an inconsistency in string. split(). Python 2.3.2 (#2, Nov 12 2003, 02:20:08) [GCC 3.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import string >>> blah = '' >>> string.split(blah) [] >>> string.split(blah, '\t') [''] >>> >>> string.split(blah, ' ') [''] The NULL string has the same relationship to any character as it has to any other, so it seems that string.split('', anything) should always give the same result. Damon ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-12-13 05:29 Message: Logged In: YES user_id=671362 I think this is a duplicate of bugs[811604]. # [ 811604 ] "string".split behaviour for empty strings http://www.python.org/sf/811604 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=859113&group_id=5470 From noreply at sourceforge.net Fri Dec 12 15:35:43 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 12 15:35:47 2003 Subject: [ python-Bugs-859113 ] inconsistency in string.split() Message-ID: Bugs item #859113, was opened at 2003-12-12 20:40 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=859113&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: damon fasching (damon3937) Assigned to: Nobody/Anonymous (nobody) Summary: inconsistency in string.split() Initial Comment: Hi, Bug is a strong word for this. I'll call this an inconsistency in string. split(). Python 2.3.2 (#2, Nov 12 2003, 02:20:08) [GCC 3.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import string >>> blah = '' >>> string.split(blah) [] >>> string.split(blah, '\t') [''] >>> >>> string.split(blah, ' ') [''] The NULL string has the same relationship to any character as it has to any other, so it seems that string.split('', anything) should always give the same result. Damon ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-12-12 21:29 Message: Logged In: YES user_id=671362 I think this is a duplicate of bugs[811604]. # [ 811604 ] "string".split behaviour for empty strings http://www.python.org/sf/811604 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=859113&group_id=5470 From noreply at sourceforge.net Sat Dec 13 06:21:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 13 06:21:07 2003 Subject: [ python-Bugs-411881 ] Use of "except:" in modules Message-ID: Bugs item #411881, was opened at 2001-03-28 07:58 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 2 Submitted By: Itamar Shtull-Trauring (itamar) Assigned to: Skip Montanaro (montanaro) 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: Raymond Hettinger (rhettinger) Date: 2003-12-13 06:21 Message: Logged In: YES user_id=80475 Hold-off on logging for a bit. Vinay Sajip has other patches already under review. I'll ask him to fix-up the bare excepts in conjuction with those patches. For the other modules, patches are welcome. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-11 15:54 Message: Logged In: YES user_id=6380 You're right. The logging module uses more blank except: clauses than I'm comfortable with. Anyone want to upload a patch set? ---------------------------------------------------------------------- Comment By: Grant Monroe (gmonroe) Date: 2003-12-11 15:50 Message: Logged In: YES user_id=929204 A good example of an incorrect use of a blanket "except:" clause is in __init__.py in the logging module. The emit method of the StreamHandler class should special case KeyboardInterrupt. Something like this: try: .... except KeyboardInterrupt: raise except: self.handleError(record) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 21:47 Message: Logged In: YES user_id=80475 Some efforts were made to remove many bare excepts prior to Py2.3a1. Briefly scanning those that remain, it looks like many of them are appropriate or best left alone. I recommend that this bug be closed unless someone sees something specific that demands a change. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 18:30 Message: Logged In: YES user_id=357491 threading.py is clear. It's blanket exceptions are for printing debug output since exceptions in threads don't get passed back to the original frame anyway. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-13 22:15 Message: Logged In: YES user_id=44345 checked in fileinput.py (v 1.15) with three except:'s tightened up. The comment in the code about IOError notwithstanding, I don't see how any of the three situations would have caught anything other than OSError. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-12 14:58 Message: Logged In: YES user_id=44345 Note that this particular item was expected to be an ongoing item, with no obvious closure. Some of the bare excepts will have subtle ramifications, and it's not always obvious what specific exceptions should be caught. I've made a few changes to my local source tree which I should check in. Rather than opening new tracker items, I believe those with checkin privileges should correct those flaws they identify and attach a comment which will alert those monitoring the item. Those people without checkin privileges should just attach a patch with a note. Skip ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-08-12 02:22 Message: Logged In: YES user_id=21627 My proposal would be to track this under a different issue: Terry, if you volunteer, please produce a new list of offenders (perhaps in an attachment to the report so it can be updated), and attach any fixes that you have to that report. People with CVS write access can then apply those patches and delete them from the report. If you do so, please post the new issue number in this report, so we have a link. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2002-08-11 13:16 Message: Logged In: YES user_id=593130 Remove types.py from the list. As distributed with 2.2.1, it has 5 'except xxxError:' statements but no offending bare except:'s. Skip (or anyone else): if/when you pursue this, I volunteer to do occasional sleuthing and send reports with suggestions and/or questions. Example: getpass.py has one 'offense': try: fd = sys.stdin.fileno() except: return default_getpass(prompt) According to lib doc 2.2.8 File Objects (as I interpret) fileno () should either work without exception or *not* be implemented. Suggestion: insert AttributeError . Question: do we protect against pseudofile objects that ignore doc and have fake .fileno() that raises NotImplementedError or whatever? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-03-23 01:02 Message: Logged In: YES user_id=44345 as partial fix, checked in changes for the following modules: mimetools.py (1.24) popen2.py (1.23) quopripy (1.19) CGIHTTPServer.py (1.22) ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-03-20 16:24 Message: Logged In: YES user_id=44345 Here is a context diff with proposed changes for the following modules: CGIHTTPServer, cgi, cmd, code, fileinput, httplib, inspect, locale, mimetools, popen2, quopri ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2001-08-11 10:06 Message: Logged In: YES user_id=21627 Fixed urllib in 1.131 and types in 1.19. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-04 02: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 14: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 03: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 02: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 09: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 04: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 10: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 12: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 12: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 12: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 10: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 05: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-30 01: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: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470 From noreply at sourceforge.net Sat Dec 13 20:08:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 13 22:39:08 2003 Subject: [ python-Bugs-858016 ] Pathological case segmentation fault in issubclass Message-ID: Bugs item #858016, was opened at 2003-12-10 22:13 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Eric M. Hopper (omnifarious) >Assigned to: Brett Cannon (bcannon) Summary: Pathological case segmentation fault in issubclass Initial Comment: This works for the PowerPC Python compiled with gcc 3.3 on OS X using fink. I suspect it's broader based than that, but I don't have the ability to check properly. Here's how to make it segment fault: x = (basestring,) for i in xrange(0, 1000000): x = (x,) issubclass(str, x) At least, it segment faults at the interactive prompt this way. I don't know if it does when it's executed from a file. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-12-13 20:08 Message: Logged In: YES user_id=31435 Yes, this needs to be fixed if it *can* be fixed without heroic effort or insane slowdown. Looks like it can be. Brett, the missing piece of your worldview here is that anywhere Python can be tricked into segfaulting is a kind of "security hole" -- it's not just mistakes we want to protect programmers from, we also want to bulletproof against hostile users, to the extent sanely possible. BTW, if issubclass() has this insecurity, I bet isinstance() does too (they were introduced & coded at the same time). ---------------------------------------------------------------------- Comment By: Eric M. Hopper (omnifarious) Date: 2003-12-11 12:54 Message: Logged In: YES user_id=313 Well, I think any case where the system segment faults unexpectedly is bad, regardless of how pathological it is. Personally, I think that issubclass should either have a recursion limit after which it throws an exception, or it shouldn't go into sub-tuples at all. The reason I made this test is that I read the description of the behavior of issublcass and found it rather strange, so I decided to push it to see how far it would go. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-12-10 23:28 Message: Logged In: YES user_id=357491 If you look at Object/abstract.c (line 2119 or so) for 2.4 CVS you will notice that PyObject_IsSubclass goes into a 'for' loop for each item in the tuple passed in and calls PyObject_IsSubclass . Unfortunately it makes no check for whether the argument it is passing is a class itself or not. This allows it to keep making calls as long as the second argument is either a class or a tuple. This is what is leads to the stack being blown and the subsequent segfault. Obvious solution is to put in a check that the argument about to be passed is a class itself so as to not have such a deep call chain. But since ``help(issubclass)`` actually makes the above use legit (it says using a tuple as a second argument is equivalent as passing each item to issubclass which is what it is doing, albeit in a rather uncommon and pointless way), is it worth putting the check in? Since this is such an obvious mis-use, I say no. But if someone else on python-dev steps in and says otherwise I will patch it. ---------------------------------------------------------------------- Comment By: Eric M. Hopper (omnifarious) Date: 2003-12-10 22:16 Message: Logged In: YES user_id=313 I forgot this: Python 2.3.2 (#1, Dec 4 2003, 09:13:58) [GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin Type "help", "copyright", "credits" or "license" for more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470 From noreply at sourceforge.net Sat Dec 13 14:45:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 01:03:13 2003 Subject: [ python-Feature Requests-801847 ] Adding rsplit() to string and unicode objects. Message-ID: Feature Requests item #801847, was opened at 2003-09-07 09:52 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=801847&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: Accepted Priority: 4 Submitted By: Sean Reifschneider (jafo) Assigned to: Alex Martelli (aleax) Summary: Adding rsplit() to string and unicode objects. Initial Comment: I'm attaching patches to the library and documentation for implementing rsplit() on string and unicode objects. This works like split(), but working from the right. ./python -c 'print u"foo, bar, baz".rsplit(None, 1)' [u'foo, bar,', u'baz'] This was supposed to be against the CVS code, but I've had a heck of a time getting it checked out -- my checkout has been hung for half an hour now. The code patch is against the 2.3 release, the docs patch is against the CVS. My checkout got to docs, but I didn't have the code to a point where I could build and test it. Sean ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-12-14 04:45 Message: Logged In: YES user_id=55188 On my review, few bugs are found. >>> u'x\x00y\x00z'.rsplit(u'\x00', 1) zsh: bus error (core dumped) ./python >>> u'abcd'.rsplit(u'abcd') [u'abcd'] >>> 'a,b,c,d'.rsplit(u',', 2) [u'a', u'b', u'c,d'] And, unittests on Lib/test/test_strop.py should be moved to strings_test.py My revision for jafo's patch is available at http://people.freebsd.org/~perky/rsplit-perkyrev.diff ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-01 23:18 Message: Logged In: YES user_id=80475 Alex said he would take the patch from here. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-26 06:03 Message: Logged In: YES user_id=80475 Okay, I've got it from here! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-11-26 05:47 Message: Logged In: YES user_id=6380 OK, I'm in a generous mood today. I approve the idea. (I'm not going to review the code, that's up to Raymond and others). And Raymond can have a fillchar option to center() as well. I don't know what cook() was supposed to do, but if it's $ substitution, I recommend to keep that in a separate module for now. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-11-26 04:35 Message: Logged In: YES user_id=81797 If you are reading this and are interested in having this functionality in the standard Python library, please step forward and champion the effort. Obviously, I believe this is useful, or I wouldn't have spent the better part of a day building and testing it. However, I simply don't have the time to go through the politics of it. What needs to be done is a case needs to be further built for the presentation to the Python developement team. See Raymond's message below for a good list of what's needed there. Also see the thread on the python developers mailing list that I started in relation to this back in September. I will be happy to help out on this, but I just don't have the time to champion the adoption process. Thanks, Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-26 04:16 Message: Logged In: YES user_id=21627 It's very easy: find somebody with commit privileges to approve and commit the change. Failing to do so, write a library PEP, and ask for pronouncement. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-11-26 01:34 Message: Logged In: YES user_id=81797 Raymond, you've asked Guido about it on September 11, and he (apparently) explicitly stayed out of the discussion. I assumed that you had let him know you wanted his judgement on this and that his response was that he didn't want to be involved, leaving it up to the library "elite guard" instead. Did you actually copy Guido on your earlier request? Personally, I don't see the logic in "if we get only one string method". Python isn't for the Python core developers, it's for the users. If the users have several things that they want added, why the artificial limit on how many to accept? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-25 11:25 Message: Logged In: YES user_id=80475 Get Guido to approve the API change and I will be happy to complete the implementation, documentation, testing, etc. Advice: He will want *compelling* non-toy use cases and reasons why that a person wouldn't just implement it in pure python (saying that they aren't smart enough is not a reason). He is rarely ever persuaded by symmetry/completeness arguments along the lines of "we have an l-this so we have to have an r-that". If that were the case, tuples would have gotten index() and count() long ago. Language growth rate is one issue, the total number of string methods is another, and more importantly he seeks to minimize the number of small API compatabilities between versions which make it difficult to write code for Py2.4 that runs on Py2.2. Also, there are a number of strong competitors vying to be added as string methods. If we only get one new method, why is this one to be preferred over str.cook() for supporting Barry's simplified string substitutions Given only one new str API change, I would personally prefer to add an optional fillchar argument to str.center(). ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-11-25 07:45 Message: Logged In: YES user_id=139309 I'd have to say me too on this one, wake up please :) ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-29 14:38 Message: Logged In: YES user_id=81797 This seems to have generated nothing but positive comment from the folks on python-dev. Thoughts? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-23 03:17 Message: Logged In: YES user_id=80475 I'll review your patch when I get a chance. ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-09-22 22:10 Message: Logged In: YES user_id=99508 As a comment on the ease with which a programmer can get rsplit wrong, note that rhettinger's rsplit implementation is not correct: compare rsplit('foobarbaz', 'bar') with 'foobarbaz'.split('bar'). He forgot to reverse the separator if it's not None. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-12 08:55 Message: Logged In: YES user_id=80475 Guido, do you care to pronounce on this one? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-11 15:07 Message: Logged In: YES user_id=21627 There is PEP 2, which suggests to write a library PEP for proposal to extend the library. Now, this probably would be overkill for a single string method. However, I feel that there are already too many string methods, so I won't accept that patch. I'm not rejecting it, either, because I see that other maintainers might have a different opinion. In short, you should propose your change to python-dev, finding out what "a majority" of the maintainers thinks; you might also propose it on python-list, trying to collect reactions from users. It would then be good to summarize these discussions here (instead of carrying them out here). ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-11 05:40 Message: Logged In: YES user_id=81797 I realize that rsplit() can be implemented, because, well, I implemented it. The standard library is there to provide ready-to-use functionality so that users of python can concentrate on their program instead of concentrate on re-inventing the wheel. find() can be implemented with a short loop, split() can be implemented with find(), join() can be implemented with a short loop. Many things can be implemented with a little additional effort on the part of the user to develop or locate the code they're wanting. These little things can add up quickly and can have quite a dramatic impact on the programming experience in Python. Having to find or implement these functions will cause distraction from the code at hand, time lost while finding, implementing, testing, and maintaining the code in question. One of Python's strengths is a rich standard library. So, what are the guidelines for determining when it's rich enough? Why is it ok to suggest that users should get distracted from their code to go implement something else? Is there a policy that I'm not aware of that new functionality should be put in the cookbook instead of the standard library? Why is it being ignored that some programmers would find implementing rsplit() challenging? I'm not trying to be difficult here, I honestly can't understand the apparent change from having a rich library to a "batteries not included" stance. The response I got from #python when I mentioned having submitted the patch indicates to me that other experienced Python developers expect there to be an rsplit(). So, why is there so much resistance to adding something to the library? What are the guidelines for determining if something should be in the library? Sean ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-11 04:35 Message: Logged In: YES user_id=80475 I would classify this more as a technique than a fundamental string operation implemented by all stringlike objects (including UserString). Accordingly, I recommend that the patch be closed and a recipe posted in the ASPN cookbook - something along the lines of: >>> def rsplit(s, sep=None, maxsplit=-1): ... return [chunk[::-1] for chunk in s[::-1].split(sep, maxsplit)[::-1]] >>> rsplit(u"foo, bar, baz", None, 1) [u'foo, bar,', u'baz'] ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-11 04:15 Message: Logged In: YES user_id=81797 os.path.basename/os.path.dirname is an example of where you could use rsplit. One of the other #python folks said he had recently wanted rsplit for an application where he was getting the domain name and user part from a list of e-mail addresses, but found that some entries contained an "@" in the user part. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-11 02:08 Message: Logged In: YES user_id=21627 I questioned the usefulness because I could not think of a meaningful application. Now I see what a potential application could be, but I doubt its generality, because that approach would break if there could be two fields that have commas in them. I also disagree that symmetry can motivate usefulness: I also doubt that all of the r* functions are useful, but they cannot be removed for backwards compatibility. The fact that rsplit would fit together with the other r* functions indicates that adding rsplit would provide symmetry, not that it would provide usefulness. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-08 09:56 Message: Logged In: YES user_id=81797 Can you provide more details about why the usefulness of this function is in question? First I would like to tell you the story of it coming to be, then I will answer your incomplete question with a (probably) incomplete answer. I had a device which sent me comma-separated fields, but one of the fields in the middle could contain a comma. The answer that seemed obvious to me was to use split with a maxsplit to get the fields up to that field, and then a rsplit with a maxsplit on the remainder. When I mentioned on #python that I was implementing rsplit, 4 other fellow python users replied right away that they had been wanting it. To answer your question, it's useful because people using strings are used to having r*() functions like rfind and rstrip. The lack of rsplit is kind of glaring in this context. Really, though, it's useful because otherwise people have to implement -- often badly. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-08 04:49 Message: Logged In: YES user_id=21627 Why is this function useful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=801847&group_id=5470 From noreply at sourceforge.net Sat Dec 13 11:34:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 02:04:58 2003 Subject: [ python-Feature Requests-847778 ] Keyword similar to "global" for nested scopes wanted Message-ID: Feature Requests item #847778, was opened at 2003-11-23 19:51 Message generated for change (Comment added) made by dubnerm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=847778&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jozef Behran (jojoworks) Assigned to: Nobody/Anonymous (nobody) Summary: Keyword similar to "global" for nested scopes wanted Initial Comment: I suggest you adding a keyword, say "nested" to explicitly bound the name to the upper level of nested scope. This keyword would be similar to "global", which bounds the name to the top level. See the attachment for the idea. ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2003-12-04 07:01 Message: Logged In: YES user_id=39274 Hm-m. What about outer scope for outer scope? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=847778&group_id=5470 From noreply at sourceforge.net Sat Dec 13 13:11:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 02:50:32 2003 Subject: [ python-Bugs-215126 ] Over restricted type checking on eval() function Message-ID: Bugs item #215126, was opened at 2000-09-22 14:36 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=215126&group_id=5470 Category: Python Interpreter Core Group: Feature Request >Status: Open Resolution: Later Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Raymond Hettinger (rhettinger) Summary: Over restricted type checking on eval() function Initial Comment: The built-in function eval() takes a string argument and a dictionary. The second argument should allow any instance which defines __getitem__ as opposed to just dictionaries. The following example creates a type error: eval, argument 2: expected dictionary, instance found class SpreadSheet: _cells = {} def __setitem__( self, key, formula ): self._cells[key] = formula def __getitem__( self, key ): return eval( self._cells[key], self ) ss = SpreadSheet() ss['a1'] = '5' ss['a2'] = 'a1*5' ss['a2'] ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-09-22 23:18 Message: Added to PEP 42. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-09-22 14:42 Message: Changed Group to Feature Request. Should be added to PEP 42 (I'll do that if nobody beats me to it). CPython requires a genuine dict now for speed. I believe JPython allows any mapping object. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=215126&group_id=5470 From noreply at sourceforge.net Sat Dec 13 15:22:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 03:07:29 2003 Subject: [ python-Bugs-858253 ] EAGAIN when sys.stdin.readline() Message-ID: Bugs item #858253, was opened at 2003-12-11 22:12 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858253&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Frallan the master Jedi (frallan) Assigned to: Nobody/Anonymous (nobody) Summary: EAGAIN when sys.stdin.readline() Initial Comment: $ cat test.py import sys print sys.stdin.readline() $ python test.py | python test.py Traceback (most recent call last): File "test.py", line 2, in ? print sys.stdin.readline() IOError: [Errno 35] Resource temporarily unavailable This happens about 3 times out of 5. It happens under FreeBSD 5.1-RELEASE (SMP) and: python-2.1.3 python-2.2.3 python-2.3.2 python-2.3.3c1 It does _not_ happen under Debian 3.0 or FreeBSD 4.7-RELEASE (SMP). According to read(2) this "error" should occur only when the descriptor is in non-blocking mode. However as you can see from the program it isn't. Further I have caught the IOError and run fcntl(F_GETFL) on sys.stdin.fileno() and the only flag set is O_RDWR. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-12-14 05:22 Message: Logged In: YES user_id=55188 I could not reproduce the error on several versions of FreeBSD: 5.2-BETA Thu Dec 4 21:59:16 KST 2003 i386 (non-SMP) 5.2-CURRENT Sat Dec 13 08:02:47 PST 2003 alpha (SMP) 5.2-CURRENT Tue Dec 9 02:39:36 PST 2003 ia64 (SMP) 5.2-CURRENT Sat Dec 13 07:52:29 PST 2003 i386 (SMP) 5.1-RELEASE Sat Jun 14 05:13:38 KST 2003 i386 (SMP) Do you have any uncommon factor of environment? (and did you install the python via ports?) ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-12-12 21:00 Message: Logged In: YES user_id=139865 Same on OpenBSD: $ uname -a OpenBSD owl 3.2 GENERIC#25 i386 $ python -V Python 2.2.1 $ python test.py | python test.py Traceback (most recent call last): File "test.py", line 2, in ? print sys.stdin.readline() IOError: [Errno 35] Resource temporarily unavailable ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858253&group_id=5470 From noreply at sourceforge.net Sun Dec 14 05:31:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 05:31:37 2003 Subject: [ python-Bugs-858253 ] EAGAIN when sys.stdin.readline() Message-ID: Bugs item #858253, was opened at 2003-12-11 13:12 Message generated for change (Comment added) made by frallan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858253&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Frallan the master Jedi (frallan) Assigned to: Nobody/Anonymous (nobody) Summary: EAGAIN when sys.stdin.readline() Initial Comment: $ cat test.py import sys print sys.stdin.readline() $ python test.py | python test.py Traceback (most recent call last): File "test.py", line 2, in ? print sys.stdin.readline() IOError: [Errno 35] Resource temporarily unavailable This happens about 3 times out of 5. It happens under FreeBSD 5.1-RELEASE (SMP) and: python-2.1.3 python-2.2.3 python-2.3.2 python-2.3.3c1 It does _not_ happen under Debian 3.0 or FreeBSD 4.7-RELEASE (SMP). According to read(2) this "error" should occur only when the descriptor is in non-blocking mode. However as you can see from the program it isn't. Further I have caught the IOError and run fcntl(F_GETFL) on sys.stdin.fileno() and the only flag set is O_RDWR. ---------------------------------------------------------------------- >Comment By: Frallan the master Jedi (frallan) Date: 2003-12-14 10:31 Message: Logged In: YES user_id=639616 All my python versions are compiled from source. Further, since the problem only occur some of the time and only on some of the platforms, it's natural to suspect foul play from the runtime environment (i.e shell, OS) and that it might not be a bug in python. It's not like blocking input should be a black art. I refuse to believe that this issue has never been raised before and subsequently solved. It's just a matter of finding the right mailing list archive. The alternative seems to be hacking the interpreter and try to narrow it down. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-12-13 20:22 Message: Logged In: YES user_id=55188 I could not reproduce the error on several versions of FreeBSD: 5.2-BETA Thu Dec 4 21:59:16 KST 2003 i386 (non-SMP) 5.2-CURRENT Sat Dec 13 08:02:47 PST 2003 alpha (SMP) 5.2-CURRENT Tue Dec 9 02:39:36 PST 2003 ia64 (SMP) 5.2-CURRENT Sat Dec 13 07:52:29 PST 2003 i386 (SMP) 5.1-RELEASE Sat Jun 14 05:13:38 KST 2003 i386 (SMP) Do you have any uncommon factor of environment? (and did you install the python via ports?) ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-12-12 12:00 Message: Logged In: YES user_id=139865 Same on OpenBSD: $ uname -a OpenBSD owl 3.2 GENERIC#25 i386 $ python -V Python 2.2.1 $ python test.py | python test.py Traceback (most recent call last): File "test.py", line 2, in ? print sys.stdin.readline() IOError: [Errno 35] Resource temporarily unavailable ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858253&group_id=5470 From noreply at sourceforge.net Sun Dec 14 07:16:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 07:16:09 2003 Subject: [ python-Bugs-859810 ] typo in doc Message-ID: Bugs item #859810, was opened at 2003-12-14 12:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=859810&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: typo in doc Initial Comment: http://python.org/doc/current/mac/module-MacOS.html s/wether/whether/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=859810&group_id=5470 From noreply at sourceforge.net Sun Dec 14 07:17:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 07:17:17 2003 Subject: [ python-Bugs-859811 ] typo in docs Message-ID: Bugs item #859811, was opened at 2003-12-14 12:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=859811&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: typo in docs Initial Comment: http://python.org/doc/current/mac/module-MacOS.html s/in stead/instead/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=859811&group_id=5470 From noreply at sourceforge.net Sun Dec 14 10:02:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 10:02:06 2003 Subject: [ python-Bugs-859810 ] typo in doc Message-ID: Bugs item #859810, was opened at 2003-12-14 07:16 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=859810&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) >Assigned to: Neal Norwitz (nnorwitz) Summary: typo in doc Initial Comment: http://python.org/doc/current/mac/module-MacOS.html s/wether/whether/ ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-14 10:02 Message: Logged In: YES user_id=33168 Thanks, checked in as: Doc/mac/libmacos.tex 1.21 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=859810&group_id=5470 From noreply at sourceforge.net Sun Dec 14 10:03:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 10:03:39 2003 Subject: [ python-Bugs-859811 ] typo in docs Message-ID: Bugs item #859811, was opened at 2003-12-14 07:17 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=859811&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) >Assigned to: Neal Norwitz (nnorwitz) Summary: typo in docs Initial Comment: http://python.org/doc/current/mac/module-MacOS.html s/in stead/instead/ ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-14 10:03 Message: Logged In: YES user_id=33168 Thanks, checked in as: * Doc/mac/libmacos.tex 1.22 * Doc/mac/libmacui.tex 1.22 * Doc/mac/using.tex 1.10 * Doc/mac/scripting.tex 1.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=859811&group_id=5470 From noreply at sourceforge.net Sun Dec 14 10:18:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 10:18:30 2003 Subject: [ python-Feature Requests-759792 ] Make urllib2 more extensible (patch) Message-ID: Feature Requests item #759792, was opened at 2003-06-24 14:16 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=759792&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: Make urllib2 more extensible (patch) Initial Comment: Problem with urllib2 as it stands: many things would be nice to implement as a handler rather than by overriding methods (and inevitably duplicating code and increasing fragility), but it's not always possible to do so. For example (all from HTTP), automatically adding Referer headers, handling 200 responses that should have been non-2xx errors if the server were sane, handling cookies, handling HTTP-EQUIV headers as if they were normal HTTP headers, automatically making responses seekable, and following Refresh headers. I've done all these things, but I had to duplicate code to do it, because I don't see how to do it with handlers. I've now rewritten this code by adding a 'processor' scheme to urllib2 (I'm *not* using 'scheme' in the technical URL sense here!). Processors work quite similarly to handlers, except that 1. They always *all* get run (rather than just the first to handle a request or response -- unlike handlers). 2. The methods that get called on processors are of the form _request and _response, and are called, respectively, immediately before and immediately after the normal OpenerDirector.open machinery. http_request, for example, gets called on all processors before, and pre-processes HTTP requests; http_response post-processes HTTP responses. 3. _request methods return request objects, and _response methods return response objects. 4. Even 200 responses get processed. You use it like this: # just pass processors to build_opener as if they were handlers opener = build_opener(FooHandler, BarProcessor, BazHandler) response = opener.open("http://www.example.com/") I've reimplemented all my stuff (the features listed in the first paragraph, above) in terms of this scheme, and it all seems to be working fine (but no unit tests yet). So, the scheme does achieve the extensibility it aims for. The patch I've attached here doesn't include most of those features -- the only new functionality it adds is an HTTPRefererProcessor. If this gets accepted, I intend to submit patches adding new processors for cookie handling etc. later. Two things I'd like to know: 1. will my solution break people's code 2. is there a better way? For 1., I *think* it shouldn't break code. For 2., the obvious problem with my solution (below) is that handlers are pretty similar to my processors already. The thing is, I can't see how to reimplement these things in terms of handlers. First, I need to *see* all requests (responses) -- I can do that using handlers by giving them low (high) .handler_order in Python 2.3 and returning None from http_open (http_error_xxx). However, 200 responses never get seen by http_error_xxx, so that doesn't work (and changing that would break old code). Second, I need to actually modify the requests and responses. Sometimes I'd much rather do that by making a new request or response than modifying the old one in-place (redirections, for example) -- and in general, even if I *am* just modifying in-place, I'd still prefer to explictly return the object than rely on side-effects. Perhaps just adding a couple of hooks to AbstractHTTPHandler might get these jobs done, but I think the increased simplicity of AbstractHTTPHandler.do_open and the various processors makes my approach worthwhile (assuming it actually works & is backwards-compat., of course...). Comments? A few notes: Some headers (Content-Length, Referer, ...) mustn't be copied to requests for a redirected URL. This requires the addition of a new dict to Request. I've added an add_unredirected_headers method, too. The old implementation just sends these headers directly, but that's not possible if you want to use procesors to implement these things. The current response object (httplib.HTTPResponse, wrapped with urllib.addinfourl) doesn't include response code or message (because code is always 200). The patch just assigns .code and .msg attributes (maybe they should be methods, for uniformity with the rest of the response interface). Backwards-compatibility notes: People who override AbstractHTTPHandler.do_open will do non-200 response handling there, which will break processors, but that's a forwards-compat. issue. I don't think the existence of overridden do_open methods in old code should be a problem for backwards-compatibility. Note that, though processors see all responses, the end user still only gets 200 responses returned. ErrorProcessor ensures that by passing non-200 responses on to the existing urllib2 error machinery. John ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2003-12-14 15:18 Message: Logged In: YES user_id=261020 Patch 852995 applied, so closing this one. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-03 18:26 Message: Logged In: YES user_id=261020 I've uploaded a revised patch, plus some urllib2 tests and a doc patch, in patch 852995. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-10-29 23:10 Message: Logged In: YES user_id=261020 Just to note a minor change that should happen if this gets accepted: processors shouldn't be separate objects, but rather just a new interface that handler objects can support. That way, a single object can implement both interfaces. This makes implementing response cache handlers easier, for example. Not uploading a new patch, since it's a trivial code change. It might also be useful to have default_request and default_response methods (by analogy with default_open), for example for any response caching that's independent of protocol scheme. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-08-12 16:19 Message: Logged In: YES user_id=31392 Dont't wait more than a couple of weeks for me. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-08-12 12:58 Message: Logged In: YES user_id=261020 If anybody wants to see some concrete examples of use of this patch, ask me & I'll mail them to you (actually, they use my urllib2 extension module rather than the patch, but the differences are trivial). BTW Jeremy, any guess about when in your Copious Free Time you're likely to get to this? I'm wondering whether to just release my code as-is, or wait for your comments. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-08-12 12:39 Message: Logged In: YES user_id=261020 Possibly similar to Apache filters, but sio's filters seem to be for filtering stream data rather than request / response objects -- has no concept of headers, for example. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-12 06:46 Message: Logged In: YES user_id=357491 Sounds kind of like Apache's filters. The idea seems fine, but perhaps this could instead be worked in with Guido's sio package in the CVS sandbox? Seems to be a similar idea. Perhaps there could some way of hooking that code into urllib2? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-31 23:15 Message: Logged In: YES user_id=31392 In principle, I'm in favor of this. I'd like to take some time to review the design and code. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-07-08 16:13 Message: Logged In: YES user_id=261020 I just noticed the patch breaks on https. Trivially fixed by adding lines like https_request = http_request to the various processor classes. Also, another use case: gzip Content-encoding. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=759792&group_id=5470 From noreply at sourceforge.net Sun Dec 14 11:43:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 11:43:40 2003 Subject: [ python-Bugs-856072 ] UserDict.DictMixin's comments should be a docstring Message-ID: Bugs item #856072, was opened at 2003-12-08 01:19 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856072&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Bennetts (spiv) >Assigned to: Raymond Hettinger (rhettinger) Summary: UserDict.DictMixin's comments should be a docstring Initial Comment: DictMixin in the UserDict module has no docstring -- but it has a comment that reads like one. I think the comment should probably be changed to a docstring so that interactive use of e.g. "help(UserDict.DictMixin)" explains how it works (override _getitem__(), __setitem__(), __delitem__(), and keys(), and the rest is done for you). If the existing comment is considered too cryptic, the text in the Library Reference for DictMixin would be a good basis for a docstring. (This is a really minor bug, but it's a shame to see such a useful class not being perfectly documented! :) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-14 11:43 Message: Logged In: YES user_id=80475 Okay, I'll take another look at the original decision to omit docstrings. The rationale was to avoid contaminating the documentation of user classes that subclass UserDict.DictMixin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856072&group_id=5470 From noreply at sourceforge.net Sun Dec 14 15:55:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 15:55:25 2003 Subject: [ python-Bugs-858016 ] Pathological case segmentation fault in issubclass Message-ID: Bugs item #858016, was opened at 2003-12-10 19:13 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Eric M. Hopper (omnifarious) Assigned to: Brett Cannon (bcannon) Summary: Pathological case segmentation fault in issubclass Initial Comment: This works for the PowerPC Python compiled with gcc 3.3 on OS X using fink. I suspect it's broader based than that, but I don't have the ability to check properly. Here's how to make it segment fault: x = (basestring,) for i in xrange(0, 1000000): x = (x,) issubclass(str, x) At least, it segment faults at the interactive prompt this way. I don't know if it does when it's executed from a file. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-12-14 12:55 Message: Logged In: YES user_id=357491 OK, consider my worldview fixed. =) I will add a check in the tuple unpacking 'for' loop to make sure it is only passing issubclass classes and not more tuples. Simple and shouldn't break very much code. Otherwise the code would have to keep a count and extra bookkeeping and it would get messy quickly. And I will take a look at isinstance, although this tuple feature was added in 2.3 for issubclass so it might not be an issue. And I will backport it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-12-13 17:08 Message: Logged In: YES user_id=31435 Yes, this needs to be fixed if it *can* be fixed without heroic effort or insane slowdown. Looks like it can be. Brett, the missing piece of your worldview here is that anywhere Python can be tricked into segfaulting is a kind of "security hole" -- it's not just mistakes we want to protect programmers from, we also want to bulletproof against hostile users, to the extent sanely possible. BTW, if issubclass() has this insecurity, I bet isinstance() does too (they were introduced & coded at the same time). ---------------------------------------------------------------------- Comment By: Eric M. Hopper (omnifarious) Date: 2003-12-11 09:54 Message: Logged In: YES user_id=313 Well, I think any case where the system segment faults unexpectedly is bad, regardless of how pathological it is. Personally, I think that issubclass should either have a recursion limit after which it throws an exception, or it shouldn't go into sub-tuples at all. The reason I made this test is that I read the description of the behavior of issublcass and found it rather strange, so I decided to push it to see how far it would go. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-12-10 20:28 Message: Logged In: YES user_id=357491 If you look at Object/abstract.c (line 2119 or so) for 2.4 CVS you will notice that PyObject_IsSubclass goes into a 'for' loop for each item in the tuple passed in and calls PyObject_IsSubclass . Unfortunately it makes no check for whether the argument it is passing is a class itself or not. This allows it to keep making calls as long as the second argument is either a class or a tuple. This is what is leads to the stack being blown and the subsequent segfault. Obvious solution is to put in a check that the argument about to be passed is a class itself so as to not have such a deep call chain. But since ``help(issubclass)`` actually makes the above use legit (it says using a tuple as a second argument is equivalent as passing each item to issubclass which is what it is doing, albeit in a rather uncommon and pointless way), is it worth putting the check in? Since this is such an obvious mis-use, I say no. But if someone else on python-dev steps in and says otherwise I will patch it. ---------------------------------------------------------------------- Comment By: Eric M. Hopper (omnifarious) Date: 2003-12-10 19:16 Message: Logged In: YES user_id=313 I forgot this: Python 2.3.2 (#1, Dec 4 2003, 09:13:58) [GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin Type "help", "copyright", "credits" or "license" for more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470 From noreply at sourceforge.net Sun Dec 14 16:09:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 16:09:10 2003 Subject: [ python-Bugs-858016 ] Pathological case segmentation fault in issubclass Message-ID: Bugs item #858016, was opened at 2003-12-10 22:13 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Eric M. Hopper (omnifarious) Assigned to: Brett Cannon (bcannon) Summary: Pathological case segmentation fault in issubclass Initial Comment: This works for the PowerPC Python compiled with gcc 3.3 on OS X using fink. I suspect it's broader based than that, but I don't have the ability to check properly. Here's how to make it segment fault: x = (basestring,) for i in xrange(0, 1000000): x = (x,) issubclass(str, x) At least, it segment faults at the interactive prompt this way. I don't know if it does when it's executed from a file. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-12-14 16:09 Message: Logged In: YES user_id=31435 I'm afraid that changing semantics needs to be run through the python-dev wringer first -- "shouldn't break very much code" isn't "shouldn't break any code". The *comments* in these functions make it appear that they never intended to support the OP's original code snippet, but the docs don't match. This leaves the intent a mystery, so it needs to be discussed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-12-14 15:55 Message: Logged In: YES user_id=357491 OK, consider my worldview fixed. =) I will add a check in the tuple unpacking 'for' loop to make sure it is only passing issubclass classes and not more tuples. Simple and shouldn't break very much code. Otherwise the code would have to keep a count and extra bookkeeping and it would get messy quickly. And I will take a look at isinstance, although this tuple feature was added in 2.3 for issubclass so it might not be an issue. And I will backport it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-12-13 20:08 Message: Logged In: YES user_id=31435 Yes, this needs to be fixed if it *can* be fixed without heroic effort or insane slowdown. Looks like it can be. Brett, the missing piece of your worldview here is that anywhere Python can be tricked into segfaulting is a kind of "security hole" -- it's not just mistakes we want to protect programmers from, we also want to bulletproof against hostile users, to the extent sanely possible. BTW, if issubclass() has this insecurity, I bet isinstance() does too (they were introduced & coded at the same time). ---------------------------------------------------------------------- Comment By: Eric M. Hopper (omnifarious) Date: 2003-12-11 12:54 Message: Logged In: YES user_id=313 Well, I think any case where the system segment faults unexpectedly is bad, regardless of how pathological it is. Personally, I think that issubclass should either have a recursion limit after which it throws an exception, or it shouldn't go into sub-tuples at all. The reason I made this test is that I read the description of the behavior of issublcass and found it rather strange, so I decided to push it to see how far it would go. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-12-10 23:28 Message: Logged In: YES user_id=357491 If you look at Object/abstract.c (line 2119 or so) for 2.4 CVS you will notice that PyObject_IsSubclass goes into a 'for' loop for each item in the tuple passed in and calls PyObject_IsSubclass . Unfortunately it makes no check for whether the argument it is passing is a class itself or not. This allows it to keep making calls as long as the second argument is either a class or a tuple. This is what is leads to the stack being blown and the subsequent segfault. Obvious solution is to put in a check that the argument about to be passed is a class itself so as to not have such a deep call chain. But since ``help(issubclass)`` actually makes the above use legit (it says using a tuple as a second argument is equivalent as passing each item to issubclass which is what it is doing, albeit in a rather uncommon and pointless way), is it worth putting the check in? Since this is such an obvious mis-use, I say no. But if someone else on python-dev steps in and says otherwise I will patch it. ---------------------------------------------------------------------- Comment By: Eric M. Hopper (omnifarious) Date: 2003-12-10 22:16 Message: Logged In: YES user_id=313 I forgot this: Python 2.3.2 (#1, Dec 4 2003, 09:13:58) [GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin Type "help", "copyright", "credits" or "license" for more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470 From noreply at sourceforge.net Sun Dec 14 19:41:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 19:41:03 2003 Subject: [ python-Bugs-860101 ] python-mode.el colorizing is broken in emacs21 Message-ID: Bugs item #860101, was opened at 2003-12-15 00:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860101&group_id=5470 Category: Demos and Tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Bowden (offense) Assigned to: Nobody/Anonymous (nobody) Summary: python-mode.el colorizing is broken in emacs21 Initial Comment: Something in the syntax detection is screwed up big time. The problem is that keywords are being highlighted in the middle of identifiers. For example in the line: os.rmdir(path) "dir" receives the keyword color and everything else is left default. python version: 2.3.2 emacs version: 21.3 OS: Debian/Unstable ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860101&group_id=5470 From noreply at sourceforge.net Sun Dec 14 20:47:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 20:47:51 2003 Subject: [ python-Bugs-853507 ] socket.recv() raises MemoryError exception (WindowsXP ONLY) Message-ID: Bugs item #853507, was opened at 2003-12-03 14:16 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853507&group_id=5470 Category: Windows >Group: 3rd Party >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Randy Wiser (randyw) >Assigned to: Tim Peters (tim_one) Summary: socket.recv() raises MemoryError exception (WindowsXP ONLY) Initial Comment: Calling socket.recv(size) with size starting at 3000000 and decreasing by approximately 1024 each time, quickly raises a MemoryError exception, although the process memory use does not exceed 30 Mbytes! Verified on Python 2.1, 2.3 and 2.3.2 (under Windows XP Professional ONLY version 5.1.2600 hotfix KB824146 if it matters :-) Cannot reproduce (test runs many iterations without fail) under Windows 2000 Professional or Server. To reproduce on XP, run attached files is separate shell windows: c:\> python hostMemErrSrv.py waiting for client on 3021 Connected by ('127.0.0.1', 1217) . . . . . . . . . . . . . . . . c:\> python hostMemErr.py MemoryError, hit return to exit. Traceback (most recent call last): File "hostMemErr.py", line 117, in ? main() File "hostMemErr.py", line 108, in main data = p.dataRecv(sz) File "hostMemErr.py", line 63, in dataRecv tmp = self.dataSocket.recv (nleft) File "", line 1, in recv MemoryError ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-12-14 20:47 Message: Logged In: YES user_id=31435 It's not crazy to ask WinXP for 3MB of memory in general, it's simply weird to pass a number that large to .recv() specifically. Sockets are a low-level facility, working directly with system network buffers, whose sizes are measured in KB rather than MB. Since we don't have Microsoft's socket implementation to stare at, we can't be sure, but it's possible that XP's implementation goes insane when fed unreasonable arguments. If so, I expect they'll eventually fix that. Regardless, I don't see anything here that's plausibly Python's doing (other than reporting back that the system malloc() returned NULL), so I'm closing this as 3rd-party, wontfix. ---------------------------------------------------------------------- Comment By: Randy Wiser (randyw) Date: 2003-12-03 20:16 Message: Logged In: YES user_id=215159 A quick test with Python 2.3 -i shows the following, so I'm guessing if at first WinXP claims no memory, try try again. Thanks for the quick response Tim. We'll try not to ask WinXP for 3 Mil. of memory unless we really need it. python -i hostMemErr.py MemoryError, hit return to exit. Traceback (most recent call last): File "hostMemErr.py", line 117, in ? main() File "hostMemErr.py", line 108, in main data = p.dataRecv(sz) File "hostMemErr.py", line 63, in dataRecv tmp = self.dataSocket.recv (nleft) MemoryError >>> s= 'z' * 3000000 Traceback (most recent call last): File "", line 1, in ? MemoryError >>> s= 'z' * 3000000 >>> s= 'z' * 3000000 >>> s= 'z' * 3000000 >>> s= 'z' * 30000000 >>> ^Z ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-12-03 14:28 Message: Logged In: YES user_id=31435 Python doesn't do anything differently across different flavors of Windows, so you're probably looking at a Microsoft bug, or an MS design limitation. Note that doing recv() with an argument in the millions isn't a sane thing to do to begin with. Unassigned from me, and reduced priority (I'm not going to do anything more on this; Randy, try writing equivalent code directly in C; if the same thing happens there, as appears likely, then your complaint should go to Microsoft). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853507&group_id=5470 From noreply at sourceforge.net Sun Dec 14 21:27:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 21:27:49 2003 Subject: [ python-Bugs-860134 ] socketmodule.c does not pickup all symbols with MS visC++ Message-ID: Bugs item #860134, was opened at 2003-12-14 21:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860134&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Frank Terhaar-Yonkers (frankty) Assigned to: Thomas Heller (theller) Summary: socketmodule.c does not pickup all symbols with MS visC++ Initial Comment: The symbol: socket.IP_HDRINCL does not exist is the Win32 Python binary I downloaded/installed of Python v2.3, nor does it appear when I compile 2.3.3RC1 with MS Visual C++. If I add the following to socketmodule.c: (per the example in the windows SDK ./Samples/netds/WinSock/iphdrinc/rawudp.c) #ifndef WIN32_LEAN_AND_MEAN #define WIN32_LEAN_AND_MEAN #endif #include #include All is well .. I've no idea what symbol to #ifdef this on as this is the first time I've compiled anything on "winders" :-) Any no idea if "lean_and_mean" is required - all I know is that it now works .. cheers, - Frank fty@employees.org ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860134&group_id=5470 From noreply at sourceforge.net Sun Dec 14 21:45:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 21:45:27 2003 Subject: [ python-Feature Requests-801847 ] Adding rsplit() to string and unicode objects. Message-ID: Feature Requests item #801847, was opened at 2003-09-06 20:52 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=801847&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: Accepted Priority: 4 Submitted By: Sean Reifschneider (jafo) Assigned to: Alex Martelli (aleax) Summary: Adding rsplit() to string and unicode objects. Initial Comment: I'm attaching patches to the library and documentation for implementing rsplit() on string and unicode objects. This works like split(), but working from the right. ./python -c 'print u"foo, bar, baz".rsplit(None, 1)' [u'foo, bar,', u'baz'] This was supposed to be against the CVS code, but I've had a heck of a time getting it checked out -- my checkout has been hung for half an hour now. The code patch is against the 2.3 release, the docs patch is against the CVS. My checkout got to docs, but I didn't have the code to a point where I could build and test it. Sean ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-14 21:45 Message: Logged In: YES user_id=6380 Perky, feel free to check it in! ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-12-13 14:45 Message: Logged In: YES user_id=55188 On my review, few bugs are found. >>> u'x\x00y\x00z'.rsplit(u'\x00', 1) zsh: bus error (core dumped) ./python >>> u'abcd'.rsplit(u'abcd') [u'abcd'] >>> 'a,b,c,d'.rsplit(u',', 2) [u'a', u'b', u'c,d'] And, unittests on Lib/test/test_strop.py should be moved to strings_test.py My revision for jafo's patch is available at http://people.freebsd.org/~perky/rsplit-perkyrev.diff ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-01 09:18 Message: Logged In: YES user_id=80475 Alex said he would take the patch from here. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-25 16:03 Message: Logged In: YES user_id=80475 Okay, I've got it from here! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-11-25 15:47 Message: Logged In: YES user_id=6380 OK, I'm in a generous mood today. I approve the idea. (I'm not going to review the code, that's up to Raymond and others). And Raymond can have a fillchar option to center() as well. I don't know what cook() was supposed to do, but if it's $ substitution, I recommend to keep that in a separate module for now. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-11-25 14:35 Message: Logged In: YES user_id=81797 If you are reading this and are interested in having this functionality in the standard Python library, please step forward and champion the effort. Obviously, I believe this is useful, or I wouldn't have spent the better part of a day building and testing it. However, I simply don't have the time to go through the politics of it. What needs to be done is a case needs to be further built for the presentation to the Python developement team. See Raymond's message below for a good list of what's needed there. Also see the thread on the python developers mailing list that I started in relation to this back in September. I will be happy to help out on this, but I just don't have the time to champion the adoption process. Thanks, Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-25 14:16 Message: Logged In: YES user_id=21627 It's very easy: find somebody with commit privileges to approve and commit the change. Failing to do so, write a library PEP, and ask for pronouncement. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-11-25 11:34 Message: Logged In: YES user_id=81797 Raymond, you've asked Guido about it on September 11, and he (apparently) explicitly stayed out of the discussion. I assumed that you had let him know you wanted his judgement on this and that his response was that he didn't want to be involved, leaving it up to the library "elite guard" instead. Did you actually copy Guido on your earlier request? Personally, I don't see the logic in "if we get only one string method". Python isn't for the Python core developers, it's for the users. If the users have several things that they want added, why the artificial limit on how many to accept? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-24 21:25 Message: Logged In: YES user_id=80475 Get Guido to approve the API change and I will be happy to complete the implementation, documentation, testing, etc. Advice: He will want *compelling* non-toy use cases and reasons why that a person wouldn't just implement it in pure python (saying that they aren't smart enough is not a reason). He is rarely ever persuaded by symmetry/completeness arguments along the lines of "we have an l-this so we have to have an r-that". If that were the case, tuples would have gotten index() and count() long ago. Language growth rate is one issue, the total number of string methods is another, and more importantly he seeks to minimize the number of small API compatabilities between versions which make it difficult to write code for Py2.4 that runs on Py2.2. Also, there are a number of strong competitors vying to be added as string methods. If we only get one new method, why is this one to be preferred over str.cook() for supporting Barry's simplified string substitutions Given only one new str API change, I would personally prefer to add an optional fillchar argument to str.center(). ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-11-24 17:45 Message: Logged In: YES user_id=139309 I'd have to say me too on this one, wake up please :) ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-29 01:38 Message: Logged In: YES user_id=81797 This seems to have generated nothing but positive comment from the folks on python-dev. Thoughts? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-22 14:17 Message: Logged In: YES user_id=80475 I'll review your patch when I get a chance. ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-09-22 09:10 Message: Logged In: YES user_id=99508 As a comment on the ease with which a programmer can get rsplit wrong, note that rhettinger's rsplit implementation is not correct: compare rsplit('foobarbaz', 'bar') with 'foobarbaz'.split('bar'). He forgot to reverse the separator if it's not None. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-11 19:55 Message: Logged In: YES user_id=80475 Guido, do you care to pronounce on this one? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-11 02:07 Message: Logged In: YES user_id=21627 There is PEP 2, which suggests to write a library PEP for proposal to extend the library. Now, this probably would be overkill for a single string method. However, I feel that there are already too many string methods, so I won't accept that patch. I'm not rejecting it, either, because I see that other maintainers might have a different opinion. In short, you should propose your change to python-dev, finding out what "a majority" of the maintainers thinks; you might also propose it on python-list, trying to collect reactions from users. It would then be good to summarize these discussions here (instead of carrying them out here). ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-10 16:40 Message: Logged In: YES user_id=81797 I realize that rsplit() can be implemented, because, well, I implemented it. The standard library is there to provide ready-to-use functionality so that users of python can concentrate on their program instead of concentrate on re-inventing the wheel. find() can be implemented with a short loop, split() can be implemented with find(), join() can be implemented with a short loop. Many things can be implemented with a little additional effort on the part of the user to develop or locate the code they're wanting. These little things can add up quickly and can have quite a dramatic impact on the programming experience in Python. Having to find or implement these functions will cause distraction from the code at hand, time lost while finding, implementing, testing, and maintaining the code in question. One of Python's strengths is a rich standard library. So, what are the guidelines for determining when it's rich enough? Why is it ok to suggest that users should get distracted from their code to go implement something else? Is there a policy that I'm not aware of that new functionality should be put in the cookbook instead of the standard library? Why is it being ignored that some programmers would find implementing rsplit() challenging? I'm not trying to be difficult here, I honestly can't understand the apparent change from having a rich library to a "batteries not included" stance. The response I got from #python when I mentioned having submitted the patch indicates to me that other experienced Python developers expect there to be an rsplit(). So, why is there so much resistance to adding something to the library? What are the guidelines for determining if something should be in the library? Sean ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-10 15:35 Message: Logged In: YES user_id=80475 I would classify this more as a technique than a fundamental string operation implemented by all stringlike objects (including UserString). Accordingly, I recommend that the patch be closed and a recipe posted in the ASPN cookbook - something along the lines of: >>> def rsplit(s, sep=None, maxsplit=-1): ... return [chunk[::-1] for chunk in s[::-1].split(sep, maxsplit)[::-1]] >>> rsplit(u"foo, bar, baz", None, 1) [u'foo, bar,', u'baz'] ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-10 15:15 Message: Logged In: YES user_id=81797 os.path.basename/os.path.dirname is an example of where you could use rsplit. One of the other #python folks said he had recently wanted rsplit for an application where he was getting the domain name and user part from a list of e-mail addresses, but found that some entries contained an "@" in the user part. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-10 13:08 Message: Logged In: YES user_id=21627 I questioned the usefulness because I could not think of a meaningful application. Now I see what a potential application could be, but I doubt its generality, because that approach would break if there could be two fields that have commas in them. I also disagree that symmetry can motivate usefulness: I also doubt that all of the r* functions are useful, but they cannot be removed for backwards compatibility. The fact that rsplit would fit together with the other r* functions indicates that adding rsplit would provide symmetry, not that it would provide usefulness. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-07 20:56 Message: Logged In: YES user_id=81797 Can you provide more details about why the usefulness of this function is in question? First I would like to tell you the story of it coming to be, then I will answer your incomplete question with a (probably) incomplete answer. I had a device which sent me comma-separated fields, but one of the fields in the middle could contain a comma. The answer that seemed obvious to me was to use split with a maxsplit to get the fields up to that field, and then a rsplit with a maxsplit on the remainder. When I mentioned on #python that I was implementing rsplit, 4 other fellow python users replied right away that they had been wanting it. To answer your question, it's useful because people using strings are used to having r*() functions like rfind and rstrip. The lack of rsplit is kind of glaring in this context. Really, though, it's useful because otherwise people have to implement -- often badly. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-07 15:49 Message: Logged In: YES user_id=21627 Why is this function useful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=801847&group_id=5470 From noreply at sourceforge.net Sun Dec 14 22:45:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 22:45:44 2003 Subject: [ python-Bugs-860155 ] mistake in StringIO.__doc__ Message-ID: Bugs item #860155, was opened at 2003-12-15 03:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860155&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Keel Thaan (kmt12) Assigned to: Nobody/Anonymous (nobody) Summary: mistake in StringIO.__doc__ Initial Comment: [Confirmed in both Python 2.1.3 and Python 2.3.2] There's an error in the doc string for the StringIO module; it contains this line: buf = f.readline() # read until end of line ('\n') or EOF but since that \n isn't escaped, it gets interpreted as an actual newline, so printing StringIO.__doc__ results in this: buf = f.readline() # read until end of line (' ') or EOF I realize this isn't that big a deal, but given how utterly trivial it is to fix . . . Simply making the doc string a raw string would take care of it. (You could of course double the backslash instead, but that has the disadvantage of affecting the readability of the doc string within the source file itself.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860155&group_id=5470 From noreply at sourceforge.net Sun Dec 14 22:47:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 22:47:43 2003 Subject: [ python-Bugs-860155 ] mistake in StringIO.__doc__ Message-ID: Bugs item #860155, was opened at 2003-12-15 03:45 Message generated for change (Settings changed) made by kmt12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860155&group_id=5470 Category: None Group: None Status: Open Resolution: None >Priority: 2 Submitted By: Keel Thaan (kmt12) Assigned to: Nobody/Anonymous (nobody) Summary: mistake in StringIO.__doc__ Initial Comment: [Confirmed in both Python 2.1.3 and Python 2.3.2] There's an error in the doc string for the StringIO module; it contains this line: buf = f.readline() # read until end of line ('\n') or EOF but since that \n isn't escaped, it gets interpreted as an actual newline, so printing StringIO.__doc__ results in this: buf = f.readline() # read until end of line (' ') or EOF I realize this isn't that big a deal, but given how utterly trivial it is to fix . . . Simply making the doc string a raw string would take care of it. (You could of course double the backslash instead, but that has the disadvantage of affecting the readability of the doc string within the source file itself.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860155&group_id=5470 From noreply at sourceforge.net Sun Dec 14 23:26:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 23:26:36 2003 Subject: [ python-Bugs-856841 ] a exception ocurrs when compiling a Python file Message-ID: Bugs item #856841, was opened at 2003-12-09 07:57 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856841&group_id=5470 Category: Parser/Compiler Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Pablo Yabo (pablo_yabo) Assigned to: Nobody/Anonymous (nobody) Summary: a exception ocurrs when compiling a Python file Initial Comment: a exception ocurrs when compiling some big python files (more than 250kb) using the debug library (python22_d.dll). When using the release library in the release version of my application the files compile succesfully. Attached is the stack trace. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-12-14 23:26 Message: Logged In: YES user_id=593130 I do not believe this is a compiler bug. While compiler input may by theoretically unbounded, all practical compilers have practical limitations that often depend, in part, on the amount of memory on your particular system. This is one reason for import and include mechanisms. As I understand the stack trace, the exception occured during an attempt to reallocate memory (ie, move an object to a larger block). (Including Python's exception trace would make this clearer). I presume debug mode uses more memory so you hit the limit sooner with that mode. Your solutions are to either 1) add more memory to your computer (should probably work) or try on a system with more memory or 2) break your source into more modules (certain to work if the problem is, indeed, simply running out of memory). 250K is not merely big but huge. The largest file in the standard lib is under 100K and the median is around 10K. Unless you have more reason to think this a bug, please withdraw or close. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856841&group_id=5470 From noreply at sourceforge.net Mon Dec 15 04:51:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 15 04:51:16 2003 Subject: [ python-Bugs-860242 ] PythonIDE does not save for PythonLauncher Message-ID: Bugs item #860242, was opened at 2003-12-15 10:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860242&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: PythonIDE does not save for PythonLauncher Initial Comment: PythonIDE Save options has a selection for the (now defunct) PythonW creator code, but not for PythonLauncher. The naming in the dialog could also be a little clearer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860242&group_id=5470 From noreply at sourceforge.net Mon Dec 15 05:04:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 15 05:04:19 2003 Subject: [ python-Bugs-856841 ] a exception ocurrs when compiling a Python file Message-ID: Bugs item #856841, was opened at 2003-12-09 13:57 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856841&group_id=5470 Category: Parser/Compiler Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Pablo Yabo (pablo_yabo) Assigned to: Nobody/Anonymous (nobody) Summary: a exception ocurrs when compiling a Python file Initial Comment: a exception ocurrs when compiling some big python files (more than 250kb) using the debug library (python22_d.dll). When using the release library in the release version of my application the files compile succesfully. Attached is the stack trace. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-12-15 11:04 Message: Logged In: YES user_id=45365 I agree with the original poster that this is a bug. While it may not be fixable (and definitely not in the general case) you should get a decent error message from Python (at the very least a MemoryError), not a crash of the interpreter. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-12-15 05:26 Message: Logged In: YES user_id=593130 I do not believe this is a compiler bug. While compiler input may by theoretically unbounded, all practical compilers have practical limitations that often depend, in part, on the amount of memory on your particular system. This is one reason for import and include mechanisms. As I understand the stack trace, the exception occured during an attempt to reallocate memory (ie, move an object to a larger block). (Including Python's exception trace would make this clearer). I presume debug mode uses more memory so you hit the limit sooner with that mode. Your solutions are to either 1) add more memory to your computer (should probably work) or try on a system with more memory or 2) break your source into more modules (certain to work if the problem is, indeed, simply running out of memory). 250K is not merely big but huge. The largest file in the standard lib is under 100K and the median is around 10K. Unless you have more reason to think this a bug, please withdraw or close. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856841&group_id=5470 From noreply at sourceforge.net Mon Dec 15 05:17:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 15 05:17:07 2003 Subject: [ python-Bugs-860155 ] mistake in StringIO.__doc__ Message-ID: Bugs item #860155, was opened at 2003-12-15 04:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860155&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 2 Submitted By: Keel Thaan (kmt12) Assigned to: Nobody/Anonymous (nobody) Summary: mistake in StringIO.__doc__ Initial Comment: [Confirmed in both Python 2.1.3 and Python 2.3.2] There's an error in the doc string for the StringIO module; it contains this line: buf = f.readline() # read until end of line ('\n') or EOF but since that \n isn't escaped, it gets interpreted as an actual newline, so printing StringIO.__doc__ results in this: buf = f.readline() # read until end of line (' ') or EOF I realize this isn't that big a deal, but given how utterly trivial it is to fix . . . Simply making the doc string a raw string would take care of it. (You could of course double the backslash instead, but that has the disadvantage of affecting the readability of the doc string within the source file itself.) ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2003-12-15 11:17 Message: Logged In: YES user_id=89016 Checked in a fix as Lib/StringIO.py 1.31 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860155&group_id=5470 From noreply at sourceforge.net Mon Dec 15 05:29:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 15 05:29:26 2003 Subject: [ python-Bugs-860101 ] python-mode.el colorizing is broken in emacs21 Message-ID: Bugs item #860101, was opened at 2003-12-15 00:41 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860101&group_id=5470 Category: Demos and Tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Bowden (offense) Assigned to: Nobody/Anonymous (nobody) Summary: python-mode.el colorizing is broken in emacs21 Initial Comment: Something in the syntax detection is screwed up big time. The problem is that keywords are being highlighted in the middle of identifiers. For example in the line: os.rmdir(path) "dir" receives the keyword color and everything else is left default. python version: 2.3.2 emacs version: 21.3 OS: Debian/Unstable ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-12-15 10:29 Message: Logged In: YES user_id=6656 a) this should probably be submitted to the python-mode project. b) at first blush, this looks more likely to be a local config problem... 'dir' isn't a python keyword, for one thing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860101&group_id=5470 From noreply at sourceforge.net Mon Dec 15 11:27:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 15 11:28:45 2003 Subject: [ python-Bugs-860134 ] socketmodule.c does not pickup all symbols with MS visC++ Message-ID: Bugs item #860134, was opened at 2003-12-15 03:27 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860134&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Frank Terhaar-Yonkers (frankty) >Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule.c does not pickup all symbols with MS visC++ Initial Comment: The symbol: socket.IP_HDRINCL does not exist is the Win32 Python binary I downloaded/installed of Python v2.3, nor does it appear when I compile 2.3.3RC1 with MS Visual C++. If I add the following to socketmodule.c: (per the example in the windows SDK ./Samples/netds/WinSock/iphdrinc/rawudp.c) #ifndef WIN32_LEAN_AND_MEAN #define WIN32_LEAN_AND_MEAN #endif #include #include All is well .. I've no idea what symbol to #ifdef this on as this is the first time I've compiled anything on "winders" :-) Any no idea if "lean_and_mean" is required - all I know is that it now works .. cheers, - Frank fty@employees.org ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-12-15 17:27 Message: Logged In: YES user_id=11105 Please don't assign bug reports to a developer (especially not me ;-). Usually they stay unassigned until someone cares (when he has the time). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860134&group_id=5470 From noreply at sourceforge.net Mon Dec 15 12:40:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 15 12:41:02 2003 Subject: [ python-Bugs-860101 ] python-mode.el colorizing is broken in emacs21 Message-ID: Bugs item #860101, was opened at 2003-12-14 18:41 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860101&group_id=5470 Category: Demos and Tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Bowden (offense) Assigned to: Nobody/Anonymous (nobody) Summary: python-mode.el colorizing is broken in emacs21 Initial Comment: Something in the syntax detection is screwed up big time. The problem is that keywords are being highlighted in the middle of identifiers. For example in the line: os.rmdir(path) "dir" receives the keyword color and everything else is left default. python version: 2.3.2 emacs version: 21.3 OS: Debian/Unstable ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-12-15 11:40 Message: Logged In: YES user_id=44345 Known problem. I inserted the incorrect change to the python- mode source. I wasn't aware it had been incorporated into the version of python-mode.el distributed with Python. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-12-15 04:29 Message: Logged In: YES user_id=6656 a) this should probably be submitted to the python-mode project. b) at first blush, this looks more likely to be a local config problem... 'dir' isn't a python keyword, for one thing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860101&group_id=5470 From noreply at sourceforge.net Mon Dec 15 13:07:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 15 13:07:28 2003 Subject: [ python-Bugs-860101 ] python-mode.el colorizing is broken in emacs21 Message-ID: Bugs item #860101, was opened at 2003-12-14 18:41 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860101&group_id=5470 Category: Demos and Tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Bowden (offense) Assigned to: Nobody/Anonymous (nobody) Summary: python-mode.el colorizing is broken in emacs21 Initial Comment: Something in the syntax detection is screwed up big time. The problem is that keywords are being highlighted in the middle of identifiers. For example in the line: os.rmdir(path) "dir" receives the keyword color and everything else is left default. python version: 2.3.2 emacs version: 21.3 OS: Debian/Unstable ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-12-15 12:07 Message: Logged In: YES user_id=44345 Please try changing the lines which use kw3 to define a font-lock pattern to ;; builtins when they don't appear as object attributes (cons (concat "\(\b\|[.]\)\(" kw3 "\)\b[ \n\t(]") 2) and let me know if that works for you. (The goal is to highlight variables which might shadow builtins.) ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-12-15 11:40 Message: Logged In: YES user_id=44345 Known problem. I inserted the incorrect change to the python- mode source. I wasn't aware it had been incorporated into the version of python-mode.el distributed with Python. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-12-15 04:29 Message: Logged In: YES user_id=6656 a) this should probably be submitted to the python-mode project. b) at first blush, this looks more likely to be a local config problem... 'dir' isn't a python keyword, for one thing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860101&group_id=5470 From noreply at sourceforge.net Mon Dec 15 13:58:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 15 13:58:20 2003 Subject: [ python-Feature Requests-801847 ] Adding rsplit() to string and unicode objects. Message-ID: Feature Requests item #801847, was opened at 2003-09-07 09:52 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=801847&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: Accepted Priority: 4 Submitted By: Sean Reifschneider (jafo) Assigned to: Alex Martelli (aleax) Summary: Adding rsplit() to string and unicode objects. Initial Comment: I'm attaching patches to the library and documentation for implementing rsplit() on string and unicode objects. This works like split(), but working from the right. ./python -c 'print u"foo, bar, baz".rsplit(None, 1)' [u'foo, bar,', u'baz'] This was supposed to be against the CVS code, but I've had a heck of a time getting it checked out -- my checkout has been hung for half an hour now. The code patch is against the 2.3 release, the docs patch is against the CVS. My checkout got to docs, but I didn't have the code to a point where I could build and test it. Sean ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-12-16 03:58 Message: Logged In: YES user_id=55188 Yo. Just checked in. I don't have a permission to close this entry. Can anybody help? :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-15 11:45 Message: Logged In: YES user_id=6380 Perky, feel free to check it in! ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-12-14 04:45 Message: Logged In: YES user_id=55188 On my review, few bugs are found. >>> u'x\x00y\x00z'.rsplit(u'\x00', 1) zsh: bus error (core dumped) ./python >>> u'abcd'.rsplit(u'abcd') [u'abcd'] >>> 'a,b,c,d'.rsplit(u',', 2) [u'a', u'b', u'c,d'] And, unittests on Lib/test/test_strop.py should be moved to strings_test.py My revision for jafo's patch is available at http://people.freebsd.org/~perky/rsplit-perkyrev.diff ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-01 23:18 Message: Logged In: YES user_id=80475 Alex said he would take the patch from here. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-26 06:03 Message: Logged In: YES user_id=80475 Okay, I've got it from here! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-11-26 05:47 Message: Logged In: YES user_id=6380 OK, I'm in a generous mood today. I approve the idea. (I'm not going to review the code, that's up to Raymond and others). And Raymond can have a fillchar option to center() as well. I don't know what cook() was supposed to do, but if it's $ substitution, I recommend to keep that in a separate module for now. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-11-26 04:35 Message: Logged In: YES user_id=81797 If you are reading this and are interested in having this functionality in the standard Python library, please step forward and champion the effort. Obviously, I believe this is useful, or I wouldn't have spent the better part of a day building and testing it. However, I simply don't have the time to go through the politics of it. What needs to be done is a case needs to be further built for the presentation to the Python developement team. See Raymond's message below for a good list of what's needed there. Also see the thread on the python developers mailing list that I started in relation to this back in September. I will be happy to help out on this, but I just don't have the time to champion the adoption process. Thanks, Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-26 04:16 Message: Logged In: YES user_id=21627 It's very easy: find somebody with commit privileges to approve and commit the change. Failing to do so, write a library PEP, and ask for pronouncement. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-11-26 01:34 Message: Logged In: YES user_id=81797 Raymond, you've asked Guido about it on September 11, and he (apparently) explicitly stayed out of the discussion. I assumed that you had let him know you wanted his judgement on this and that his response was that he didn't want to be involved, leaving it up to the library "elite guard" instead. Did you actually copy Guido on your earlier request? Personally, I don't see the logic in "if we get only one string method". Python isn't for the Python core developers, it's for the users. If the users have several things that they want added, why the artificial limit on how many to accept? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-25 11:25 Message: Logged In: YES user_id=80475 Get Guido to approve the API change and I will be happy to complete the implementation, documentation, testing, etc. Advice: He will want *compelling* non-toy use cases and reasons why that a person wouldn't just implement it in pure python (saying that they aren't smart enough is not a reason). He is rarely ever persuaded by symmetry/completeness arguments along the lines of "we have an l-this so we have to have an r-that". If that were the case, tuples would have gotten index() and count() long ago. Language growth rate is one issue, the total number of string methods is another, and more importantly he seeks to minimize the number of small API compatabilities between versions which make it difficult to write code for Py2.4 that runs on Py2.2. Also, there are a number of strong competitors vying to be added as string methods. If we only get one new method, why is this one to be preferred over str.cook() for supporting Barry's simplified string substitutions Given only one new str API change, I would personally prefer to add an optional fillchar argument to str.center(). ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-11-25 07:45 Message: Logged In: YES user_id=139309 I'd have to say me too on this one, wake up please :) ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-29 14:38 Message: Logged In: YES user_id=81797 This seems to have generated nothing but positive comment from the folks on python-dev. Thoughts? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-23 03:17 Message: Logged In: YES user_id=80475 I'll review your patch when I get a chance. ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-09-22 22:10 Message: Logged In: YES user_id=99508 As a comment on the ease with which a programmer can get rsplit wrong, note that rhettinger's rsplit implementation is not correct: compare rsplit('foobarbaz', 'bar') with 'foobarbaz'.split('bar'). He forgot to reverse the separator if it's not None. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-12 08:55 Message: Logged In: YES user_id=80475 Guido, do you care to pronounce on this one? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-11 15:07 Message: Logged In: YES user_id=21627 There is PEP 2, which suggests to write a library PEP for proposal to extend the library. Now, this probably would be overkill for a single string method. However, I feel that there are already too many string methods, so I won't accept that patch. I'm not rejecting it, either, because I see that other maintainers might have a different opinion. In short, you should propose your change to python-dev, finding out what "a majority" of the maintainers thinks; you might also propose it on python-list, trying to collect reactions from users. It would then be good to summarize these discussions here (instead of carrying them out here). ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-11 05:40 Message: Logged In: YES user_id=81797 I realize that rsplit() can be implemented, because, well, I implemented it. The standard library is there to provide ready-to-use functionality so that users of python can concentrate on their program instead of concentrate on re-inventing the wheel. find() can be implemented with a short loop, split() can be implemented with find(), join() can be implemented with a short loop. Many things can be implemented with a little additional effort on the part of the user to develop or locate the code they're wanting. These little things can add up quickly and can have quite a dramatic impact on the programming experience in Python. Having to find or implement these functions will cause distraction from the code at hand, time lost while finding, implementing, testing, and maintaining the code in question. One of Python's strengths is a rich standard library. So, what are the guidelines for determining when it's rich enough? Why is it ok to suggest that users should get distracted from their code to go implement something else? Is there a policy that I'm not aware of that new functionality should be put in the cookbook instead of the standard library? Why is it being ignored that some programmers would find implementing rsplit() challenging? I'm not trying to be difficult here, I honestly can't understand the apparent change from having a rich library to a "batteries not included" stance. The response I got from #python when I mentioned having submitted the patch indicates to me that other experienced Python developers expect there to be an rsplit(). So, why is there so much resistance to adding something to the library? What are the guidelines for determining if something should be in the library? Sean ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-11 04:35 Message: Logged In: YES user_id=80475 I would classify this more as a technique than a fundamental string operation implemented by all stringlike objects (including UserString). Accordingly, I recommend that the patch be closed and a recipe posted in the ASPN cookbook - something along the lines of: >>> def rsplit(s, sep=None, maxsplit=-1): ... return [chunk[::-1] for chunk in s[::-1].split(sep, maxsplit)[::-1]] >>> rsplit(u"foo, bar, baz", None, 1) [u'foo, bar,', u'baz'] ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-11 04:15 Message: Logged In: YES user_id=81797 os.path.basename/os.path.dirname is an example of where you could use rsplit. One of the other #python folks said he had recently wanted rsplit for an application where he was getting the domain name and user part from a list of e-mail addresses, but found that some entries contained an "@" in the user part. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-11 02:08 Message: Logged In: YES user_id=21627 I questioned the usefulness because I could not think of a meaningful application. Now I see what a potential application could be, but I doubt its generality, because that approach would break if there could be two fields that have commas in them. I also disagree that symmetry can motivate usefulness: I also doubt that all of the r* functions are useful, but they cannot be removed for backwards compatibility. The fact that rsplit would fit together with the other r* functions indicates that adding rsplit would provide symmetry, not that it would provide usefulness. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-08 09:56 Message: Logged In: YES user_id=81797 Can you provide more details about why the usefulness of this function is in question? First I would like to tell you the story of it coming to be, then I will answer your incomplete question with a (probably) incomplete answer. I had a device which sent me comma-separated fields, but one of the fields in the middle could contain a comma. The answer that seemed obvious to me was to use split with a maxsplit to get the fields up to that field, and then a rsplit with a maxsplit on the remainder. When I mentioned on #python that I was implementing rsplit, 4 other fellow python users replied right away that they had been wanting it. To answer your question, it's useful because people using strings are used to having r*() functions like rfind and rstrip. The lack of rsplit is kind of glaring in this context. Really, though, it's useful because otherwise people have to implement -- often badly. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-08 04:49 Message: Logged In: YES user_id=21627 Why is this function useful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=801847&group_id=5470 From noreply at sourceforge.net Mon Dec 15 14:11:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 15 14:11:35 2003 Subject: [ python-Bugs-860515 ] fileinput does not use universal input Message-ID: Bugs item #860515, was opened at 2003-12-15 11:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860515&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Nobody/Anonymous (nobody) Summary: fileinput does not use universal input Initial Comment: In Python 2.3.0 the fileinput module does not appear to use universal line ending mode for reading files. I found this using MacPython 2.3 (via the binary installer) but looking at the module it appears to be vanilla code. I confess I didn't see where the files were opened, so I cannot suggest a fix. Sample code: import fileinput for line in fileinput.input(): print line[0:20] try this with text files that have some other platform's line endings. For me, it works on MacOS X for files with unix line endings, but fails if the file(s) have Mac line endings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860515&group_id=5470 From noreply at sourceforge.net Mon Dec 15 14:38:43 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 15 14:38:47 2003 Subject: [ python-Feature Requests-801847 ] Adding rsplit() to string and unicode objects. Message-ID: Feature Requests item #801847, was opened at 2003-09-06 20:52 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=801847&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: Accepted Priority: 4 Submitted By: Sean Reifschneider (jafo) >Assigned to: Raymond Hettinger (rhettinger) Summary: Adding rsplit() to string and unicode objects. Initial Comment: I'm attaching patches to the library and documentation for implementing rsplit() on string and unicode objects. This works like split(), but working from the right. ./python -c 'print u"foo, bar, baz".rsplit(None, 1)' [u'foo, bar,', u'baz'] This was supposed to be against the CVS code, but I've had a heck of a time getting it checked out -- my checkout has been hung for half an hour now. The code patch is against the 2.3 release, the docs patch is against the CVS. My checkout got to docs, but I didn't have the code to a point where I could build and test it. Sean ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-15 14:38 Message: Logged In: YES user_id=6380 I could just close it for you, but I'll make it an exercise for you & Raymond to figure out how to set your developer perms properly. :-) ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-12-15 13:58 Message: Logged In: YES user_id=55188 Yo. Just checked in. I don't have a permission to close this entry. Can anybody help? :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-14 21:45 Message: Logged In: YES user_id=6380 Perky, feel free to check it in! ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-12-13 14:45 Message: Logged In: YES user_id=55188 On my review, few bugs are found. >>> u'x\x00y\x00z'.rsplit(u'\x00', 1) zsh: bus error (core dumped) ./python >>> u'abcd'.rsplit(u'abcd') [u'abcd'] >>> 'a,b,c,d'.rsplit(u',', 2) [u'a', u'b', u'c,d'] And, unittests on Lib/test/test_strop.py should be moved to strings_test.py My revision for jafo's patch is available at http://people.freebsd.org/~perky/rsplit-perkyrev.diff ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-01 09:18 Message: Logged In: YES user_id=80475 Alex said he would take the patch from here. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-25 16:03 Message: Logged In: YES user_id=80475 Okay, I've got it from here! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-11-25 15:47 Message: Logged In: YES user_id=6380 OK, I'm in a generous mood today. I approve the idea. (I'm not going to review the code, that's up to Raymond and others). And Raymond can have a fillchar option to center() as well. I don't know what cook() was supposed to do, but if it's $ substitution, I recommend to keep that in a separate module for now. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-11-25 14:35 Message: Logged In: YES user_id=81797 If you are reading this and are interested in having this functionality in the standard Python library, please step forward and champion the effort. Obviously, I believe this is useful, or I wouldn't have spent the better part of a day building and testing it. However, I simply don't have the time to go through the politics of it. What needs to be done is a case needs to be further built for the presentation to the Python developement team. See Raymond's message below for a good list of what's needed there. Also see the thread on the python developers mailing list that I started in relation to this back in September. I will be happy to help out on this, but I just don't have the time to champion the adoption process. Thanks, Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-25 14:16 Message: Logged In: YES user_id=21627 It's very easy: find somebody with commit privileges to approve and commit the change. Failing to do so, write a library PEP, and ask for pronouncement. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-11-25 11:34 Message: Logged In: YES user_id=81797 Raymond, you've asked Guido about it on September 11, and he (apparently) explicitly stayed out of the discussion. I assumed that you had let him know you wanted his judgement on this and that his response was that he didn't want to be involved, leaving it up to the library "elite guard" instead. Did you actually copy Guido on your earlier request? Personally, I don't see the logic in "if we get only one string method". Python isn't for the Python core developers, it's for the users. If the users have several things that they want added, why the artificial limit on how many to accept? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-24 21:25 Message: Logged In: YES user_id=80475 Get Guido to approve the API change and I will be happy to complete the implementation, documentation, testing, etc. Advice: He will want *compelling* non-toy use cases and reasons why that a person wouldn't just implement it in pure python (saying that they aren't smart enough is not a reason). He is rarely ever persuaded by symmetry/completeness arguments along the lines of "we have an l-this so we have to have an r-that". If that were the case, tuples would have gotten index() and count() long ago. Language growth rate is one issue, the total number of string methods is another, and more importantly he seeks to minimize the number of small API compatabilities between versions which make it difficult to write code for Py2.4 that runs on Py2.2. Also, there are a number of strong competitors vying to be added as string methods. If we only get one new method, why is this one to be preferred over str.cook() for supporting Barry's simplified string substitutions Given only one new str API change, I would personally prefer to add an optional fillchar argument to str.center(). ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-11-24 17:45 Message: Logged In: YES user_id=139309 I'd have to say me too on this one, wake up please :) ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-29 01:38 Message: Logged In: YES user_id=81797 This seems to have generated nothing but positive comment from the folks on python-dev. Thoughts? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-22 14:17 Message: Logged In: YES user_id=80475 I'll review your patch when I get a chance. ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-09-22 09:10 Message: Logged In: YES user_id=99508 As a comment on the ease with which a programmer can get rsplit wrong, note that rhettinger's rsplit implementation is not correct: compare rsplit('foobarbaz', 'bar') with 'foobarbaz'.split('bar'). He forgot to reverse the separator if it's not None. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-11 19:55 Message: Logged In: YES user_id=80475 Guido, do you care to pronounce on this one? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-11 02:07 Message: Logged In: YES user_id=21627 There is PEP 2, which suggests to write a library PEP for proposal to extend the library. Now, this probably would be overkill for a single string method. However, I feel that there are already too many string methods, so I won't accept that patch. I'm not rejecting it, either, because I see that other maintainers might have a different opinion. In short, you should propose your change to python-dev, finding out what "a majority" of the maintainers thinks; you might also propose it on python-list, trying to collect reactions from users. It would then be good to summarize these discussions here (instead of carrying them out here). ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-10 16:40 Message: Logged In: YES user_id=81797 I realize that rsplit() can be implemented, because, well, I implemented it. The standard library is there to provide ready-to-use functionality so that users of python can concentrate on their program instead of concentrate on re-inventing the wheel. find() can be implemented with a short loop, split() can be implemented with find(), join() can be implemented with a short loop. Many things can be implemented with a little additional effort on the part of the user to develop or locate the code they're wanting. These little things can add up quickly and can have quite a dramatic impact on the programming experience in Python. Having to find or implement these functions will cause distraction from the code at hand, time lost while finding, implementing, testing, and maintaining the code in question. One of Python's strengths is a rich standard library. So, what are the guidelines for determining when it's rich enough? Why is it ok to suggest that users should get distracted from their code to go implement something else? Is there a policy that I'm not aware of that new functionality should be put in the cookbook instead of the standard library? Why is it being ignored that some programmers would find implementing rsplit() challenging? I'm not trying to be difficult here, I honestly can't understand the apparent change from having a rich library to a "batteries not included" stance. The response I got from #python when I mentioned having submitted the patch indicates to me that other experienced Python developers expect there to be an rsplit(). So, why is there so much resistance to adding something to the library? What are the guidelines for determining if something should be in the library? Sean ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-10 15:35 Message: Logged In: YES user_id=80475 I would classify this more as a technique than a fundamental string operation implemented by all stringlike objects (including UserString). Accordingly, I recommend that the patch be closed and a recipe posted in the ASPN cookbook - something along the lines of: >>> def rsplit(s, sep=None, maxsplit=-1): ... return [chunk[::-1] for chunk in s[::-1].split(sep, maxsplit)[::-1]] >>> rsplit(u"foo, bar, baz", None, 1) [u'foo, bar,', u'baz'] ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-10 15:15 Message: Logged In: YES user_id=81797 os.path.basename/os.path.dirname is an example of where you could use rsplit. One of the other #python folks said he had recently wanted rsplit for an application where he was getting the domain name and user part from a list of e-mail addresses, but found that some entries contained an "@" in the user part. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-10 13:08 Message: Logged In: YES user_id=21627 I questioned the usefulness because I could not think of a meaningful application. Now I see what a potential application could be, but I doubt its generality, because that approach would break if there could be two fields that have commas in them. I also disagree that symmetry can motivate usefulness: I also doubt that all of the r* functions are useful, but they cannot be removed for backwards compatibility. The fact that rsplit would fit together with the other r* functions indicates that adding rsplit would provide symmetry, not that it would provide usefulness. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-07 20:56 Message: Logged In: YES user_id=81797 Can you provide more details about why the usefulness of this function is in question? First I would like to tell you the story of it coming to be, then I will answer your incomplete question with a (probably) incomplete answer. I had a device which sent me comma-separated fields, but one of the fields in the middle could contain a comma. The answer that seemed obvious to me was to use split with a maxsplit to get the fields up to that field, and then a rsplit with a maxsplit on the remainder. When I mentioned on #python that I was implementing rsplit, 4 other fellow python users replied right away that they had been wanting it. To answer your question, it's useful because people using strings are used to having r*() functions like rfind and rstrip. The lack of rsplit is kind of glaring in this context. Really, though, it's useful because otherwise people have to implement -- often badly. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-07 15:49 Message: Logged In: YES user_id=21627 Why is this function useful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=801847&group_id=5470 From noreply at sourceforge.net Mon Dec 15 14:45:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 15 14:45:54 2003 Subject: [ python-Bugs-860134 ] socketmodule.c does not pickup all symbols with MS visC++ Message-ID: Bugs item #860134, was opened at 2003-12-14 21:27 Message generated for change (Comment added) made by frankty You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860134&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Frank Terhaar-Yonkers (frankty) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule.c does not pickup all symbols with MS visC++ Initial Comment: The symbol: socket.IP_HDRINCL does not exist is the Win32 Python binary I downloaded/installed of Python v2.3, nor does it appear when I compile 2.3.3RC1 with MS Visual C++. If I add the following to socketmodule.c: (per the example in the windows SDK ./Samples/netds/WinSock/iphdrinc/rawudp.c) #ifndef WIN32_LEAN_AND_MEAN #define WIN32_LEAN_AND_MEAN #endif #include #include All is well .. I've no idea what symbol to #ifdef this on as this is the first time I've compiled anything on "winders" :-) Any no idea if "lean_and_mean" is required - all I know is that it now works .. cheers, - Frank fty@employees.org ---------------------------------------------------------------------- >Comment By: Frank Terhaar-Yonkers (frankty) Date: 2003-12-15 14:45 Message: Logged In: YES user_id=931285 I have NO IDEA how it got assigned to you. I don't even know who you are .. Sorry for any hassle. cheers - Frank ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-12-15 11:27 Message: Logged In: YES user_id=11105 Please don't assign bug reports to a developer (especially not me ;-). Usually they stay unassigned until someone cares (when he has the time). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860134&group_id=5470 From noreply at sourceforge.net Mon Dec 15 15:06:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 15 15:06:23 2003 Subject: [ python-Bugs-860547 ] Core dump problems Message-ID: Bugs item #860547, was opened at 2003-12-15 20:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860547&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Draper (crunch) Assigned to: Nobody/Anonymous (nobody) Summary: Core dump problems Initial Comment: Tried to install Python 2.3.3c1 It keeps core dumping (leaving python.core). I'm not doing anything strange, just documented stuff from the manuals. I tried 'gdb -c python.core' and then using 'back', but there are no labels compiled in (I hate that...); how can I get the labels to be included? "./configure --debug" doesn't work. I assume without the labels the numbers are meaningless. Running this under OpenBSD 3.2. Then, where should I submit my core dump (if anywhere?)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860547&group_id=5470 From noreply at sourceforge.net Mon Dec 15 16:08:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 15 16:08:10 2003 Subject: [ python-Bugs-860547 ] Core dump problems Message-ID: Bugs item #860547, was opened at 2003-12-15 20:06 Message generated for change (Comment added) made by crunch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860547&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Draper (crunch) Assigned to: Nobody/Anonymous (nobody) Summary: Core dump problems Initial Comment: Tried to install Python 2.3.3c1 It keeps core dumping (leaving python.core). I'm not doing anything strange, just documented stuff from the manuals. I tried 'gdb -c python.core' and then using 'back', but there are no labels compiled in (I hate that...); how can I get the labels to be included? "./configure --debug" doesn't work. I assume without the labels the numbers are meaningless. Running this under OpenBSD 3.2. Then, where should I submit my core dump (if anywhere?)? ---------------------------------------------------------------------- >Comment By: John Draper (crunch) Date: 2003-12-15 21:08 Message: Logged In: YES user_id=61606 Further details on the Python core dump: It core dumps (segmentation fault) when I check the database for a certain key. The offending statement is: x=database.has_key(keystring). database is open and otherwise normal. The database is "gdbm-1.8.3". The offending key is "3012a3ec5c796329fee7c242d4df00d6". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860547&group_id=5470 From noreply at sourceforge.net Mon Dec 15 18:12:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 15 18:12:24 2003 Subject: [ python-Bugs-860547 ] Core dump problems Message-ID: Bugs item #860547, was opened at 2003-12-15 15:06 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860547&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Draper (crunch) Assigned to: Nobody/Anonymous (nobody) Summary: Core dump problems Initial Comment: Tried to install Python 2.3.3c1 It keeps core dumping (leaving python.core). I'm not doing anything strange, just documented stuff from the manuals. I tried 'gdb -c python.core' and then using 'back', but there are no labels compiled in (I hate that...); how can I get the labels to be included? "./configure --debug" doesn't work. I assume without the labels the numbers are meaningless. Running this under OpenBSD 3.2. Then, where should I submit my core dump (if anywhere?)? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-15 18:12 Message: Logged In: YES user_id=33168 try ./configure --with-pydebug Do all the tests run? (make test) ---------------------------------------------------------------------- Comment By: John Draper (crunch) Date: 2003-12-15 16:08 Message: Logged In: YES user_id=61606 Further details on the Python core dump: It core dumps (segmentation fault) when I check the database for a certain key. The offending statement is: x=database.has_key(keystring). database is open and otherwise normal. The database is "gdbm-1.8.3". The offending key is "3012a3ec5c796329fee7c242d4df00d6". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860547&group_id=5470 From noreply at sourceforge.net Mon Dec 15 21:08:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 15 21:08:31 2003 Subject: [ python-Bugs-680577 ] urllib2 authentication problem Message-ID: Bugs item #680577, was opened at 2003-02-05 00:22 Message generated for change (Comment added) made by gazzadee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680577&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gary Donovan (gazzadee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 authentication problem Initial Comment: I've found a problem using the authentication in urllib2. When matching up host-names in order to find a password, then putting the protocol in the address makes it seem like a different address. eg... I create a HTTPBasicAuthHandler with a HTTPPasswordMgrWithDefaultRealm, and add the tuple (None, "http://proxy.blah.com:17828", "foo", "bar") to it. I then setup the proxy to use http://proxy.blah.com:17828 (which requires authentication). When I connect, the password lookup fails, because it is trying to find a match for "proxy.blah.com:17828" rather than "http://proxy.blah.com:17828" This problem doesn't exist if I pass "proxy.blah.com:17828" to the password manager. There seems to be some stuff in HTTPPasswordMgr to deal with variations on site names, but I guess it's not working in this case (unless this is intentional). Version Info: Python 2.2 (#1, Feb 24 2002, 16:21:58) [GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)] on linux-i386 ---------------------------------------------------------------------- >Comment By: Gary Donovan (gazzadee) Date: 2003-12-16 02:08 Message: Logged In: YES user_id=693152 This was a while ago, and my memory has faded. I'll try to respond intelligently. I think the question was with the way the password manager looks up passwords, rather than anything else. I am pretty sure that the problem is not to do with the URI passed to urlopen(). In the code shown below, the problem was solely dependent on whether I added the line: (None, "blah.com:17828", "foo", "bar") ...to the HTTPPasswordMgrWithDefaultRealm object. If that password set was added, then the password lookup for the proxy was successful, and urlopen() worked. If that password set was not included, then the password lookup for the proxy was unsuccessful (despite the inclusion of the other 2, similar, password sets - "http://blah.com:17828" and "blah.com"), and urlopen() would fail. Hence my suspicion that the password manager did not fully remove the scheme, despite attempts to do so. I'll see if I can set it up on the latest python and get it to happen again. Just as an explanation, the situation was that I was running an authenticating proxy on a non-standard port (in order to avoid clashing with the normal proxy), in order to test out how my download code would work through an authenticating proxy. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-01 00:14 Message: Logged In: YES user_id=261020 The problem seems to be with the port (:17828), not the URL scheme (http:), because HTTPPasswordMgr.reduce_uri() removes the scheme. RFC 2617 (top of page 3) says nothing about removing the port from the URI. urllib2 does not remove the port, so this doesn't appear to be a bug. I guess gazzadee was doing a urlopen with a different canonical root URI (RFC 2617, top of page 3 again) to the one he gave in add_password (ie. the URL he passed to urlopen() had no explicit port number). ---------------------------------------------------------------------- Comment By: Gary Donovan (gazzadee) Date: 2003-02-09 23:17 Message: Logged In: YES user_id=693152 Okay, the same problem crops up in Python 2.2.2 running under cygwin on Win XP Version Info: Python 2.2.2 (#1, Dec 31 2002, 12:24:34) [GCC 3.2 20020927 (prerelease)] on cygwin Here's the pertinent section of my test file (passwords and URL changed to protect the innocent): # Setup proxy proxy_handler = ProxyHandler({"http" : "http://blah.com:17828"}) # Setup authentication pass_mgr = HTTPPasswordMgrWithDefaultRealm() for passwd in [ (None, "http://blah.com:17828", "foo", "bar"), # (None, "blah.com:17828", "foo", "bar"), \ # Works if this line is uncommented (None, "blah.com", "foo", "bar"), ]: print("Adding password set (%s, %s, %s, %s)" % passwd) pass_mgr.add_password(*passwd) auth_handler = HTTPBasicAuthHandler(pass_mgr) proxy_auth_handler = ProxyBasicAuthHandler(pass_mgr) # Now build a new URL opener and install it opener = build_opener(proxy_handler, proxy_auth_handler, auth_handler, HTTPHandler) install_opener(opener) # Now try to open a file and see what happens request = Request("http://www.google.com") try: remotefile = urlopen(request) except HTTPError, ex: print("Unable to download file due to HTTP Error %d (%s)." % (ex.code, ex.msg)) return ---------------------------------------------------------------------- Comment By: Gerhard H?ring (ghaering) Date: 2003-02-07 23:21 Message: Logged In: YES user_id=163326 Can you please retry with Python 2.2.2? It seems that a related bug was fixed for 2.2.2: http://python.org/2.2.2/NEWS.txt has an entry: """ - In urllib2.py: fix proxy config with user+pass authentication. [SF patch 527518] """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680577&group_id=5470 From noreply at sourceforge.net Mon Dec 15 22:10:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 15 22:13:46 2003 Subject: [ python-Bugs-680577 ] urllib2 authentication problem Message-ID: Bugs item #680577, was opened at 2003-02-05 00:22 Message generated for change (Comment added) made by gazzadee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680577&group_id=5470 Category: Python Library >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary Donovan (gazzadee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 authentication problem Initial Comment: I've found a problem using the authentication in urllib2. When matching up host-names in order to find a password, then putting the protocol in the address makes it seem like a different address. eg... I create a HTTPBasicAuthHandler with a HTTPPasswordMgrWithDefaultRealm, and add the tuple (None, "http://proxy.blah.com:17828", "foo", "bar") to it. I then setup the proxy to use http://proxy.blah.com:17828 (which requires authentication). When I connect, the password lookup fails, because it is trying to find a match for "proxy.blah.com:17828" rather than "http://proxy.blah.com:17828" This problem doesn't exist if I pass "proxy.blah.com:17828" to the password manager. There seems to be some stuff in HTTPPasswordMgr to deal with variations on site names, but I guess it's not working in this case (unless this is intentional). Version Info: Python 2.2 (#1, Feb 24 2002, 16:21:58) [GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)] on linux-i386 ---------------------------------------------------------------------- >Comment By: Gary Donovan (gazzadee) Date: 2003-12-16 03:10 Message: Logged In: YES user_id=693152 Okay, I have attached a file that replicates this problem. If you run it as is (replacing the proxy name and address with something suitable), then it will fail (requiring proxy authentication). If you uncomment line 23 (which specifies the password without the scheme), then it will work successfully. Technical Info: * For a proxy, I am using Squid Cache version 2.4.STABLE7 for i586-mandrake-linux-gnu... * I have replicated the problem with Python 2.2.2 on Linux, and Python 2.3.2 on Windows XP. ---------------------------------------------------------------------- Comment By: Gary Donovan (gazzadee) Date: 2003-12-16 02:08 Message: Logged In: YES user_id=693152 This was a while ago, and my memory has faded. I'll try to respond intelligently. I think the question was with the way the password manager looks up passwords, rather than anything else. I am pretty sure that the problem is not to do with the URI passed to urlopen(). In the code shown below, the problem was solely dependent on whether I added the line: (None, "blah.com:17828", "foo", "bar") ...to the HTTPPasswordMgrWithDefaultRealm object. If that password set was added, then the password lookup for the proxy was successful, and urlopen() worked. If that password set was not included, then the password lookup for the proxy was unsuccessful (despite the inclusion of the other 2, similar, password sets - "http://blah.com:17828" and "blah.com"), and urlopen() would fail. Hence my suspicion that the password manager did not fully remove the scheme, despite attempts to do so. I'll see if I can set it up on the latest python and get it to happen again. Just as an explanation, the situation was that I was running an authenticating proxy on a non-standard port (in order to avoid clashing with the normal proxy), in order to test out how my download code would work through an authenticating proxy. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-01 00:14 Message: Logged In: YES user_id=261020 The problem seems to be with the port (:17828), not the URL scheme (http:), because HTTPPasswordMgr.reduce_uri() removes the scheme. RFC 2617 (top of page 3) says nothing about removing the port from the URI. urllib2 does not remove the port, so this doesn't appear to be a bug. I guess gazzadee was doing a urlopen with a different canonical root URI (RFC 2617, top of page 3 again) to the one he gave in add_password (ie. the URL he passed to urlopen() had no explicit port number). ---------------------------------------------------------------------- Comment By: Gary Donovan (gazzadee) Date: 2003-02-09 23:17 Message: Logged In: YES user_id=693152 Okay, the same problem crops up in Python 2.2.2 running under cygwin on Win XP Version Info: Python 2.2.2 (#1, Dec 31 2002, 12:24:34) [GCC 3.2 20020927 (prerelease)] on cygwin Here's the pertinent section of my test file (passwords and URL changed to protect the innocent): # Setup proxy proxy_handler = ProxyHandler({"http" : "http://blah.com:17828"}) # Setup authentication pass_mgr = HTTPPasswordMgrWithDefaultRealm() for passwd in [ (None, "http://blah.com:17828", "foo", "bar"), # (None, "blah.com:17828", "foo", "bar"), \ # Works if this line is uncommented (None, "blah.com", "foo", "bar"), ]: print("Adding password set (%s, %s, %s, %s)" % passwd) pass_mgr.add_password(*passwd) auth_handler = HTTPBasicAuthHandler(pass_mgr) proxy_auth_handler = ProxyBasicAuthHandler(pass_mgr) # Now build a new URL opener and install it opener = build_opener(proxy_handler, proxy_auth_handler, auth_handler, HTTPHandler) install_opener(opener) # Now try to open a file and see what happens request = Request("http://www.google.com") try: remotefile = urlopen(request) except HTTPError, ex: print("Unable to download file due to HTTP Error %d (%s)." % (ex.code, ex.msg)) return ---------------------------------------------------------------------- Comment By: Gerhard H?ring (ghaering) Date: 2003-02-07 23:21 Message: Logged In: YES user_id=163326 Can you please retry with Python 2.2.2? It seems that a related bug was fixed for 2.2.2: http://python.org/2.2.2/NEWS.txt has an entry: """ - In urllib2.py: fix proxy config with user+pass authentication. [SF patch 527518] """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680577&group_id=5470 From noreply at sourceforge.net Mon Dec 15 23:48:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 15 23:48:39 2003 Subject: [ python-Feature Requests-801847 ] Adding rsplit() to string and unicode objects. Message-ID: Feature Requests item #801847, was opened at 2003-09-07 09:52 Message generated for change (Settings changed) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=801847&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed Resolution: Accepted Priority: 4 Submitted By: Sean Reifschneider (jafo) Assigned to: Raymond Hettinger (rhettinger) Summary: Adding rsplit() to string and unicode objects. Initial Comment: I'm attaching patches to the library and documentation for implementing rsplit() on string and unicode objects. This works like split(), but working from the right. ./python -c 'print u"foo, bar, baz".rsplit(None, 1)' [u'foo, bar,', u'baz'] This was supposed to be against the CVS code, but I've had a heck of a time getting it checked out -- my checkout has been hung for half an hour now. The code patch is against the 2.3 release, the docs patch is against the CVS. My checkout got to docs, but I didn't have the code to a point where I could build and test it. Sean ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-16 04:38 Message: Logged In: YES user_id=6380 I could just close it for you, but I'll make it an exercise for you & Raymond to figure out how to set your developer perms properly. :-) ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-12-16 03:58 Message: Logged In: YES user_id=55188 Yo. Just checked in. I don't have a permission to close this entry. Can anybody help? :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-15 11:45 Message: Logged In: YES user_id=6380 Perky, feel free to check it in! ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-12-14 04:45 Message: Logged In: YES user_id=55188 On my review, few bugs are found. >>> u'x\x00y\x00z'.rsplit(u'\x00', 1) zsh: bus error (core dumped) ./python >>> u'abcd'.rsplit(u'abcd') [u'abcd'] >>> 'a,b,c,d'.rsplit(u',', 2) [u'a', u'b', u'c,d'] And, unittests on Lib/test/test_strop.py should be moved to strings_test.py My revision for jafo's patch is available at http://people.freebsd.org/~perky/rsplit-perkyrev.diff ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-01 23:18 Message: Logged In: YES user_id=80475 Alex said he would take the patch from here. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-26 06:03 Message: Logged In: YES user_id=80475 Okay, I've got it from here! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-11-26 05:47 Message: Logged In: YES user_id=6380 OK, I'm in a generous mood today. I approve the idea. (I'm not going to review the code, that's up to Raymond and others). And Raymond can have a fillchar option to center() as well. I don't know what cook() was supposed to do, but if it's $ substitution, I recommend to keep that in a separate module for now. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-11-26 04:35 Message: Logged In: YES user_id=81797 If you are reading this and are interested in having this functionality in the standard Python library, please step forward and champion the effort. Obviously, I believe this is useful, or I wouldn't have spent the better part of a day building and testing it. However, I simply don't have the time to go through the politics of it. What needs to be done is a case needs to be further built for the presentation to the Python developement team. See Raymond's message below for a good list of what's needed there. Also see the thread on the python developers mailing list that I started in relation to this back in September. I will be happy to help out on this, but I just don't have the time to champion the adoption process. Thanks, Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-26 04:16 Message: Logged In: YES user_id=21627 It's very easy: find somebody with commit privileges to approve and commit the change. Failing to do so, write a library PEP, and ask for pronouncement. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-11-26 01:34 Message: Logged In: YES user_id=81797 Raymond, you've asked Guido about it on September 11, and he (apparently) explicitly stayed out of the discussion. I assumed that you had let him know you wanted his judgement on this and that his response was that he didn't want to be involved, leaving it up to the library "elite guard" instead. Did you actually copy Guido on your earlier request? Personally, I don't see the logic in "if we get only one string method". Python isn't for the Python core developers, it's for the users. If the users have several things that they want added, why the artificial limit on how many to accept? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-25 11:25 Message: Logged In: YES user_id=80475 Get Guido to approve the API change and I will be happy to complete the implementation, documentation, testing, etc. Advice: He will want *compelling* non-toy use cases and reasons why that a person wouldn't just implement it in pure python (saying that they aren't smart enough is not a reason). He is rarely ever persuaded by symmetry/completeness arguments along the lines of "we have an l-this so we have to have an r-that". If that were the case, tuples would have gotten index() and count() long ago. Language growth rate is one issue, the total number of string methods is another, and more importantly he seeks to minimize the number of small API compatabilities between versions which make it difficult to write code for Py2.4 that runs on Py2.2. Also, there are a number of strong competitors vying to be added as string methods. If we only get one new method, why is this one to be preferred over str.cook() for supporting Barry's simplified string substitutions Given only one new str API change, I would personally prefer to add an optional fillchar argument to str.center(). ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-11-25 07:45 Message: Logged In: YES user_id=139309 I'd have to say me too on this one, wake up please :) ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-29 14:38 Message: Logged In: YES user_id=81797 This seems to have generated nothing but positive comment from the folks on python-dev. Thoughts? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-23 03:17 Message: Logged In: YES user_id=80475 I'll review your patch when I get a chance. ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-09-22 22:10 Message: Logged In: YES user_id=99508 As a comment on the ease with which a programmer can get rsplit wrong, note that rhettinger's rsplit implementation is not correct: compare rsplit('foobarbaz', 'bar') with 'foobarbaz'.split('bar'). He forgot to reverse the separator if it's not None. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-12 08:55 Message: Logged In: YES user_id=80475 Guido, do you care to pronounce on this one? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-11 15:07 Message: Logged In: YES user_id=21627 There is PEP 2, which suggests to write a library PEP for proposal to extend the library. Now, this probably would be overkill for a single string method. However, I feel that there are already too many string methods, so I won't accept that patch. I'm not rejecting it, either, because I see that other maintainers might have a different opinion. In short, you should propose your change to python-dev, finding out what "a majority" of the maintainers thinks; you might also propose it on python-list, trying to collect reactions from users. It would then be good to summarize these discussions here (instead of carrying them out here). ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-11 05:40 Message: Logged In: YES user_id=81797 I realize that rsplit() can be implemented, because, well, I implemented it. The standard library is there to provide ready-to-use functionality so that users of python can concentrate on their program instead of concentrate on re-inventing the wheel. find() can be implemented with a short loop, split() can be implemented with find(), join() can be implemented with a short loop. Many things can be implemented with a little additional effort on the part of the user to develop or locate the code they're wanting. These little things can add up quickly and can have quite a dramatic impact on the programming experience in Python. Having to find or implement these functions will cause distraction from the code at hand, time lost while finding, implementing, testing, and maintaining the code in question. One of Python's strengths is a rich standard library. So, what are the guidelines for determining when it's rich enough? Why is it ok to suggest that users should get distracted from their code to go implement something else? Is there a policy that I'm not aware of that new functionality should be put in the cookbook instead of the standard library? Why is it being ignored that some programmers would find implementing rsplit() challenging? I'm not trying to be difficult here, I honestly can't understand the apparent change from having a rich library to a "batteries not included" stance. The response I got from #python when I mentioned having submitted the patch indicates to me that other experienced Python developers expect there to be an rsplit(). So, why is there so much resistance to adding something to the library? What are the guidelines for determining if something should be in the library? Sean ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-11 04:35 Message: Logged In: YES user_id=80475 I would classify this more as a technique than a fundamental string operation implemented by all stringlike objects (including UserString). Accordingly, I recommend that the patch be closed and a recipe posted in the ASPN cookbook - something along the lines of: >>> def rsplit(s, sep=None, maxsplit=-1): ... return [chunk[::-1] for chunk in s[::-1].split(sep, maxsplit)[::-1]] >>> rsplit(u"foo, bar, baz", None, 1) [u'foo, bar,', u'baz'] ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-11 04:15 Message: Logged In: YES user_id=81797 os.path.basename/os.path.dirname is an example of where you could use rsplit. One of the other #python folks said he had recently wanted rsplit for an application where he was getting the domain name and user part from a list of e-mail addresses, but found that some entries contained an "@" in the user part. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-11 02:08 Message: Logged In: YES user_id=21627 I questioned the usefulness because I could not think of a meaningful application. Now I see what a potential application could be, but I doubt its generality, because that approach would break if there could be two fields that have commas in them. I also disagree that symmetry can motivate usefulness: I also doubt that all of the r* functions are useful, but they cannot be removed for backwards compatibility. The fact that rsplit would fit together with the other r* functions indicates that adding rsplit would provide symmetry, not that it would provide usefulness. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-08 09:56 Message: Logged In: YES user_id=81797 Can you provide more details about why the usefulness of this function is in question? First I would like to tell you the story of it coming to be, then I will answer your incomplete question with a (probably) incomplete answer. I had a device which sent me comma-separated fields, but one of the fields in the middle could contain a comma. The answer that seemed obvious to me was to use split with a maxsplit to get the fields up to that field, and then a rsplit with a maxsplit on the remainder. When I mentioned on #python that I was implementing rsplit, 4 other fellow python users replied right away that they had been wanting it. To answer your question, it's useful because people using strings are used to having r*() functions like rfind and rstrip. The lack of rsplit is kind of glaring in this context. Really, though, it's useful because otherwise people have to implement -- often badly. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-08 04:49 Message: Logged In: YES user_id=21627 Why is this function useful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=801847&group_id=5470 From noreply at sourceforge.net Tue Dec 16 04:59:43 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 16 04:59:48 2003 Subject: [ python-Bugs-860864 ] testing 1 2 3 Message-ID: Bugs item #860864, was opened at 2003-12-16 09:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860864&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: testing 1 2 3 Initial Comment: Just trying to submit a bug using lynx. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860864&group_id=5470 From noreply at sourceforge.net Tue Dec 16 05:02:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 16 05:02:10 2003 Subject: [ python-Bugs-860864 ] testing 1 2 3 Message-ID: Bugs item #860864, was opened at 2003-12-16 09:59 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860864&group_id=5470 Category: None >Group: Trash >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: testing 1 2 3 Initial Comment: Just trying to submit a bug using lynx. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-12-16 10:02 Message: Logged In: YES user_id=6656 it seems to work so long as you attempt to attach /dev/null... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860864&group_id=5470 From noreply at sourceforge.net Tue Dec 16 07:49:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 16 07:49:42 2003 Subject: [ python-Bugs-680577 ] urllib2 authentication problem Message-ID: Bugs item #680577, was opened at 2003-02-05 00:22 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680577&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary Donovan (gazzadee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 authentication problem Initial Comment: I've found a problem using the authentication in urllib2. When matching up host-names in order to find a password, then putting the protocol in the address makes it seem like a different address. eg... I create a HTTPBasicAuthHandler with a HTTPPasswordMgrWithDefaultRealm, and add the tuple (None, "http://proxy.blah.com:17828", "foo", "bar") to it. I then setup the proxy to use http://proxy.blah.com:17828 (which requires authentication). When I connect, the password lookup fails, because it is trying to find a match for "proxy.blah.com:17828" rather than "http://proxy.blah.com:17828" This problem doesn't exist if I pass "proxy.blah.com:17828" to the password manager. There seems to be some stuff in HTTPPasswordMgr to deal with variations on site names, but I guess it's not working in this case (unless this is intentional). Version Info: Python 2.2 (#1, Feb 24 2002, 16:21:58) [GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)] on linux-i386 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-16 12:49 Message: Logged In: YES user_id=261020 Thanks! It seems .reduce_uri() tries to cope with hostnames as well as absoluteURIs. I don't understand why it wants to do that, but it fails, because it doesn't anticipate what urlparse does when a port is present: >>> urlparse.urlparse("foo.bar.com") ('', '', 'foo.bar.com', '', '', '') >>> urlparse.urlparse("foo.bar.com:80") ('foo.bar.com', '', '80', '', '', '') I haven't checked, but I assume it's just incorrect use of urlparse to pass it a hostname. Of course, if it's "fixed" to only accept absoluteURIs, it will break existing code, so I guess it must be fixed for hostnames. :-(( Also, I think .is_suburi("/foo/spam", "/foo/eggs") should return False, but returns True, and .http_error_40x() use req.get_host() when they should be using req.get_full_url() (from a quick look at RFC 2617). ---------------------------------------------------------------------- Comment By: Gary Donovan (gazzadee) Date: 2003-12-16 03:10 Message: Logged In: YES user_id=693152 Okay, I have attached a file that replicates this problem. If you run it as is (replacing the proxy name and address with something suitable), then it will fail (requiring proxy authentication). If you uncomment line 23 (which specifies the password without the scheme), then it will work successfully. Technical Info: * For a proxy, I am using Squid Cache version 2.4.STABLE7 for i586-mandrake-linux-gnu... * I have replicated the problem with Python 2.2.2 on Linux, and Python 2.3.2 on Windows XP. ---------------------------------------------------------------------- Comment By: Gary Donovan (gazzadee) Date: 2003-12-16 02:08 Message: Logged In: YES user_id=693152 This was a while ago, and my memory has faded. I'll try to respond intelligently. I think the question was with the way the password manager looks up passwords, rather than anything else. I am pretty sure that the problem is not to do with the URI passed to urlopen(). In the code shown below, the problem was solely dependent on whether I added the line: (None, "blah.com:17828", "foo", "bar") ...to the HTTPPasswordMgrWithDefaultRealm object. If that password set was added, then the password lookup for the proxy was successful, and urlopen() worked. If that password set was not included, then the password lookup for the proxy was unsuccessful (despite the inclusion of the other 2, similar, password sets - "http://blah.com:17828" and "blah.com"), and urlopen() would fail. Hence my suspicion that the password manager did not fully remove the scheme, despite attempts to do so. I'll see if I can set it up on the latest python and get it to happen again. Just as an explanation, the situation was that I was running an authenticating proxy on a non-standard port (in order to avoid clashing with the normal proxy), in order to test out how my download code would work through an authenticating proxy. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-01 00:14 Message: Logged In: YES user_id=261020 The problem seems to be with the port (:17828), not the URL scheme (http:), because HTTPPasswordMgr.reduce_uri() removes the scheme. RFC 2617 (top of page 3) says nothing about removing the port from the URI. urllib2 does not remove the port, so this doesn't appear to be a bug. I guess gazzadee was doing a urlopen with a different canonical root URI (RFC 2617, top of page 3 again) to the one he gave in add_password (ie. the URL he passed to urlopen() had no explicit port number). ---------------------------------------------------------------------- Comment By: Gary Donovan (gazzadee) Date: 2003-02-09 23:17 Message: Logged In: YES user_id=693152 Okay, the same problem crops up in Python 2.2.2 running under cygwin on Win XP Version Info: Python 2.2.2 (#1, Dec 31 2002, 12:24:34) [GCC 3.2 20020927 (prerelease)] on cygwin Here's the pertinent section of my test file (passwords and URL changed to protect the innocent): # Setup proxy proxy_handler = ProxyHandler({"http" : "http://blah.com:17828"}) # Setup authentication pass_mgr = HTTPPasswordMgrWithDefaultRealm() for passwd in [ (None, "http://blah.com:17828", "foo", "bar"), # (None, "blah.com:17828", "foo", "bar"), \ # Works if this line is uncommented (None, "blah.com", "foo", "bar"), ]: print("Adding password set (%s, %s, %s, %s)" % passwd) pass_mgr.add_password(*passwd) auth_handler = HTTPBasicAuthHandler(pass_mgr) proxy_auth_handler = ProxyBasicAuthHandler(pass_mgr) # Now build a new URL opener and install it opener = build_opener(proxy_handler, proxy_auth_handler, auth_handler, HTTPHandler) install_opener(opener) # Now try to open a file and see what happens request = Request("http://www.google.com") try: remotefile = urlopen(request) except HTTPError, ex: print("Unable to download file due to HTTP Error %d (%s)." % (ex.code, ex.msg)) return ---------------------------------------------------------------------- Comment By: Gerhard H?ring (ghaering) Date: 2003-02-07 23:21 Message: Logged In: YES user_id=163326 Can you please retry with Python 2.2.2? It seems that a related bug was fixed for 2.2.2: http://python.org/2.2.2/NEWS.txt has an entry: """ - In urllib2.py: fix proxy config with user+pass authentication. [SF patch 527518] """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680577&group_id=5470 From noreply at sourceforge.net Tue Dec 16 10:37:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 16 10:37:54 2003 Subject: [ python-Bugs-215126 ] Over restricted type checking on eval() function Message-ID: Bugs item #215126, was opened at 2000-09-22 15:36 Message generated for change (Comment added) made by mcherm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=215126&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: Later Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Raymond Hettinger (rhettinger) Summary: Over restricted type checking on eval() function Initial Comment: The built-in function eval() takes a string argument and a dictionary. The second argument should allow any instance which defines __getitem__ as opposed to just dictionaries. The following example creates a type error: eval, argument 2: expected dictionary, instance found class SpreadSheet: _cells = {} def __setitem__( self, key, formula ): self._cells[key] = formula def __getitem__( self, key ): return eval( self._cells[key], self ) ss = SpreadSheet() ss['a1'] = '5' ss['a2'] = 'a1*5' ss['a2'] ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2003-12-16 10:37 Message: Logged In: YES user_id=99874 I'll just add my voice as somebody who would find this to be "darn handy" if it could ever done without noticably impacting the speed of python code that DOESN'T use eval(). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-09-23 00:18 Message: Added to PEP 42. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-09-22 15:42 Message: Changed Group to Feature Request. Should be added to PEP 42 (I'll do that if nobody beats me to it). CPython requires a genuine dict now for speed. I believe JPython allows any mapping object. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=215126&group_id=5470 From noreply at sourceforge.net Tue Dec 16 10:37:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 16 10:38:00 2003 Subject: [ python-Bugs-856841 ] a exception ocurrs when compiling a Python file Message-ID: Bugs item #856841, was opened at 2003-12-09 07:57 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856841&group_id=5470 Category: Parser/Compiler Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Pablo Yabo (pablo_yabo) Assigned to: Nobody/Anonymous (nobody) Summary: a exception ocurrs when compiling a Python file Initial Comment: a exception ocurrs when compiling some big python files (more than 250kb) using the debug library (python22_d.dll). When using the release library in the release version of my application the files compile succesfully. Attached is the stack trace. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-12-16 10:37 Message: Logged In: YES user_id=593130 If, by 'exception', PY indeed means a system crash rather than a Python exception, then I agree that more graceful termination would be desireable. However, I believe someone once pointed out on Py-Dev list that memory failures may make interpreter operation, even to produce a Python stack trace, impossible. In any case, the details of system software and hardware, including memory, needed to even discuss this, are still missing. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-12-15 05:04 Message: Logged In: YES user_id=45365 I agree with the original poster that this is a bug. While it may not be fixable (and definitely not in the general case) you should get a decent error message from Python (at the very least a MemoryError), not a crash of the interpreter. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-12-14 23:26 Message: Logged In: YES user_id=593130 I do not believe this is a compiler bug. While compiler input may by theoretically unbounded, all practical compilers have practical limitations that often depend, in part, on the amount of memory on your particular system. This is one reason for import and include mechanisms. As I understand the stack trace, the exception occured during an attempt to reallocate memory (ie, move an object to a larger block). (Including Python's exception trace would make this clearer). I presume debug mode uses more memory so you hit the limit sooner with that mode. Your solutions are to either 1) add more memory to your computer (should probably work) or try on a system with more memory or 2) break your source into more modules (certain to work if the problem is, indeed, simply running out of memory). 250K is not merely big but huge. The largest file in the standard lib is under 100K and the median is around 10K. Unless you have more reason to think this a bug, please withdraw or close. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856841&group_id=5470 From noreply at sourceforge.net Tue Dec 16 12:27:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 16 12:28:26 2003 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 11:21 Message generated for change (Comment added) made by mhertha You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: Later Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Neal Norwitz (nnorwitz) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 18:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-31 04:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 21:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include #include --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 12:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-23 04:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 20:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 13:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include #include #include #include So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 14:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 09:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 20:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 15:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 15:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-17 02:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 00:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" To: "Ralf W. Grosse-Kunstleve" Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include #include . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 16:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-22 08:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 01:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 19:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 20:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 14:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Tue Dec 16 18:09:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 16 18:09:25 2003 Subject: [ python-Bugs-861340 ] UnboundLocalError in cgitb.py Message-ID: Bugs item #861340, was opened at 2003-12-16 18:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=861340&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: UnboundLocalError in cgitb.py Initial Comment: Here's the exception: Exception return cgitb.text((E, e, tb)).rstrip('\r\n') File "/usr/lib/python2.3/cgitb.py", line 197, in text vars = scanvars(reader, frame, locals) File "/usr/lib/python2.3/cgitb.py", line 76, in scanvars parent = value UnboundLocalError: local variable 'value' referenced before assignment And here's the code: if lasttoken == '.': if parent is not __UNDEF__: value = getattr(parent, token, __UNDEF__) vars.append((prefix + token, prefix, value)) else: where, value = lookup(token, frame, locals) vars.append((token, where, value)) elif token == '.': prefix += lasttoken + '.' parent = value If lasttoken is '.' and parent is __UNDEF__, value doesn't get set. I'd offer a patch, but I really have no idea what this code is doing and so don't know what to set value to. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=861340&group_id=5470 From noreply at sourceforge.net Tue Dec 16 21:28:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 16 21:28:28 2003 Subject: [ python-Feature Requests-848910 ] Enable crosscompilation Message-ID: Feature Requests item #848910, was opened at 2003-11-25 21:55 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=848910&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: J?rg Hoh (hohjg) Assigned to: Nobody/Anonymous (nobody) Summary: Enable crosscompilation Initial Comment: Python is awful to crosscompile. I've done it with the help of that site ( http://www.ailis.de/~k/knowledge/crosscompiling/python.php), but I still had to patch the setup.py myself. The wish: Could you avoid to add the standard include path (usually /usr/include) to the include paths (in setup.py)? It confuses my crosscompiler (for which /usr/include isn't applicable, because it produces code for a different plattform and endianess), because the includes given by commandline to the gcc are searched before the standard include paths. And if there are files with the wished names, it will produce lots of errors and warnings. The second one (a more longterm wish) Could you split the build process into 2 parts? A part which is plattform independet (the (cross-) compilation of the python-binary and all required binary libraries), and a plattform specific one, which is then running on the target plattform. This would help me and other people crosscompiling python for more plattforms and embedded systems, which haven't an available native compiler (or the plattform isn't suppossed to run a compiler because of its limited ressouces). ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2003-12-17 11:28 Message: Logged In: YES user_id=55188 BTW, where's your patch? I couldn't find the patch for 2.3.2 you've created from your site. :-) ---------------------------------------------------------------------- Comment By: J?rg Hoh (hohjg) Date: 2003-11-27 17:17 Message: Logged In: YES user_id=359136 Ok, here comes my patch (for python version 2.3.2) For the Makefile: It introduces a new Variable HOSTPYTHON; this is initially set to BUILDPYTHON, but for crosscompilation purposes it should be set to name of a python binary, which runs on the build machine. In calls to setup.py the variable CROSS_COMPILATION is set to "yes". In the setup.py we check for the value of CROSS_COMPILATION; if not set to "yes" , LIBDIR and INCLUDEDIR are taken from calls to distutils, otherwise we get it from the corrsponding environment variables (but the Makefile doesn't export them, because I don't need them anymore). In all cases don't add /usr/lib/, /usr/include and /lib to the search pathes of the compiler, because these pathes are searched first for include files and libraries (before the default path settings from the compiler; so a crosscompiler will always use the host includes instead of the includes of the target plattform). Here (http://www.ailis.de/~k/knowledge/crosscompiling/python.php) is described how to use that Makefile. Please note: This patch works for me, and probably it isn't usefull to include it into the distribution. But please look at the changes of the include and library pathes, they won't affect all the native builders, but may help alot of people who do crosscompiling. ---------------------------------------------------------------------- Comment By: J?rg Hoh (hohjg) Date: 2003-11-27 05:25 Message: Logged In: YES user_id=359136 I've already have a patch (which is mostly a port of http://www.ailis.de/~k/knowledge/crosscompiling/python.php to the current version), and extended it further, so it compiles now really all modules. The compilation itself isn't as simple anymore as ./configure make make install I can submit a simple patch, which enables setup.py to get some information of the environment instead of distutils. These patches aren't nice (in fact I would call them a really hack), especially the patched Makefile. I'll will do it tomorrow morning, but don't expect to much from it :-) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-27 05:09 Message: Logged In: YES user_id=33168 I don't think anyone would take issue with supporting cross-compilation. Your requests seem reasonable, although not necessarily easy. :-) However, I don't think many (any?) developers cross-compile. Probably the only way to support cross-compilation would be if you could produce a patch. Even a patch that solves part of the problem could be beneficial. How would you like to make a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=848910&group_id=5470 From noreply at sourceforge.net Wed Dec 17 01:49:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 17 01:50:03 2003 Subject: [ python-Bugs-860101 ] python-mode.el colorizing is broken in emacs21 Message-ID: Bugs item #860101, was opened at 2003-12-15 00:41 Message generated for change (Comment added) made by offense You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860101&group_id=5470 Category: Demos and Tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Bowden (offense) Assigned to: Nobody/Anonymous (nobody) Summary: python-mode.el colorizing is broken in emacs21 Initial Comment: Something in the syntax detection is screwed up big time. The problem is that keywords are being highlighted in the middle of identifiers. For example in the line: os.rmdir(path) "dir" receives the keyword color and everything else is left default. python version: 2.3.2 emacs version: 21.3 OS: Debian/Unstable ---------------------------------------------------------------------- >Comment By: Jeff Bowden (offense) Date: 2003-12-17 06:49 Message: Logged In: YES user_id=321043 That change does fix the problem however I think it goes too far because now variables which might mask builtins are not highlighted. Oh well, at least it's not as distraction as before. Here's a weird thing. The version of python-mode.el in the debian python-elisp package is 4.40 whereas the one in the python2.3 source package is 4.35. Both the binary python-elisp and the python2.3 source claim to be version 2.3.2.91. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-12-15 18:07 Message: Logged In: YES user_id=44345 Please try changing the lines which use kw3 to define a font-lock pattern to ;; builtins when they don't appear as object attributes (cons (concat "\(\b\|[.]\)\(" kw3 "\)\b[ \n\t(]") 2) and let me know if that works for you. (The goal is to highlight variables which might shadow builtins.) ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-12-15 17:40 Message: Logged In: YES user_id=44345 Known problem. I inserted the incorrect change to the python- mode source. I wasn't aware it had been incorporated into the version of python-mode.el distributed with Python. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-12-15 10:29 Message: Logged In: YES user_id=6656 a) this should probably be submitted to the python-mode project. b) at first blush, this looks more likely to be a local config problem... 'dir' isn't a python keyword, for one thing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860101&group_id=5470 From noreply at sourceforge.net Wed Dec 17 05:39:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 17 05:39:57 2003 Subject: [ python-Bugs-606250 ] python-mode kills arrow in gdb (gud.el) Message-ID: Bugs item #606250, was opened at 2002-09-08 01:21 Message generated for change (Comment added) made by warner You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606250&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Barry A. Warsaw (bwarsaw) Summary: python-mode kills arrow in gdb (gud.el) Initial Comment: [ forwarded from http://bugs.debian.org/159628 ] missing proper category ... Once python-mode.el has been loaded, all GDB buffers stop showing the little arrow that lives in the "fringe" on the left side of an emacs21 frame. To be specific, the arrow appears and then disappears right away, each time a 'step' or 'next' command is run. I traced the problem down to the unconditional hooking of 'comint-output-filter-functions, python-mode.el line 3472 to be exact: (add-hook 'comint-output-filter-functions 'py-pdbtrack-track-stack-file) I haven't tested it fully, but I've found that if I take this line out, GDB can show its arrow once more. There is code in python-mode.el to insert this hook in a buffer-local fashion only in the '*Python*' buffer.. maybe that should be reviewed and used instead of this global hook? (took forever to figure out it was python-mode causing the problem..) ---------------------------------------------------------------------- Comment By: Brian Warner (warner) Date: 2003-12-17 02:39 Message: Logged In: YES user_id=24186 This one is still broken for me, in python-mode 4.40. (I'm the submitter of the original debian bug report). Here are some instructions to reproduce the problem: =============== 574:warner@cinla% cat hello.c #include int main(void) { printf("hello\n"); printf("world\n"); printf("\n"); return 0; } 575:warner@cinla% gcc -g -o hello hello.c 576:warner@cinla% ./hello hello world 577:warner@cinla% cat foo.py #! /usr/bin/python print "hiya" 578:warner@cinla% emacs -q M-x gdb hello RET # starts GUD session (gdb) b main RET (gdb) run RET # GDB stops on "hello". Note arrow in fringe. C-x C-f foo.py RET # loads python-mode.el C-x b *gud-hello* RET # switch back to GDB buffer (gdb) next RET # GDB stops on "world". Note lack of arrow. (gdb) next RET # arrow flickers and disappears each time =================== emacs-version reports "GNU Emacs 21.3.1 (i386-pc-linux-gnu, X toolkit) of 2003-10-31 on raven, modified by Debian" this is package emacs21, version 21.3+1-4 (from unstable) python-elisp is version 2.3.2.91-1, with py-version at $Revision: 4.40 $ let me know if there is anything I can do to further track it down. thanks! -Brian ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-31 21:10 Message: Logged In: YES user_id=44345 Matthias, I'm closing this. It seems to work for me. I entered gdb on the python executable, set a break in main(), got there, visited a Python file and manually reloaded python-mode, then returned to the gdb buffer. The => marker was visible and didn't disappear with a series of next and step commands. The only differences are I'm using XEmacs 21.5.9 and python-mode 4.37. If you can verify that the problem still exists with 4.37 under Emacs 21 I'll dig further. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-01 18:51 Message: Logged In: YES user_id=33168 Barry, I thought you worked on this? Perhaps this is a duplicate? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606250&group_id=5470 From noreply at sourceforge.net Wed Dec 17 11:21:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 17 11:21:47 2003 Subject: [ python-Bugs-860101 ] python-mode.el colorizing is broken in emacs21 Message-ID: Bugs item #860101, was opened at 2003-12-14 18:41 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860101&group_id=5470 Category: Demos and Tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Bowden (offense) Assigned to: Nobody/Anonymous (nobody) Summary: python-mode.el colorizing is broken in emacs21 Initial Comment: Something in the syntax detection is screwed up big time. The problem is that keywords are being highlighted in the middle of identifiers. For example in the line: os.rmdir(path) "dir" receives the keyword color and everything else is left default. python version: 2.3.2 emacs version: 21.3 OS: Debian/Unstable ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-12-17 10:21 Message: Logged In: YES user_id=44345 Works for me (see attached). ---------------------------------------------------------------------- Comment By: Jeff Bowden (offense) Date: 2003-12-17 00:49 Message: Logged In: YES user_id=321043 That change does fix the problem however I think it goes too far because now variables which might mask builtins are not highlighted. Oh well, at least it's not as distraction as before. Here's a weird thing. The version of python-mode.el in the debian python-elisp package is 4.40 whereas the one in the python2.3 source package is 4.35. Both the binary python-elisp and the python2.3 source claim to be version 2.3.2.91. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-12-15 12:07 Message: Logged In: YES user_id=44345 Please try changing the lines which use kw3 to define a font-lock pattern to ;; builtins when they don't appear as object attributes (cons (concat "\(\b\|[.]\)\(" kw3 "\)\b[ \n\t(]") 2) and let me know if that works for you. (The goal is to highlight variables which might shadow builtins.) ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-12-15 11:40 Message: Logged In: YES user_id=44345 Known problem. I inserted the incorrect change to the python- mode source. I wasn't aware it had been incorporated into the version of python-mode.el distributed with Python. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-12-15 04:29 Message: Logged In: YES user_id=6656 a) this should probably be submitted to the python-mode project. b) at first blush, this looks more likely to be a local config problem... 'dir' isn't a python keyword, for one thing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860101&group_id=5470 From noreply at sourceforge.net Thu Dec 18 03:53:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 18 03:54:01 2003 Subject: [ python-Bugs-862127 ] 404 in Library documentation. Message-ID: Bugs item #862127, was opened at 2003-12-18 03:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=862127&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: 404 in Library documentation. Initial Comment: The distutils section links to http://www.python.org/doc/inst/ inst.html , which doesn't exist. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=862127&group_id=5470 From noreply at sourceforge.net Thu Dec 18 10:02:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 18 10:02:27 2003 Subject: [ python-Bugs-861340 ] UnboundLocalError in cgitb.py Message-ID: Bugs item #861340, was opened at 2003-12-16 18:09 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=861340&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) >Assigned to: Skip Montanaro (montanaro) Summary: UnboundLocalError in cgitb.py Initial Comment: Here's the exception: Exception return cgitb.text((E, e, tb)).rstrip('\r\n') File "/usr/lib/python2.3/cgitb.py", line 197, in text vars = scanvars(reader, frame, locals) File "/usr/lib/python2.3/cgitb.py", line 76, in scanvars parent = value UnboundLocalError: local variable 'value' referenced before assignment And here's the code: if lasttoken == '.': if parent is not __UNDEF__: value = getattr(parent, token, __UNDEF__) vars.append((prefix + token, prefix, value)) else: where, value = lookup(token, frame, locals) vars.append((token, where, value)) elif token == '.': prefix += lasttoken + '.' parent = value If lasttoken is '.' and parent is __UNDEF__, value doesn't get set. I'd offer a patch, but I really have no idea what this code is doing and so don't know what to set value to. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-18 10:02 Message: Logged In: YES user_id=33168 Jeremy, can you attach a complete test case? Skip, I realize you didn't write the scanvars code (Ping did), but you did add text. So maybe you have an idea. >From a brief scan, it looks like if value is initialized to None, the code might work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=861340&group_id=5470 From noreply at sourceforge.net Thu Dec 18 11:13:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 18 11:13:54 2003 Subject: [ python-Bugs-861340 ] UnboundLocalError in cgitb.py Message-ID: Bugs item #861340, was opened at 2003-12-16 17:09 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=861340&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Skip Montanaro (montanaro) Summary: UnboundLocalError in cgitb.py Initial Comment: Here's the exception: Exception return cgitb.text((E, e, tb)).rstrip('\r\n') File "/usr/lib/python2.3/cgitb.py", line 197, in text vars = scanvars(reader, frame, locals) File "/usr/lib/python2.3/cgitb.py", line 76, in scanvars parent = value UnboundLocalError: local variable 'value' referenced before assignment And here's the code: if lasttoken == '.': if parent is not __UNDEF__: value = getattr(parent, token, __UNDEF__) vars.append((prefix + token, prefix, value)) else: where, value = lookup(token, frame, locals) vars.append((token, where, value)) elif token == '.': prefix += lasttoken + '.' parent = value If lasttoken is '.' and parent is __UNDEF__, value doesn't get set. I'd offer a patch, but I really have no idea what this code is doing and so don't know what to set value to. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-12-18 10:13 Message: Logged In: YES user_id=44345 Sorry, I have no idea what it does either. I'll look into it a bit, but don't expect a miracle. :-( ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-18 09:02 Message: Logged In: YES user_id=33168 Jeremy, can you attach a complete test case? Skip, I realize you didn't write the scanvars code (Ping did), but you did add text. So maybe you have an idea. >From a brief scan, it looks like if value is initialized to None, the code might work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=861340&group_id=5470 From noreply at sourceforge.net Thu Dec 18 12:31:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 18 12:31:26 2003 Subject: [ python-Bugs-861340 ] UnboundLocalError in cgitb.py Message-ID: Bugs item #861340, was opened at 2003-12-16 17:09 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=861340&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Skip Montanaro (montanaro) Summary: UnboundLocalError in cgitb.py Initial Comment: Here's the exception: Exception return cgitb.text((E, e, tb)).rstrip('\r\n') File "/usr/lib/python2.3/cgitb.py", line 197, in text vars = scanvars(reader, frame, locals) File "/usr/lib/python2.3/cgitb.py", line 76, in scanvars parent = value UnboundLocalError: local variable 'value' referenced before assignment And here's the code: if lasttoken == '.': if parent is not __UNDEF__: value = getattr(parent, token, __UNDEF__) vars.append((prefix + token, prefix, value)) else: where, value = lookup(token, frame, locals) vars.append((token, where, value)) elif token == '.': prefix += lasttoken + '.' parent = value If lasttoken is '.' and parent is __UNDEF__, value doesn't get set. I'd offer a patch, but I really have no idea what this code is doing and so don't know what to set value to. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-12-18 11:31 Message: Logged In: YES user_id=44345 I pulled scanvars() and lookup() out into a separate file and instrumented things a little. From staring at the code I thought that perhaps it didn't handle the case where the line starts with a dot separating an object and its attribute. I can't provoke a failure in that situation though. See attached lookup.py. Jeremy, can you fiddle it to make it fail? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-12-18 10:13 Message: Logged In: YES user_id=44345 Sorry, I have no idea what it does either. I'll look into it a bit, but don't expect a miracle. :-( ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-18 09:02 Message: Logged In: YES user_id=33168 Jeremy, can you attach a complete test case? Skip, I realize you didn't write the scanvars code (Ping did), but you did add text. So maybe you have an idea. >From a brief scan, it looks like if value is initialized to None, the code might work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=861340&group_id=5470 From noreply at sourceforge.net Thu Dec 18 14:37:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 18 14:37:40 2003 Subject: [ python-Bugs-862474 ] HTML problems in 2.3.3 html docs Message-ID: Bugs item #862474, was opened at 2003-12-18 20:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=862474&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: HTML problems in 2.3.3 html docs Initial Comment: MS htmlhelp compiler complains about this: HHC3004: Warning: node736.html : The HTML tag "#67847#" is not a valid HTML tag (it does not begin with an alphanumeric character). HHC3004: Warning: node736.html : The HTML tag "#67847#" is not a valid HTML tag (it does not begin with an alphanumeric character). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=862474&group_id=5470 From noreply at sourceforge.net Thu Dec 18 15:59:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 18 16:00:12 2003 Subject: [ python-Bugs-862474 ] HTML problems in 2.3.3 html docs Message-ID: Bugs item #862474, was opened at 2003-12-18 14:37 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=862474&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: HTML problems in 2.3.3 html docs Initial Comment: MS htmlhelp compiler complains about this: HHC3004: Warning: node736.html : The HTML tag "#67847#" is not a valid HTML tag (it does not begin with an alphanumeric character). HHC3004: Warning: node736.html : The HTML tag "#67847#" is not a valid HTML tag (it does not begin with an alphanumeric character). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-12-18 15:59 Message: Logged In: YES user_id=3066 Fixed in Doc/lib/libmsvcrt.tex revisions 1.6 and 1.5.8.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=862474&group_id=5470 From noreply at sourceforge.net Thu Dec 18 16:10:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 18 16:10:40 2003 Subject: [ python-Bugs-860101 ] python-mode.el colorizing is broken in emacs21 Message-ID: Bugs item #860101, was opened at 2003-12-14 18:41 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860101&group_id=5470 Category: Demos and Tools Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeff Bowden (offense) >Assigned to: Skip Montanaro (montanaro) Summary: python-mode.el colorizing is broken in emacs21 Initial Comment: Something in the syntax detection is screwed up big time. The problem is that keywords are being highlighted in the middle of identifiers. For example in the line: os.rmdir(path) "dir" receives the keyword color and everything else is left default. python version: 2.3.2 emacs version: 21.3 OS: Debian/Unstable ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-12-18 15:10 Message: Logged In: YES user_id=44345 fix checked into the python-mode project as 4.41. See http://sf.net/projects/python-mode ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-12-17 10:21 Message: Logged In: YES user_id=44345 Works for me (see attached). ---------------------------------------------------------------------- Comment By: Jeff Bowden (offense) Date: 2003-12-17 00:49 Message: Logged In: YES user_id=321043 That change does fix the problem however I think it goes too far because now variables which might mask builtins are not highlighted. Oh well, at least it's not as distraction as before. Here's a weird thing. The version of python-mode.el in the debian python-elisp package is 4.40 whereas the one in the python2.3 source package is 4.35. Both the binary python-elisp and the python2.3 source claim to be version 2.3.2.91. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-12-15 12:07 Message: Logged In: YES user_id=44345 Please try changing the lines which use kw3 to define a font-lock pattern to ;; builtins when they don't appear as object attributes (cons (concat "\(\b\|[.]\)\(" kw3 "\)\b[ \n\t(]") 2) and let me know if that works for you. (The goal is to highlight variables which might shadow builtins.) ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-12-15 11:40 Message: Logged In: YES user_id=44345 Known problem. I inserted the incorrect change to the python- mode source. I wasn't aware it had been incorporated into the version of python-mode.el distributed with Python. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-12-15 04:29 Message: Logged In: YES user_id=6656 a) this should probably be submitted to the python-mode project. b) at first blush, this looks more likely to be a local config problem... 'dir' isn't a python keyword, for one thing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860101&group_id=5470 From noreply at sourceforge.net Thu Dec 18 16:39:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 18 16:39:42 2003 Subject: [ python-Bugs-858016 ] Pathological case segmentation fault in issubclass Message-ID: Bugs item #858016, was opened at 2003-12-10 19:13 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Eric M. Hopper (omnifarious) Assigned to: Brett Cannon (bcannon) Summary: Pathological case segmentation fault in issubclass Initial Comment: This works for the PowerPC Python compiled with gcc 3.3 on OS X using fink. I suspect it's broader based than that, but I don't have the ability to check properly. Here's how to make it segment fault: x = (basestring,) for i in xrange(0, 1000000): x = (x,) issubclass(str, x) At least, it segment faults at the interactive prompt this way. I don't know if it does when it's executed from a file. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-12-18 13:39 Message: Logged In: YES user_id=357491 I have appended a file that adds a basic test to make sure that when the items of a tuple are used to call isinstance or issubclass that only classes or types are used; everything else raises TypeError. Also tried to clarify the wording of the doc strings. Changed the docs for isinstance since it allowed nested tupling while issubclass' didn't. Have a look and if someone will sign off on it I will apply the patch and then start working on a 2.3 solution that doesn't break semantics. And I just realized I left out a Misc/NEWS in the patch; it will be there when it gets applied. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-12-14 13:09 Message: Logged In: YES user_id=31435 I'm afraid that changing semantics needs to be run through the python-dev wringer first -- "shouldn't break very much code" isn't "shouldn't break any code". The *comments* in these functions make it appear that they never intended to support the OP's original code snippet, but the docs don't match. This leaves the intent a mystery, so it needs to be discussed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-12-14 12:55 Message: Logged In: YES user_id=357491 OK, consider my worldview fixed. =) I will add a check in the tuple unpacking 'for' loop to make sure it is only passing issubclass classes and not more tuples. Simple and shouldn't break very much code. Otherwise the code would have to keep a count and extra bookkeeping and it would get messy quickly. And I will take a look at isinstance, although this tuple feature was added in 2.3 for issubclass so it might not be an issue. And I will backport it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-12-13 17:08 Message: Logged In: YES user_id=31435 Yes, this needs to be fixed if it *can* be fixed without heroic effort or insane slowdown. Looks like it can be. Brett, the missing piece of your worldview here is that anywhere Python can be tricked into segfaulting is a kind of "security hole" -- it's not just mistakes we want to protect programmers from, we also want to bulletproof against hostile users, to the extent sanely possible. BTW, if issubclass() has this insecurity, I bet isinstance() does too (they were introduced & coded at the same time). ---------------------------------------------------------------------- Comment By: Eric M. Hopper (omnifarious) Date: 2003-12-11 09:54 Message: Logged In: YES user_id=313 Well, I think any case where the system segment faults unexpectedly is bad, regardless of how pathological it is. Personally, I think that issubclass should either have a recursion limit after which it throws an exception, or it shouldn't go into sub-tuples at all. The reason I made this test is that I read the description of the behavior of issublcass and found it rather strange, so I decided to push it to see how far it would go. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-12-10 20:28 Message: Logged In: YES user_id=357491 If you look at Object/abstract.c (line 2119 or so) for 2.4 CVS you will notice that PyObject_IsSubclass goes into a 'for' loop for each item in the tuple passed in and calls PyObject_IsSubclass . Unfortunately it makes no check for whether the argument it is passing is a class itself or not. This allows it to keep making calls as long as the second argument is either a class or a tuple. This is what is leads to the stack being blown and the subsequent segfault. Obvious solution is to put in a check that the argument about to be passed is a class itself so as to not have such a deep call chain. But since ``help(issubclass)`` actually makes the above use legit (it says using a tuple as a second argument is equivalent as passing each item to issubclass which is what it is doing, albeit in a rather uncommon and pointless way), is it worth putting the check in? Since this is such an obvious mis-use, I say no. But if someone else on python-dev steps in and says otherwise I will patch it. ---------------------------------------------------------------------- Comment By: Eric M. Hopper (omnifarious) Date: 2003-12-10 19:16 Message: Logged In: YES user_id=313 I forgot this: Python 2.3.2 (#1, Dec 4 2003, 09:13:58) [GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin Type "help", "copyright", "credits" or "license" for more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470 From noreply at sourceforge.net Thu Dec 18 16:48:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 18 16:48:36 2003 Subject: [ python-Bugs-858016 ] Pathological case segmentation fault in issubclass Message-ID: Bugs item #858016, was opened at 2003-12-10 22:13 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Eric M. Hopper (omnifarious) Assigned to: Brett Cannon (bcannon) Summary: Pathological case segmentation fault in issubclass Initial Comment: This works for the PowerPC Python compiled with gcc 3.3 on OS X using fink. I suspect it's broader based than that, but I don't have the ability to check properly. Here's how to make it segment fault: x = (basestring,) for i in xrange(0, 1000000): x = (x,) issubclass(str, x) At least, it segment faults at the interactive prompt this way. I don't know if it does when it's executed from a file. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-12-18 16:48 Message: Logged In: YES user_id=31435 Oh, Brett, you're missing a chance for some fun here! A bug should always be assigned to the next person who should "do something" about it. Think of it as a hot potato. You should assign the bug to who you *want* to review this, and then sit back and watch the fun, as each person in turn tries to unload the potato onto someone else. That's one way to get a comforting illusion of activity here . ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-12-18 16:39 Message: Logged In: YES user_id=357491 I have appended a file that adds a basic test to make sure that when the items of a tuple are used to call isinstance or issubclass that only classes or types are used; everything else raises TypeError. Also tried to clarify the wording of the doc strings. Changed the docs for isinstance since it allowed nested tupling while issubclass' didn't. Have a look and if someone will sign off on it I will apply the patch and then start working on a 2.3 solution that doesn't break semantics. And I just realized I left out a Misc/NEWS in the patch; it will be there when it gets applied. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-12-14 16:09 Message: Logged In: YES user_id=31435 I'm afraid that changing semantics needs to be run through the python-dev wringer first -- "shouldn't break very much code" isn't "shouldn't break any code". The *comments* in these functions make it appear that they never intended to support the OP's original code snippet, but the docs don't match. This leaves the intent a mystery, so it needs to be discussed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-12-14 15:55 Message: Logged In: YES user_id=357491 OK, consider my worldview fixed. =) I will add a check in the tuple unpacking 'for' loop to make sure it is only passing issubclass classes and not more tuples. Simple and shouldn't break very much code. Otherwise the code would have to keep a count and extra bookkeeping and it would get messy quickly. And I will take a look at isinstance, although this tuple feature was added in 2.3 for issubclass so it might not be an issue. And I will backport it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-12-13 20:08 Message: Logged In: YES user_id=31435 Yes, this needs to be fixed if it *can* be fixed without heroic effort or insane slowdown. Looks like it can be. Brett, the missing piece of your worldview here is that anywhere Python can be tricked into segfaulting is a kind of "security hole" -- it's not just mistakes we want to protect programmers from, we also want to bulletproof against hostile users, to the extent sanely possible. BTW, if issubclass() has this insecurity, I bet isinstance() does too (they were introduced & coded at the same time). ---------------------------------------------------------------------- Comment By: Eric M. Hopper (omnifarious) Date: 2003-12-11 12:54 Message: Logged In: YES user_id=313 Well, I think any case where the system segment faults unexpectedly is bad, regardless of how pathological it is. Personally, I think that issubclass should either have a recursion limit after which it throws an exception, or it shouldn't go into sub-tuples at all. The reason I made this test is that I read the description of the behavior of issublcass and found it rather strange, so I decided to push it to see how far it would go. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-12-10 23:28 Message: Logged In: YES user_id=357491 If you look at Object/abstract.c (line 2119 or so) for 2.4 CVS you will notice that PyObject_IsSubclass goes into a 'for' loop for each item in the tuple passed in and calls PyObject_IsSubclass . Unfortunately it makes no check for whether the argument it is passing is a class itself or not. This allows it to keep making calls as long as the second argument is either a class or a tuple. This is what is leads to the stack being blown and the subsequent segfault. Obvious solution is to put in a check that the argument about to be passed is a class itself so as to not have such a deep call chain. But since ``help(issubclass)`` actually makes the above use legit (it says using a tuple as a second argument is equivalent as passing each item to issubclass which is what it is doing, albeit in a rather uncommon and pointless way), is it worth putting the check in? Since this is such an obvious mis-use, I say no. But if someone else on python-dev steps in and says otherwise I will patch it. ---------------------------------------------------------------------- Comment By: Eric M. Hopper (omnifarious) Date: 2003-12-10 22:16 Message: Logged In: YES user_id=313 I forgot this: Python 2.3.2 (#1, Dec 4 2003, 09:13:58) [GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin Type "help", "copyright", "credits" or "license" for more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470 From noreply at sourceforge.net Thu Dec 18 16:51:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 18 16:51:41 2003 Subject: [ python-Bugs-862474 ] HTML problems in 2.3.3 html docs Message-ID: Bugs item #862474, was opened at 2003-12-19 04:37 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=862474&group_id=5470 Category: Documentation Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: HTML problems in 2.3.3 html docs Initial Comment: MS htmlhelp compiler complains about this: HHC3004: Warning: node736.html : The HTML tag "#67847#" is not a valid HTML tag (it does not begin with an alphanumeric character). HHC3004: Warning: node736.html : The HTML tag "#67847#" is not a valid HTML tag (it does not begin with an alphanumeric character). ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-12-19 06:51 Message: Logged In: YES user_id=671362 I've submitted a similar bug report a few month ago. summary : tex to html convert bug http://www.python.org/sf/809599 With this fix, it also fixes my bug report. So please close Bug #809599. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-12-19 05:59 Message: Logged In: YES user_id=3066 Fixed in Doc/lib/libmsvcrt.tex revisions 1.6 and 1.5.8.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=862474&group_id=5470 From noreply at sourceforge.net Thu Dec 18 17:54:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 18 17:54:08 2003 Subject: [ python-Bugs-809599 ] tex to html convert bug Message-ID: Bugs item #809599, was opened at 2003-09-19 22:13 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809599&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: tex to html convert bug Initial Comment: At the section "22. MS Windows Specific Services" in Python Library Reference, there're strange characters in the middle of the sentence. http://www.python.org/dev/doc/devel/lib/node735.ht ml > msvcrt Miscellaneous useful routines from the > MS VC++<#67760#><#67760#> runtime You can see strange tags, "<#67760#>" after the word, "VC++". In Python 2.2, it looks just fine. http://www.python.org/doc/2.2.2/lib/node611.html > msvcrt Miscellaneous useful routines from the > MS VC++ runtime. It looks like this problem is caused by Fred's last commit to libmsvcrt.tex(Jul 2 2003). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-12-18 17:54 Message: Logged In: YES user_id=3066 Fixed in Doc/lib/libmsvcrt.tex revisions 1.6 and 1.5.8.1. Duplicated by SF bug #862474. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-09-23 16:12 Message: Logged In: YES user_id=3066 I was just about to post a report on this myself when I saw this. The ugly <#67760#> junk is a representation of syntactical curly braces used internally in LaTeX2HTML; these should be be produced in the final output. I'm pretty sure I know what needs to be done to fix this, but won't be able to get to it in time for Python 2.3.1. This will be fixed for Python 2.3.2 and 2.4. Assigned to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809599&group_id=5470 From noreply at sourceforge.net Thu Dec 18 17:56:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 18 17:56:18 2003 Subject: [ python-Bugs-861340 ] UnboundLocalError in cgitb.py Message-ID: Bugs item #861340, was opened at 2003-12-16 18:09 Message generated for change (Comment added) made by jemfinch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=861340&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Skip Montanaro (montanaro) Summary: UnboundLocalError in cgitb.py Initial Comment: Here's the exception: Exception return cgitb.text((E, e, tb)).rstrip('\r\n') File "/usr/lib/python2.3/cgitb.py", line 197, in text vars = scanvars(reader, frame, locals) File "/usr/lib/python2.3/cgitb.py", line 76, in scanvars parent = value UnboundLocalError: local variable 'value' referenced before assignment And here's the code: if lasttoken == '.': if parent is not __UNDEF__: value = getattr(parent, token, __UNDEF__) vars.append((prefix + token, prefix, value)) else: where, value = lookup(token, frame, locals) vars.append((token, where, value)) elif token == '.': prefix += lasttoken + '.' parent = value If lasttoken is '.' and parent is __UNDEF__, value doesn't get set. I'd offer a patch, but I really have no idea what this code is doing and so don't know what to set value to. ---------------------------------------------------------------------- >Comment By: Jeremy Fincher (jemfinch) Date: 2003-12-18 17:56 Message: Logged In: YES user_id=99508 To be honest, it's just something I ran into in my own test suite when my exception-handling logging code caught an exception I didn't expect to get raised. Since I have no idea what the code in cgitb that's raising the exception is actually doing, I really don't know how to begin to try and narrow it down to a test case. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-12-18 12:31 Message: Logged In: YES user_id=44345 I pulled scanvars() and lookup() out into a separate file and instrumented things a little. From staring at the code I thought that perhaps it didn't handle the case where the line starts with a dot separating an object and its attribute. I can't provoke a failure in that situation though. See attached lookup.py. Jeremy, can you fiddle it to make it fail? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-12-18 11:13 Message: Logged In: YES user_id=44345 Sorry, I have no idea what it does either. I'll look into it a bit, but don't expect a miracle. :-( ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-18 10:02 Message: Logged In: YES user_id=33168 Jeremy, can you attach a complete test case? Skip, I realize you didn't write the scanvars code (Ping did), but you did add text. So maybe you have an idea. >From a brief scan, it looks like if value is initialized to None, the code might work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=861340&group_id=5470 From noreply at sourceforge.net Thu Dec 18 18:02:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 18 18:02:29 2003 Subject: [ python-Bugs-861340 ] UnboundLocalError in cgitb.py Message-ID: Bugs item #861340, was opened at 2003-12-16 18:09 Message generated for change (Comment added) made by jemfinch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=861340&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Skip Montanaro (montanaro) Summary: UnboundLocalError in cgitb.py Initial Comment: Here's the exception: Exception return cgitb.text((E, e, tb)).rstrip('\r\n') File "/usr/lib/python2.3/cgitb.py", line 197, in text vars = scanvars(reader, frame, locals) File "/usr/lib/python2.3/cgitb.py", line 76, in scanvars parent = value UnboundLocalError: local variable 'value' referenced before assignment And here's the code: if lasttoken == '.': if parent is not __UNDEF__: value = getattr(parent, token, __UNDEF__) vars.append((prefix + token, prefix, value)) else: where, value = lookup(token, frame, locals) vars.append((token, where, value)) elif token == '.': prefix += lasttoken + '.' parent = value If lasttoken is '.' and parent is __UNDEF__, value doesn't get set. I'd offer a patch, but I really have no idea what this code is doing and so don't know what to set value to. ---------------------------------------------------------------------- >Comment By: Jeremy Fincher (jemfinch) Date: 2003-12-18 18:02 Message: Logged In: YES user_id=99508 The code that caused the raised exception (which subsequently triggered the exception in cgitb) was this: outputstr = '%d %s match \'%s\' (%s):' % (len(bugs), \ utils.pluralize(len(bugs), 'bug'), searchstr, utils.commaAndify(keywords, And='AND')) That's actually from the diff where I changed it to be a bit more idiomatic :) It wasn't my code, I promise! ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-12-18 17:56 Message: Logged In: YES user_id=99508 To be honest, it's just something I ran into in my own test suite when my exception-handling logging code caught an exception I didn't expect to get raised. Since I have no idea what the code in cgitb that's raising the exception is actually doing, I really don't know how to begin to try and narrow it down to a test case. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-12-18 12:31 Message: Logged In: YES user_id=44345 I pulled scanvars() and lookup() out into a separate file and instrumented things a little. From staring at the code I thought that perhaps it didn't handle the case where the line starts with a dot separating an object and its attribute. I can't provoke a failure in that situation though. See attached lookup.py. Jeremy, can you fiddle it to make it fail? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-12-18 11:13 Message: Logged In: YES user_id=44345 Sorry, I have no idea what it does either. I'll look into it a bit, but don't expect a miracle. :-( ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-18 10:02 Message: Logged In: YES user_id=33168 Jeremy, can you attach a complete test case? Skip, I realize you didn't write the scanvars code (Ping did), but you did add text. So maybe you have an idea. >From a brief scan, it looks like if value is initialized to None, the code might work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=861340&group_id=5470 From noreply at sourceforge.net Thu Dec 18 18:32:58 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 18 18:33:03 2003 Subject: [ python-Bugs-861340 ] UnboundLocalError in cgitb.py Message-ID: Bugs item #861340, was opened at 2003-12-16 18:09 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=861340&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Skip Montanaro (montanaro) Summary: UnboundLocalError in cgitb.py Initial Comment: Here's the exception: Exception return cgitb.text((E, e, tb)).rstrip('\r\n') File "/usr/lib/python2.3/cgitb.py", line 197, in text vars = scanvars(reader, frame, locals) File "/usr/lib/python2.3/cgitb.py", line 76, in scanvars parent = value UnboundLocalError: local variable 'value' referenced before assignment And here's the code: if lasttoken == '.': if parent is not __UNDEF__: value = getattr(parent, token, __UNDEF__) vars.append((prefix + token, prefix, value)) else: where, value = lookup(token, frame, locals) vars.append((token, where, value)) elif token == '.': prefix += lasttoken + '.' parent = value If lasttoken is '.' and parent is __UNDEF__, value doesn't get set. I'd offer a patch, but I really have no idea what this code is doing and so don't know what to set value to. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-18 18:32 Message: Logged In: YES user_id=33168 Jeremy, that's still not enough to reproduce the bug. What exception was thrown by the code below and from where? What were the values of bugs, searchstr, and keywords? What are the definitions for utils.pluralize() and utils.commaAndify()? ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-12-18 18:02 Message: Logged In: YES user_id=99508 The code that caused the raised exception (which subsequently triggered the exception in cgitb) was this: outputstr = '%d %s match \'%s\' (%s):' % (len(bugs), \ utils.pluralize(len(bugs), 'bug'), searchstr, utils.commaAndify(keywords, And='AND')) That's actually from the diff where I changed it to be a bit more idiomatic :) It wasn't my code, I promise! ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-12-18 17:56 Message: Logged In: YES user_id=99508 To be honest, it's just something I ran into in my own test suite when my exception-handling logging code caught an exception I didn't expect to get raised. Since I have no idea what the code in cgitb that's raising the exception is actually doing, I really don't know how to begin to try and narrow it down to a test case. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-12-18 12:31 Message: Logged In: YES user_id=44345 I pulled scanvars() and lookup() out into a separate file and instrumented things a little. From staring at the code I thought that perhaps it didn't handle the case where the line starts with a dot separating an object and its attribute. I can't provoke a failure in that situation though. See attached lookup.py. Jeremy, can you fiddle it to make it fail? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-12-18 11:13 Message: Logged In: YES user_id=44345 Sorry, I have no idea what it does either. I'll look into it a bit, but don't expect a miracle. :-( ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-18 10:02 Message: Logged In: YES user_id=33168 Jeremy, can you attach a complete test case? Skip, I realize you didn't write the scanvars code (Ping did), but you did add text. So maybe you have an idea. >From a brief scan, it looks like if value is initialized to None, the code might work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=861340&group_id=5470 From noreply at sourceforge.net Thu Dec 18 18:55:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 18 18:55:55 2003 Subject: [ python-Bugs-862600 ] Assignment to __builtins__.__debug__ doesn't do anything. Message-ID: Bugs item #862600, was opened at 2003-12-18 18:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=862600&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: Assignment to __builtins__.__debug__ doesn't do anything. Initial Comment: In 2.2, it would dynamically turn off asserts: Python 2.2.3+ (#1, Sep 30 2003, 01:19:08) [GCC 3.3.2 20030908 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> __debug__ 1 >>> __builtins__.__debug__ = 0 >>> assert 0, "There should be nothing raised." >>> But in 2.3, this changed: Python 2.3.2 (#2, Nov 11 2003, 00:22:57) [GCC 3.3.2 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> __debug__ True >>> __builtins__debug__ = False >>> assert 0, "There should be nothing raised." Traceback (most recent call last): File "", line 1, in ? AssertionError: There should be nothing raised. >>> If this is in fact the intended behavior (I hope it's not) then what's an application author to do when he wants to offer users a -O option *to his application* that turns off asserts? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=862600&group_id=5470 From noreply at sourceforge.net Fri Dec 19 00:24:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 19 00:24:26 2003 Subject: [ python-Bugs-858016 ] Pathological case segmentation fault in issubclass Message-ID: Bugs item #858016, was opened at 2003-12-10 19:13 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Eric M. Hopper (omnifarious) >Assigned to: Tim Peters (tim_one) Summary: Pathological case segmentation fault in issubclass Initial Comment: This works for the PowerPC Python compiled with gcc 3.3 on OS X using fink. I suspect it's broader based than that, but I don't have the ability to check properly. Here's how to make it segment fault: x = (basestring,) for i in xrange(0, 1000000): x = (x,) issubclass(str, x) At least, it segment faults at the interactive prompt this way. I don't know if it does when it's executed from a file. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-12-18 21:24 Message: Logged In: YES user_id=357491 OK, Tim, start hopping. =) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-12-18 13:48 Message: Logged In: YES user_id=31435 Oh, Brett, you're missing a chance for some fun here! A bug should always be assigned to the next person who should "do something" about it. Think of it as a hot potato. You should assign the bug to who you *want* to review this, and then sit back and watch the fun, as each person in turn tries to unload the potato onto someone else. That's one way to get a comforting illusion of activity here . ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-12-18 13:39 Message: Logged In: YES user_id=357491 I have appended a file that adds a basic test to make sure that when the items of a tuple are used to call isinstance or issubclass that only classes or types are used; everything else raises TypeError. Also tried to clarify the wording of the doc strings. Changed the docs for isinstance since it allowed nested tupling while issubclass' didn't. Have a look and if someone will sign off on it I will apply the patch and then start working on a 2.3 solution that doesn't break semantics. And I just realized I left out a Misc/NEWS in the patch; it will be there when it gets applied. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-12-14 13:09 Message: Logged In: YES user_id=31435 I'm afraid that changing semantics needs to be run through the python-dev wringer first -- "shouldn't break very much code" isn't "shouldn't break any code". The *comments* in these functions make it appear that they never intended to support the OP's original code snippet, but the docs don't match. This leaves the intent a mystery, so it needs to be discussed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-12-14 12:55 Message: Logged In: YES user_id=357491 OK, consider my worldview fixed. =) I will add a check in the tuple unpacking 'for' loop to make sure it is only passing issubclass classes and not more tuples. Simple and shouldn't break very much code. Otherwise the code would have to keep a count and extra bookkeeping and it would get messy quickly. And I will take a look at isinstance, although this tuple feature was added in 2.3 for issubclass so it might not be an issue. And I will backport it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-12-13 17:08 Message: Logged In: YES user_id=31435 Yes, this needs to be fixed if it *can* be fixed without heroic effort or insane slowdown. Looks like it can be. Brett, the missing piece of your worldview here is that anywhere Python can be tricked into segfaulting is a kind of "security hole" -- it's not just mistakes we want to protect programmers from, we also want to bulletproof against hostile users, to the extent sanely possible. BTW, if issubclass() has this insecurity, I bet isinstance() does too (they were introduced & coded at the same time). ---------------------------------------------------------------------- Comment By: Eric M. Hopper (omnifarious) Date: 2003-12-11 09:54 Message: Logged In: YES user_id=313 Well, I think any case where the system segment faults unexpectedly is bad, regardless of how pathological it is. Personally, I think that issubclass should either have a recursion limit after which it throws an exception, or it shouldn't go into sub-tuples at all. The reason I made this test is that I read the description of the behavior of issublcass and found it rather strange, so I decided to push it to see how far it would go. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-12-10 20:28 Message: Logged In: YES user_id=357491 If you look at Object/abstract.c (line 2119 or so) for 2.4 CVS you will notice that PyObject_IsSubclass goes into a 'for' loop for each item in the tuple passed in and calls PyObject_IsSubclass . Unfortunately it makes no check for whether the argument it is passing is a class itself or not. This allows it to keep making calls as long as the second argument is either a class or a tuple. This is what is leads to the stack being blown and the subsequent segfault. Obvious solution is to put in a check that the argument about to be passed is a class itself so as to not have such a deep call chain. But since ``help(issubclass)`` actually makes the above use legit (it says using a tuple as a second argument is equivalent as passing each item to issubclass which is what it is doing, albeit in a rather uncommon and pointless way), is it worth putting the check in? Since this is such an obvious mis-use, I say no. But if someone else on python-dev steps in and says otherwise I will patch it. ---------------------------------------------------------------------- Comment By: Eric M. Hopper (omnifarious) Date: 2003-12-10 19:16 Message: Logged In: YES user_id=313 I forgot this: Python 2.3.2 (#1, Dec 4 2003, 09:13:58) [GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin Type "help", "copyright", "credits" or "license" for more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470 From noreply at sourceforge.net Fri Dec 19 08:58:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 19 08:58:44 2003 Subject: [ python-Bugs-862941 ] PythonIDE on osx can't run script with commandline python Message-ID: Bugs item #862941, was opened at 2003-12-19 14:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=862941&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Flemming Funch (ffunch) Assigned to: Jack Jansen (jackjansen) Summary: PythonIDE on osx can't run script with commandline python Initial Comment: In Python IDE, if I have a script open, any script, and I check "Run with Command Line Python" and run it, I get: TypeError: do_script() takes at least 2 non-keyword arguments (1 given) This is MacPython2.3-Panther, PythonIDE1.01, OSX10.3.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=862941&group_id=5470 From noreply at sourceforge.net Fri Dec 19 10:13:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 19 10:13:51 2003 Subject: [ python-Bugs-862980 ] int('somenumber',0) returns somenummber Message-ID: Bugs item #862980, was opened at 2003-12-19 16:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=862980&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Laura Creighton (lcreighton) Assigned to: Nobody/Anonymous (nobody) Summary: int('somenumber',0) returns somenummber Initial Comment: Found this incredibly minor bug in Python 2.2 and 2.3 while writing testcases for PyPy. >>> int('123',1) Traceback (most recent call last): File "", line 1, in ? ValueError: int() base must be >= 2 and <= 36 >>> int('123',0) 123 >>> Laura ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=862980&group_id=5470 From noreply at sourceforge.net Fri Dec 19 10:53:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 19 10:53:49 2003 Subject: [ python-Bugs-862980 ] int('somenumber',0) returns somenummber Message-ID: Bugs item #862980, was opened at 2003-12-19 10:13 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=862980&group_id=5470 Category: Python Interpreter Core >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Laura Creighton (lcreighton) Assigned to: Nobody/Anonymous (nobody) Summary: int('somenumber',0) returns somenummber Initial Comment: Found this incredibly minor bug in Python 2.2 and 2.3 while writing testcases for PyPy. >>> int('123',1) Traceback (most recent call last): File "", line 1, in ? ValueError: int() base must be >= 2 and <= 36 >>> int('123',0) 123 >>> Laura ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-12-19 10:53 Message: Logged In: YES user_id=31435 Sorry, you don't get a Bug Hunter award for this one, not even an incredibly minor award . From the docs, "If radix is zero, the proper radix is guessed based on the contents of string; the interpretation is the same as for integer literals." So, e.g., >>> int('10', 0) 10 >>> int('010', 0) 8 >>> int('0x10', 0) 16 >>> but >>> int('010') 10 >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=862980&group_id=5470 From noreply at sourceforge.net Fri Dec 19 11:00:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 19 11:00:51 2003 Subject: [ python-Bugs-862980 ] int('somenumber',0) returns somenummber Message-ID: Bugs item #862980, was opened at 2003-12-19 16:13 Message generated for change (Comment added) made by lcreighton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=862980&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Laura Creighton (lcreighton) Assigned to: Nobody/Anonymous (nobody) Summary: int('somenumber',0) returns somenummber Initial Comment: Found this incredibly minor bug in Python 2.2 and 2.3 while writing testcases for PyPy. >>> int('123',1) Traceback (most recent call last): File "", line 1, in ? ValueError: int() base must be >= 2 and <= 36 >>> int('123',0) 123 >>> Laura ---------------------------------------------------------------------- >Comment By: Laura Creighton (lcreighton) Date: 2003-12-19 17:00 Message: Logged In: YES user_id=376262 Ooops, sorry about that. So, now I guess I should change the PyPy one to guess. Thanks Tim. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-12-19 16:53 Message: Logged In: YES user_id=31435 Sorry, you don't get a Bug Hunter award for this one, not even an incredibly minor award . From the docs, "If radix is zero, the proper radix is guessed based on the contents of string; the interpretation is the same as for integer literals." So, e.g., >>> int('10', 0) 10 >>> int('010', 0) 8 >>> int('0x10', 0) 16 >>> but >>> int('010') 10 >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=862980&group_id=5470 From noreply at sourceforge.net Fri Dec 19 18:02:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 19 18:02:15 2003 Subject: [ python-Bugs-863222 ] os.environ.copy() behaves differently in 2.2 vs. 2.3 Message-ID: Bugs item #863222, was opened at 2003-12-19 15:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=863222&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregory Kwok (gkwok) Assigned to: Nobody/Anonymous (nobody) Summary: os.environ.copy() behaves differently in 2.2 vs. 2.3 Initial Comment: Under Python 2.2.x, os.environ.copy() returns a copy of the os.environ object. Under Python 2.3.x, it returns what is really os.environ.data.copy(), which is different. See attached file for more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=863222&group_id=5470 From noreply at sourceforge.net Sun Dec 21 06:50:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 21 06:50:17 2003 Subject: [ python-Bugs-857909 ] bsddb craps out sporadically Message-ID: Bugs item #857909, was opened at 2003-12-11 09:41 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857909&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Predrag Miocinovic (predragm) Assigned to: Nobody/Anonymous (nobody) Summary: bsddb craps out sporadically Initial Comment: I get following from Python2.3.2 with BerkeleyDB 3.3.11 running on linux RH7.3; ------------------------ Traceback (most recent call last): File "/raid/ANITA-lite/gse/unpackd.py", line 702, in ? PacketObject.shelve() File "/raid/ANITA-lite/gse/unpackd.py", line 78, in shelve wvShelf[shelfKey] = self File "/usr/local/lib/python2.3/shelve.py", line 130, in __setitem__ self.dict[key] = f.getvalue() File "/usr/local/lib/python2.3/bsddb/__init__.py", line 120, in __setitem__ self.db[key] = value bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: Invalid argument') Exception bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery') in ignored Exception bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery') in ignored ---------------------------------- The server reporting this is running at relatively heavy load and the error occurs several times per day (this call occurs roughly 100,000 per day, but only 42 times per any given shelve instance). It reminds be of bug report #775414, but this is a non-threaded application. That said, another process is accessing the same shelve, but I've implemented a lockout system which should make sure they don't have simultaneous access. The lockout seems to work fine. The same application is running on different machine using Python2.3.2 with BerkeleyDB 4.0.14 on linux RH9 and the same error occured once (to my knowledge), but with "30987" replaced by "30981" in the traceback above, if it makes any difference. Finally, a third system, python2.3.2 with BerkeleyDB 4.0.14 on linux RH9 (but quite a bit faster, and thus lighter load) runs w/o reporting this problem so far. I don't have a convenient code snipet to exemplify the problem, but I don't do anything more than open (or re-open) a shelve and write a single python object instance to it per opening. If necessary, I can provide the code in question. ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-12-21 22:50 Message: Logged In: YES user_id=250749 As far as I can make out, what you're seeing is a BerkeleyDB issue, and bsddb is just reporting what BDB is telling it. DB_RUNRECOVERY (-30987 on DB 3.3, -30981 on DB 4.0) is documented as (quoted from DB4.0 HTML docs): "There exists a class of errors that Berkeley DB considers fatal to an entire Berkeley DB environment. An example of this type of error is a corrupted database or a log write failure because the disk is out of free space. The only way to recover from these failures is to have all threads of control exit the Berkeley DB environment, run recovery of the environment, and re-enter Berkeley DB." Therefore I think you should to followup this in a BerkeleyDB forum. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857909&group_id=5470 From noreply at sourceforge.net Sun Dec 21 12:31:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 21 12:31:34 2003 Subject: [ python-Bugs-864029 ] date/type type Message-ID: Bugs item #864029, was opened at 2003-12-21 17:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864029&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Rob W.W. Hooft (hooft) Assigned to: Nobody/Anonymous (nobody) Summary: date/type type Initial Comment: Chapter 17 of what is new in python 2.3 lists a "date/type type" instead of a "date/time type" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864029&group_id=5470 From noreply at sourceforge.net Sun Dec 21 13:37:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 21 13:37:36 2003 Subject: [ python-Bugs-864063 ] ConfigParser.getint failure on 2.3.3 Message-ID: Bugs item #864063, was opened at 2003-12-21 19:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864063&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jarek Zgoda (zgoda) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser.getint failure on 2.3.3 Initial Comment: It fails with this traceback: jarek:~/projekty/jpawrk/trunk$ ./jpa.py Traceback (most recent call last): File "/home/jarek/projekty/jpawrk/trunk/lib/jt_mainwindow.py", line 328, in OnMessageEdit self.cfg) File "/home/jarek/projekty/jpawrk/trunk/lib/jt_msgeditwindow.py", line 35, in editMessage dlg = MsgEditDlg(tmp, config) File "/home/jarek/projekty/jpawrk/trunk/lib/jt_msgeditwindow.py", line 69, in __init__ self.__setProperties(config) File "/home/jarek/projekty/jpawrk/trunk/lib/jt_msgeditwindow.py", line 76, in __setProperties winSize = cfg.getWindowSize('msgedit') File "/home/jarek/projekty/jpawrk/trunk/lib/jt_cfg.py", line 66, in getWindowSize return (self.cp.getint(windowName, 'width'), File "/usr/lib/python2.3/ConfigParser.py", line 315, in getint return self._get(section, int, option) File "/usr/lib/python2.3/ConfigParser.py", line 312, in _get return conv(self.get(section, option)) File "/usr/lib/python2.3/ConfigParser.py", line 518, in get return self._interpolate(section, option, value, d) File "/usr/lib/python2.3/ConfigParser.py", line 557, in _interpolate if value.find("%(") != -1: AttributeError: 'int' object has no attribute 'find' The offending line in ConfigParser.py is line 553 which reads: value = rawval In case of non-string values this will fail later, since find() is a string method. Changing this line to: value = str(rawval) helps in case of numeric values (didn't check with booleans, though). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864063&group_id=5470 From noreply at sourceforge.net Sun Dec 21 15:43:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 21 15:43:10 2003 Subject: [ python-Bugs-864029 ] date/type type Message-ID: Bugs item #864029, was opened at 2003-12-21 12:31 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864029&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Rob W.W. Hooft (hooft) >Assigned to: Raymond Hettinger (rhettinger) Summary: date/type type Initial Comment: Chapter 17 of what is new in python 2.3 lists a "date/type type" instead of a "date/time type" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864029&group_id=5470 From noreply at sourceforge.net Sun Dec 21 15:44:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 21 15:44:51 2003 Subject: [ python-Bugs-864106 ] PyErr_Clear() called if hash fails in PyDict_GetItem() Message-ID: Bugs item #864106, was opened at 2003-12-21 15:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864106&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Guido van Rossum (gvanrossum) Summary: PyErr_Clear() called if hash fails in PyDict_GetItem() Initial Comment: Heh, if this is a bug it's been in there since 1998. But considering it's in an error path and not tested by the regression tests, I can believe it. :-) Since Guido was the last to check in code in this area, I'm giving him the bug. :-) Objects/dictobject.c line 494 in PyDict_GetItem(), if getting the hash value fails, PyErr_Clear() is called, then return NULL. It doesn't look like PyErr_Clear() should be called. In the 8 other instances in this file, the exception isn't cleared. There may be another problem on line 522. The return value from PyObject_Hash() isn't checked. I'll attach a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864106&group_id=5470 From noreply at sourceforge.net Sun Dec 21 16:00:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 21 16:00:56 2003 Subject: [ python-Bugs-863222 ] os.environ.copy() behaves differently in 2.2 vs. 2.3 Message-ID: Bugs item #863222, was opened at 2003-12-19 18:02 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=863222&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Gregory Kwok (gkwok) Assigned to: Nobody/Anonymous (nobody) Summary: os.environ.copy() behaves differently in 2.2 vs. 2.3 Initial Comment: Under Python 2.2.x, os.environ.copy() returns a copy of the os.environ object. Under Python 2.3.x, it returns what is really os.environ.data.copy(), which is different. See attached file for more information. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-21 16:00 Message: Logged In: YES user_id=80475 Sorry, this is not a bug. The new behavior is the intended behavior -- copies are supposed to be independent from the original. MvL made the correction in Lib/os.py 1.56. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=863222&group_id=5470 From noreply at sourceforge.net Sun Dec 21 16:23:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 21 16:23:30 2003 Subject: [ python-Bugs-864106 ] PyErr_Clear() called if hash fails in PyDict_GetItem() Message-ID: Bugs item #864106, was opened at 2003-12-21 15:44 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864106&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Guido van Rossum (gvanrossum) Summary: PyErr_Clear() called if hash fails in PyDict_GetItem() Initial Comment: Heh, if this is a bug it's been in there since 1998. But considering it's in an error path and not tested by the regression tests, I can believe it. :-) Since Guido was the last to check in code in this area, I'm giving him the bug. :-) Objects/dictobject.c line 494 in PyDict_GetItem(), if getting the hash value fails, PyErr_Clear() is called, then return NULL. It doesn't look like PyErr_Clear() should be called. In the 8 other instances in this file, the exception isn't cleared. There may be another problem on line 522. The return value from PyObject_Hash() isn't checked. I'll attach a patch. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-21 16:23 Message: Logged In: YES user_id=80475 It may not be in the tests, but it is documented in the C API Reference. Also, there is at least some code that relies on the behavior. For example, in Python/ceval.c the case for LOAD_NAME uses PyDict_GetItem() to check through the nested scopes for a name -- if NULL is returned, it does not attempt to clear an error before searching the next scope. Line 522 also looks fine to me. It is guarded by a PyString_CheckExact, so the call to PyObject_Hash() should never fail. In fact, checking for a -1 would be wrong because some string could potentially hash to that value. If this seems correct to you, please mark as Invalid, close the bug, and add the missing regression test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864106&group_id=5470 From noreply at sourceforge.net Sun Dec 21 16:24:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 21 16:24:47 2003 Subject: [ python-Bugs-856072 ] UserDict.DictMixin's comments should be a docstring Message-ID: Bugs item #856072, was opened at 2003-12-08 01:19 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856072&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Bennetts (spiv) Assigned to: Raymond Hettinger (rhettinger) Summary: UserDict.DictMixin's comments should be a docstring Initial Comment: DictMixin in the UserDict module has no docstring -- but it has a comment that reads like one. I think the comment should probably be changed to a docstring so that interactive use of e.g. "help(UserDict.DictMixin)" explains how it works (override _getitem__(), __setitem__(), __delitem__(), and keys(), and the rest is done for you). If the existing comment is considered too cryptic, the text in the Library Reference for DictMixin would be a good basis for a docstring. (This is a really minor bug, but it's a shame to see such a useful class not being perfectly documented! :) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-21 16:24 Message: Logged In: YES user_id=80475 After thinking about it for a while, I would like to stick with the original decision. If you agree, please mark as Invalid and close the bug report. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-14 11:43 Message: Logged In: YES user_id=80475 Okay, I'll take another look at the original decision to omit docstrings. The rationale was to avoid contaminating the documentation of user classes that subclass UserDict.DictMixin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856072&group_id=5470 From noreply at sourceforge.net Sun Dec 21 19:13:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 21 19:13:26 2003 Subject: [ python-Bugs-864106 ] PyErr_Clear() called if hash fails in PyDict_GetItem() Message-ID: Bugs item #864106, was opened at 2003-12-21 15:44 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864106&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Guido van Rossum (gvanrossum) Summary: PyErr_Clear() called if hash fails in PyDict_GetItem() Initial Comment: Heh, if this is a bug it's been in there since 1998. But considering it's in an error path and not tested by the regression tests, I can believe it. :-) Since Guido was the last to check in code in this area, I'm giving him the bug. :-) Objects/dictobject.c line 494 in PyDict_GetItem(), if getting the hash value fails, PyErr_Clear() is called, then return NULL. It doesn't look like PyErr_Clear() should be called. In the 8 other instances in this file, the exception isn't cleared. There may be another problem on line 522. The return value from PyObject_Hash() isn't checked. I'll attach a patch. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-21 19:13 Message: Logged In: YES user_id=6380 It's not a bug. For better or for worse, PyDict_GetItem()'s contract is that it returns NULL *without* setting an exception. Before the PyErr_Clear() call was added, a failing hash function was a great way to cause confusion, because every caller of PyDict_GetItem() "knows" it doesn't set an exception, so nobody checks for exceptions, so when it *did* set an exception, the exception lingered until some later unrelated piece of code did a redundant error check. Rather than make everybody check for errors on all PyDict_GetItem() calls, we decided to swallow the error on this one (unlikely) error path that would set an exception. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-21 16:23 Message: Logged In: YES user_id=80475 It may not be in the tests, but it is documented in the C API Reference. Also, there is at least some code that relies on the behavior. For example, in Python/ceval.c the case for LOAD_NAME uses PyDict_GetItem() to check through the nested scopes for a name -- if NULL is returned, it does not attempt to clear an error before searching the next scope. Line 522 also looks fine to me. It is guarded by a PyString_CheckExact, so the call to PyObject_Hash() should never fail. In fact, checking for a -1 would be wrong because some string could potentially hash to that value. If this seems correct to you, please mark as Invalid, close the bug, and add the missing regression test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864106&group_id=5470 From noreply at sourceforge.net Sun Dec 21 19:36:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 21 19:37:06 2003 Subject: [ python-Bugs-856072 ] UserDict.DictMixin's comments should be a docstring Message-ID: Bugs item #856072, was opened at 2003-12-08 17:19 Message generated for change (Comment added) made by spiv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856072&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Andrew Bennetts (spiv) Assigned to: Raymond Hettinger (rhettinger) Summary: UserDict.DictMixin's comments should be a docstring Initial Comment: DictMixin in the UserDict module has no docstring -- but it has a comment that reads like one. I think the comment should probably be changed to a docstring so that interactive use of e.g. "help(UserDict.DictMixin)" explains how it works (override _getitem__(), __setitem__(), __delitem__(), and keys(), and the rest is done for you). If the existing comment is considered too cryptic, the text in the Library Reference for DictMixin would be a good basis for a docstring. (This is a really minor bug, but it's a shame to see such a useful class not being perfectly documented! :) ---------------------------------------------------------------------- >Comment By: Andrew Bennetts (spiv) Date: 2003-12-22 11:36 Message: Logged In: YES user_id=50945 I'm happy to trust your judgement on this. The library reference docs should be the primary reference rather than the docstring, after all. Thanks! ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-22 08:24 Message: Logged In: YES user_id=80475 After thinking about it for a while, I would like to stick with the original decision. If you agree, please mark as Invalid and close the bug report. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-15 03:43 Message: Logged In: YES user_id=80475 Okay, I'll take another look at the original decision to omit docstrings. The rationale was to avoid contaminating the documentation of user classes that subclass UserDict.DictMixin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856072&group_id=5470 From noreply at sourceforge.net Sun Dec 21 23:48:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 21 23:48:19 2003 Subject: [ python-Bugs-857909 ] bsddb craps out sporadically Message-ID: Bugs item #857909, was opened at 2003-12-10 12:41 Message generated for change (Comment added) made by predragm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857909&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Predrag Miocinovic (predragm) Assigned to: Nobody/Anonymous (nobody) Summary: bsddb craps out sporadically Initial Comment: I get following from Python2.3.2 with BerkeleyDB 3.3.11 running on linux RH7.3; ------------------------ Traceback (most recent call last): File "/raid/ANITA-lite/gse/unpackd.py", line 702, in ? PacketObject.shelve() File "/raid/ANITA-lite/gse/unpackd.py", line 78, in shelve wvShelf[shelfKey] = self File "/usr/local/lib/python2.3/shelve.py", line 130, in __setitem__ self.dict[key] = f.getvalue() File "/usr/local/lib/python2.3/bsddb/__init__.py", line 120, in __setitem__ self.db[key] = value bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: Invalid argument') Exception bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery') in ignored Exception bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery') in ignored ---------------------------------- The server reporting this is running at relatively heavy load and the error occurs several times per day (this call occurs roughly 100,000 per day, but only 42 times per any given shelve instance). It reminds be of bug report #775414, but this is a non-threaded application. That said, another process is accessing the same shelve, but I've implemented a lockout system which should make sure they don't have simultaneous access. The lockout seems to work fine. The same application is running on different machine using Python2.3.2 with BerkeleyDB 4.0.14 on linux RH9 and the same error occured once (to my knowledge), but with "30987" replaced by "30981" in the traceback above, if it makes any difference. Finally, a third system, python2.3.2 with BerkeleyDB 4.0.14 on linux RH9 (but quite a bit faster, and thus lighter load) runs w/o reporting this problem so far. I don't have a convenient code snipet to exemplify the problem, but I don't do anything more than open (or re-open) a shelve and write a single python object instance to it per opening. If necessary, I can provide the code in question. ---------------------------------------------------------------------- >Comment By: Predrag Miocinovic (predragm) Date: 2003-12-21 18:48 Message: Logged In: YES user_id=860222 I find the last comment somewhat unsatisfactory. While this appears to be BerkeleyDB issue (and w/o going into details why the exception gets thrown), it's strange that Shelve module doesn't handle this more gracefully. Since the concept of Shelve is hiding implementation details from the application, having to catch BerkeleyDB exceptions for simple shelf operations is bit over the top. If I move to another system, using different underlying DB (as given by anydbm), will I have to catch new set of exceptions all over again? Shelve (or anydbm) should either provide ability to select underlying DB implementation to use, or it should handle all DB implementation aspects so that it is trully transparent to the end user. Just my $0.02. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-12-21 01:50 Message: Logged In: YES user_id=250749 As far as I can make out, what you're seeing is a BerkeleyDB issue, and bsddb is just reporting what BDB is telling it. DB_RUNRECOVERY (-30987 on DB 3.3, -30981 on DB 4.0) is documented as (quoted from DB4.0 HTML docs): "There exists a class of errors that Berkeley DB considers fatal to an entire Berkeley DB environment. An example of this type of error is a corrupted database or a log write failure because the disk is out of free space. The only way to recover from these failures is to have all threads of control exit the Berkeley DB environment, run recovery of the environment, and re-enter Berkeley DB." Therefore I think you should to followup this in a BerkeleyDB forum. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857909&group_id=5470 From noreply at sourceforge.net Mon Dec 22 06:30:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 22 06:30:13 2003 Subject: [ python-Bugs-864374 ] 2.3.3 tests on cygwin Message-ID: Bugs item #864374, was opened at 2003-12-22 13:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864374&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3.3 tests on cygwin Initial Comment: Hello, After running ./configure --prefix=/usr make make test I get the following --- 217 tests OK. 7 tests failed: test_bz2 test_fork1 test_largefile test_os test_popen2 test_pty test_tempfile 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_dbm test_email_codecs test_gl test_imgfile test_ioctl test_linuxaudiodev test_locale test_macfs test_macostools test_mpz test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound Those skips are all expected on cygwin. When running test_bz2, test_fork1, test_popen2, test_pty, test_tempfile alone they look ok (return value to OS is 0). For the others I'm attaching output. My system is win2k on IBM T30 (laptop). Cygwin 1.5.5. Miki ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864374&group_id=5470 From noreply at sourceforge.net Mon Dec 22 06:40:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 22 06:41:00 2003 Subject: [ python-Bugs-864379 ] Python 2.3.3 make test core dump on HP-UX11i Message-ID: Bugs item #864379, was opened at 2003-12-22 11:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864379&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.3.3 make test core dump on HP-UX11i Initial Comment: I built Python-2.3.3 on HP-UX11i in the same way that I built Python-2.3.2. However, this time running 'make test' core dumps on the second pass with: test_sax *** Termination signal 138 Stop. The output from test_sax.py is given below. Each test appears to fail, but the summary gives zero failures (this also happens with Python 2.3.2, but 'make test' doesn't core dump on that release). > ./python ./Lib/test/test_sax.py Failed test_attrs_empty Failed test_attrs_wattr Failed test_double_quoteattr Failed test_escape_all Failed test_escape_basic Failed test_escape_extra Failed test_expat_attrs_empty Failed test_expat_attrs_wattr Failed test_expat_dtdhandler Failed test_expat_entityresolver Failed test_expat_file Failed test_expat_incomplete Failed test_expat_incremental Failed test_expat_incremental_reset Failed test_expat_inpsource_filename Failed test_expat_inpsource_location Failed test_expat_inpsource_stream Failed test_expat_inpsource_sysid Failed test_expat_locator_noinfo Failed test_expat_locator_withinfo Failed test_expat_nsattrs_empty Failed test_expat_nsattrs_wattr Failed test_filter_basic Failed test_make_parser Failed test_make_parser2 Failed test_nsattrs_empty Failed test_nsattrs_wattr Failed test_quoteattr_basic Failed test_single_double_quoteattr Failed test_single_quoteattr Failed test_unescape_all Failed test_unescape_amp_extra Failed test_unescape_basic Failed test_unescape_extra Failed test_xmlgen_attr_escape Failed test_xmlgen_basic Failed test_xmlgen_content Failed test_xmlgen_content_escape Failed test_xmlgen_ignorable Failed test_xmlgen_ns Failed test_xmlgen_pi 41 tests, 0 failures ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864379&group_id=5470 From noreply at sourceforge.net Mon Dec 22 10:49:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 22 10:49:31 2003 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 05:21 Message generated for change (Comment added) made by billbaxter26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: Later Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Neal Norwitz (nnorwitz) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 10:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 12:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-30 22:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 15:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include #include --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 06:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-22 22:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 14:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 07:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include #include #include #include So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 08:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 03:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 14:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 09:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 09:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 20:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 18:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" To: "Ralf W. Grosse-Kunstleve" Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include #include . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 10:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-22 02:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 19:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 13:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 14:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 08:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Mon Dec 22 13:52:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 22 13:52:18 2003 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 11:21 Message generated for change (Comment added) made by mhertha You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: Later Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Neal Norwitz (nnorwitz) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 19:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 16:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 18:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-31 04:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 21:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include #include --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 12:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-23 04:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 20:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 13:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include #include #include #include So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 14:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 09:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 20:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 15:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 15:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-17 02:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 00:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" To: "Ralf W. Grosse-Kunstleve" Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include #include . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 16:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-22 08:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 01:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 19:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 20:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 14:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Mon Dec 22 16:04:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 22 16:04:50 2003 Subject: [ python-Bugs-660098 ] New style classes and __hash__ Message-ID: Bugs item #660098, was opened at 2002-12-30 13:39 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Guido van Rossum (gvanrossum) Summary: New style classes and __hash__ Initial Comment: New style classes obviously inherit a __hash__ implementation from object which returns the id. Per default this allows using instances as dictionary keys, but usually with the wrong behaviour, because most often user classes are mutable, and their contained data should be used to calculate the hash value. IMO one possible solution would be to change typeobject.c:object_hash() to raise TypeError, and change all the immutable (core) Python objects to use _Py_HashPointer in their tp_hash slot. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-22 16:04 Message: Logged In: YES user_id=6380 Anybody see a reason why I shouldn't check this in? See python-dev discussion. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-05 13:30 Message: Logged In: YES user_id=6380 Here's the patch I am thinking of. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-05 13:06 Message: Logged In: YES user_id=6380 I wonder if the solution could be as simple as removing the tp_hash slot from the object class? I just tried that and it passes the entire test suite, as well as the tests that Tim added to the patch. The trick is that PyObject_Hash() has a fallback which does the right thing. And when the base object class doesn't set tp_compare or tp_richcompare, I think it should be allowed not to set tp_hash either. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-11 09:41 Message: Logged In: YES user_id=6380 Oops, not so fast. This also makes object.__hash__() calls fail when it is explicitly invoked, e.g. when a class overrides __eq__ to print a message and then call the base class __eq__, it must do the same for __hash__, but object.__hash__ will still fail in this case. I'll think of a fix for that. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-11 06:16 Message: Logged In: YES user_id=6380 OK, feel free to check it in. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-11 00:39 Message: Logged In: YES user_id=31435 The patch seems fines to me. I've attached a new patch, combining yours with new tests in test_class.py. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-09 14:04 Message: Logged In: YES user_id=6380 A trick similar to what we do in object_new might work. There, we raise an error if the tp_init slot is the default function (object_init) and any arguments are passed. I propose that object_hash checks that tp_compare and tp_richcompare are both NULL. I'm attaching a patch -- let me know if that works. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-09 13:54 Message: Logged In: YES user_id=31435 >>> class C: # classic class complains ... __cmp__ = lambda a, b: 0 ... >>> {C(): 1} Traceback (most recent call last): File "", line 1, in ? TypeError: unhashable instance >>> class C(object): # new-style class does not complain ... __cmp__ = lambda a, b: 0 ... >>> {C(): 1} {<__main__.C object at 0x007F6970>: 1} >>> That was under current CVS. I see the same behavior in 2.2.3, so this isn't new. About Thomas's original report, I don't agree -- the default behavior is very useful. The rule I've always lived by is that, to be usable as a dict key, an instance's class must either: 1. Implement none of {__cmp__, __eq__, __hash__}. or 2. Implement __hash__ and (at least) one of {__cmp, __eq__}. Classic classes still work this way. New-style classes don't appear to outlaw any combination here. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-09 13:44 Message: Logged In: YES user_id=6380 Yes, please paste an example here. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-05-09 13:32 Message: Logged In: YES user_id=31392 Currently, a new-style class that defines __cmp__ but not __hash__ is usable as a dictionary key. That seems related to this bug. Should I paste the example here and bump the priority? Or should I open a separate bug report? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-11 18:01 Message: Logged In: YES user_id=6380 I spent an afternoon looking into this, and I can't see an easy solution. The idea of only inheriting __hash__ together with certain other slots is really flawed; it may be better if object DIDN'T define a default implementation for __hash__, comparisons (both flavors), and other things, or maybe the default __hash__ should raise an exception when the comparisons are not those inherited from object, or maybe PyType_Ready should insert a dummy __hash__ when it sees that you redefine __eq__, or... I really don't know. I'm going to sleep on this some more, and lower the priority. You can always get the right behavior by explicitly defining __hash__. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-12-30 13:50 Message: Logged In: YES user_id=11105 You mean at the end of the inherit_slots() function? For my extension which I'm currently debugging, tp_compare, tp_richcompare, and tp_hash are inherited from base, but only tp_hash is != NULL there. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-30 13:44 Message: Logged In: YES user_id=6380 There seems to be code that tries to inherit tp_hash only when tp_compare and tp_richcompare are also inherited, but it seems to be failing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660098&group_id=5470 From noreply at sourceforge.net Mon Dec 22 19:04:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 22 19:04:42 2003 Subject: [ python-Bugs-857909 ] bsddb craps out sporadically Message-ID: Bugs item #857909, was opened at 2003-12-11 09:41 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857909&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Predrag Miocinovic (predragm) Assigned to: Nobody/Anonymous (nobody) Summary: bsddb craps out sporadically Initial Comment: I get following from Python2.3.2 with BerkeleyDB 3.3.11 running on linux RH7.3; ------------------------ Traceback (most recent call last): File "/raid/ANITA-lite/gse/unpackd.py", line 702, in ? PacketObject.shelve() File "/raid/ANITA-lite/gse/unpackd.py", line 78, in shelve wvShelf[shelfKey] = self File "/usr/local/lib/python2.3/shelve.py", line 130, in __setitem__ self.dict[key] = f.getvalue() File "/usr/local/lib/python2.3/bsddb/__init__.py", line 120, in __setitem__ self.db[key] = value bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery -- PANIC: Invalid argument') Exception bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery') in ignored Exception bsddb._db.DBRunRecoveryError: (-30987, 'DB_RUNRECOVERY: Fatal error, run database recovery') in ignored ---------------------------------- The server reporting this is running at relatively heavy load and the error occurs several times per day (this call occurs roughly 100,000 per day, but only 42 times per any given shelve instance). It reminds be of bug report #775414, but this is a non-threaded application. That said, another process is accessing the same shelve, but I've implemented a lockout system which should make sure they don't have simultaneous access. The lockout seems to work fine. The same application is running on different machine using Python2.3.2 with BerkeleyDB 4.0.14 on linux RH9 and the same error occured once (to my knowledge), but with "30987" replaced by "30981" in the traceback above, if it makes any difference. Finally, a third system, python2.3.2 with BerkeleyDB 4.0.14 on linux RH9 (but quite a bit faster, and thus lighter load) runs w/o reporting this problem so far. I don't have a convenient code snipet to exemplify the problem, but I don't do anything more than open (or re-open) a shelve and write a single python object instance to it per opening. If necessary, I can provide the code in question. ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-12-23 11:04 Message: Logged In: YES user_id=250749 I can sympathise with your POV, but shelve has a documented restriction that it is not supported for multiuser user use without specific external support - that is multiple readers are Ok, but writing requires exclusive access to the shelve database. As you are using it in such an environment, it is up to you to guarantee the required safety. The error being reported is highly likely to be a consequence of your locking scheme being inadequate for use with the BerkeleyDB environment, at least on that system, and my suggestion that you take this up in a BerkeleyDB forum was directed at you getting sufficient information to improve your locking scheme to avoid the problem you see. I think you are a little optimistic expecting the shelve module (let alone the anydbm module) to cope with exceptions arising from use outside its documented restrictions - and BerkeleyDB supports lots of capability beyond the scope of the functionality used by shelve and anydbm and the exceptions to go with that. If you care about the shelve storage format, you can force the type of storage by creating an empty database of the format of your choice, provided that that format is supported by anydbm. With a bit of care, you should be able to convert a shelve from one format to another, within the anydbm format support restriction. While it might be nice to have some format control, anydbm's purpose is hide the database format/interface. If you care about the format, you're expected to use the desired interface module directly. ---------------------------------------------------------------------- Comment By: Predrag Miocinovic (predragm) Date: 2003-12-22 15:48 Message: Logged In: YES user_id=860222 I find the last comment somewhat unsatisfactory. While this appears to be BerkeleyDB issue (and w/o going into details why the exception gets thrown), it's strange that Shelve module doesn't handle this more gracefully. Since the concept of Shelve is hiding implementation details from the application, having to catch BerkeleyDB exceptions for simple shelf operations is bit over the top. If I move to another system, using different underlying DB (as given by anydbm), will I have to catch new set of exceptions all over again? Shelve (or anydbm) should either provide ability to select underlying DB implementation to use, or it should handle all DB implementation aspects so that it is trully transparent to the end user. Just my $0.02. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-12-21 22:50 Message: Logged In: YES user_id=250749 As far as I can make out, what you're seeing is a BerkeleyDB issue, and bsddb is just reporting what BDB is telling it. DB_RUNRECOVERY (-30987 on DB 3.3, -30981 on DB 4.0) is documented as (quoted from DB4.0 HTML docs): "There exists a class of errors that Berkeley DB considers fatal to an entire Berkeley DB environment. An example of this type of error is a corrupted database or a log write failure because the disk is out of free space. The only way to recover from these failures is to have all threads of control exit the Berkeley DB environment, run recovery of the environment, and re-enter Berkeley DB." Therefore I think you should to followup this in a BerkeleyDB forum. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857909&group_id=5470 From noreply at sourceforge.net Tue Dec 23 06:51:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 23 06:51:40 2003 Subject: [ python-Bugs-864944 ] doctest chokes on recursive members Message-ID: Bugs item #864944, was opened at 2003-12-23 13:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864944&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gintautas Miliauskas (gintautasm) Assigned to: Nobody/Anonymous (nobody) Summary: doctest chokes on recursive members Initial Comment: doctests recurse infinitely when they find a recursive member in a class. A simple example: --b0rk.py-- class Crash: pass Crash.c = Crash ----- --test.py-- import doctest import b0rk doctest.testmod(b0rk) ----- --output of test.py-- Traceback (most recent call last): File "test.py", line 5, in ? doctest.testmod(b0rk) File "/usr/lib/python2.3/doctest.py", line 1148, in testmod f, t = tester.rundict(m.__dict__, name, m) File "/usr/lib/python2.3/doctest.py", line 908, in rundict f2, t2 = self.__runone(value, name + "." + thisname) File "/usr/lib/python2.3/doctest.py", line 1069, in __runone return self.rundoc(target, name) File "/usr/lib/python2.3/doctest.py", line 828, in rundoc f2, t2 = self.run__test__(d, name) <.............................> File "/usr/lib/python2.3/doctest.py", line 935, in run__test__ f, t = self.rundoc(v, thisname) File "/usr/lib/python2.3/doctest.py", line 790, in rundoc for tag, kind, homecls, value in _classify_class_attrs(object): File "/usr/lib/python2.3/inspect.py", line 201, in classify_class_attrs mro = getmro(cls) RuntimeError: maximum recursion depth exceeded ----- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864944&group_id=5470 From noreply at sourceforge.net Tue Dec 23 09:11:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 23 09:11:24 2003 Subject: [ python-Bugs-864985 ] Python 2.3.3 won't build on MacOSX 10.2 Message-ID: Bugs item #864985, was opened at 2003-12-23 14:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864985&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Jack Jansen (jackjansen) Summary: Python 2.3.3 won't build on MacOSX 10.2 Initial Comment: Python 2.3.3 won't build out-of-the-box on MacOSX 10.2 because Mac/OSX/Makefile is expecting xcodebuild instead of pbxbuild. The fix is already there, just change the commenting on the lines # For 10.2: #PBXBUILD=pbxbuild # For 10.3: PBXBUILD=xcodebuild This fix should either be handled automatically or documented in ./Mac/OSX/README Thanks! Kent ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864985&group_id=5470 From noreply at sourceforge.net Tue Dec 23 10:10:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 23 10:10:29 2003 Subject: [ python-Bugs-865014 ] Hangs when opening 2nd shell with subprocess under windows Message-ID: Bugs item #865014, was opened at 2003-12-23 15:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=865014&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: mike foord (fuzzy_dream) Assigned to: Nobody/Anonymous (nobody) Summary: Hangs when opening 2nd shell with subprocess under windows Initial Comment: The Python 2.3.3 windows installer sets a file association for .py files - 'edit with IDLE'. It sets this up to launch IDLE with the command line '-n' which is *without* a subprocess. I set up a new file association to launch IDLE with subprocess enabled. If IDLE ever attempts to open a second shell window with subprocess it hangs and I have to kill the process. Is this a known limitation or a bug (?) - if the latter why does the installer default to using the -n flag. I asked on comp.lang.python and surprisingly got no answer - perhaps the time of year has something to do with it. :-) My prefferred email address for contact is fuzzyman AT atlantibots DOT org DOT uk ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=865014&group_id=5470 From noreply at sourceforge.net Tue Dec 23 11:34:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 23 11:34:25 2003 Subject: [ python-Bugs-829532 ] os.makedirs() cannot handle "." Message-ID: Bugs item #829532, was opened at 2003-10-24 07:44 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829532&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bram Moolenaar (vimboss) Assigned to: A.M. Kuchling (akuchling) Summary: os.makedirs() cannot handle "." Initial Comment: Invoking os.makedirs() with an argument that contains a directory name with a single dot fails. The resulting error is confusing: "File exists". The problem is that the path is split up in pieces and an attempt is made to create the "." directory. This always exists, of course. It happens anyway, because the test for existence is done before creating the directory that contains ".". There are various possible solutions: 1. First normalize the path so that "." entries are removed. This would also work for ".." entries. But it might cause trouble for symbolic links and there is a performance penalty. 2. Check for existence of the directory again after the recursive call to create the directory that contains the entry. This will cause the normal error for an existing directory to be skipped, unless an extra flag is added. This gets complicated. 3. Simply skip creating a directory with the name ".". I propose to use the third solution. I have attached a patch for this. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-12-23 11:34 Message: Logged In: YES user_id=11375 Your patch is correct. Checked in as rev. 1.74 of os.py. Thanks! ---------------------------------------------------------------------- Comment By: Bram Moolenaar (vimboss) Date: 2003-10-31 17:10 Message: Logged In: YES user_id=57665 The patch suggested by akuchling doesn't work for "dir/./.". And the remark is false anyway, the patch I suggested does generate an exception for makedirs("."). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-10-31 14:41 Message: Logged In: YES user_id=11375 Note that the documentation for os.makedirs() says it raises an exception if the directory already exists, so os.makedirs('.') has to continue to be an error, though os.makedirs('/foo/bar/.') should be made to work properly. The attached patch implements this. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-10-27 19:54 Message: Logged In: YES user_id=539787 Minor correction (in ex cmdline style :): :%s/"\."/curdir/g in the 'diff' patch (making it more OS independent). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-10-24 13:46 Message: Logged In: YES user_id=11375 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829532&group_id=5470 From noreply at sourceforge.net Tue Dec 23 11:45:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 23 11:45:52 2003 Subject: [ python-Bugs-862127 ] 404 in Library documentation. Message-ID: Bugs item #862127, was opened at 2003-12-18 03:53 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=862127&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeremy Fincher (jemfinch) >Assigned to: A.M. Kuchling (akuchling) Summary: 404 in Library documentation. Initial Comment: The distutils section links to http://www.python.org/doc/inst/ inst.html , which doesn't exist. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-12-23 11:45 Message: Logged In: YES user_id=11375 The problem turned out to be two missing symlinks on the python.org site; http://www.python.org/doc/inst/ now works. Thanks for reporting this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=862127&group_id=5470 From noreply at sourceforge.net Tue Dec 23 11:48:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 23 11:48:24 2003 Subject: [ python-Bugs-864029 ] date/type type Message-ID: Bugs item #864029, was opened at 2003-12-21 12:31 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864029&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Rob W.W. Hooft (hooft) >Assigned to: A.M. Kuchling (akuchling) Summary: date/type type Initial Comment: Chapter 17 of what is new in python 2.3 lists a "date/type type" instead of a "date/time type" ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-12-23 11:48 Message: Logged In: YES user_id=11375 Oops; fixed. Thanks for catching it! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864029&group_id=5470 From noreply at sourceforge.net Tue Dec 23 11:55:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 23 11:55:29 2003 Subject: [ python-Bugs-857821 ] Remove notion of deprecated string.{atol, atof} functions Message-ID: Bugs item #857821, was opened at 2003-12-10 15:08 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857821&group_id=5470 >Category: Documentation >Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gerrit Holl (gerrit) >Assigned to: A.M. Kuchling (akuchling) Summary: Remove notion of deprecated string.{atol,atof} functions Initial Comment: In the documentation of the builtin functions long and float, a mention was made of the functions atof and atol in the string module: string.atof and string.atol. Since these have been deprecated for a long time, this is incorrect. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-12-23 11:55 Message: Logged In: YES user_id=11375 Checked in; thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857821&group_id=5470 From noreply at sourceforge.net Tue Dec 23 12:01:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 23 12:02:35 2003 Subject: [ python-Bugs-850818 ] Typo in Popen3 description Message-ID: Bugs item #850818, was opened at 2003-11-28 12:08 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850818&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gregory H. Ball (greg_ball) >Assigned to: A.M. Kuchling (akuchling) Summary: Typo in Popen3 description Initial Comment: In section 6.8.1 Popen3 and Popen4 Objects, of the current and development docs, under attribute 'childerr': """ Where the standard error from the child process goes is capturestderr was true for the constructor, or None. """ The 'is' should be 'if'. I think it might also be an improvement to replace 'or' with 'otherwise'. If a rewriting is acceptable, I think """ A file object that provides error output from the child process, if capturestderr was true for the constructor, otherwise None. """ improves uniformity with the descriptions of 'fromchild' and 'tochild'. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-12-23 12:01 Message: Logged In: YES user_id=11375 Your rewrite is certainly much better than the existing text; checked in as rev. 1.20. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850818&group_id=5470 From noreply at sourceforge.net Tue Dec 23 12:05:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 23 12:05:47 2003 Subject: [ python-Bugs-850823 ] Doc/README has broken link Message-ID: Bugs item #850823, was opened at 2003-11-28 12:16 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850823&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gregory H. Ball (greg_ball) >Assigned to: A.M. Kuchling (akuchling) Summary: Doc/README has broken link Initial Comment: The README file in the docs directory has a URL for the development docs which is out of date. This is true in current (anonymous) CVS. http://python.sourceforge.net/devel-docs/ should be http://www.python.org/dev/doc/devel/ Also, perhaps a referral from the old page could be arranged instead of a 404. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-12-23 12:05 Message: Logged In: YES user_id=11375 Fixed in rev. 1.53 of the file; thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850823&group_id=5470 From noreply at sourceforge.net Tue Dec 23 12:10:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 23 12:10:25 2003 Subject: [ python-Bugs-849046 ] gzip.GzipFile is slow Message-ID: Bugs item #849046, was opened at 2003-11-25 10:45 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=849046&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 3 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: gzip.GzipFile is slow Initial Comment: gzip.GzipFile is significantly (an order of a magnitude) slower than using the gzip binary. I've been bitten by this several times, and have replaced "fd = gzip.open('somefile', 'r')" by "fd = os.popen('gzcat somefile', 'r')" on several occassions. Would a patch that implemented GzipFile in C have any change of being accepted? ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-12-23 12:10 Message: Logged In: YES user_id=11375 It should be simple to check if the string operations are responsible -- comment out the 'self.extrabuf = self.extrabuf + data' in _add_read_data. If that makes a big difference, then _read should probably be building a list instead of modifying a string. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-12-04 14:51 Message: Logged In: YES user_id=357491 Looking at GzipFile.read and ._read , I think a large chunk of time is burned in the decompression of small chunks of data. It initially reads and decompresses 1024 bits, and then if that read did not hit the EOF, it multiplies it by 2 and continues until the EOF is reached and then finishes up. The problem is that for each read a call to _read is made that sets up a bunch of objects. I would not be surprised if the object creation and teardown is hurting the performance. I would also not be surprised if the reading of small chunks of data is an initial problem as well. This is all guesswork, though, since I did not run the profiler on this. *But*, there might be a good reason for reading small chunks. If you are decompressing a large file, you might run out of memory very quickly by reading the file into memory *and* decompressing at the same time. Reading it in successively larger chunks means you don't hold the file's entire contents in memory at any one time. So the question becomes whether causing your memory to get overloaded and major thrashing on your swap space is worth the performance increase. There is also the option of inlining _read into 'read', but since it makes two calls that seems like poor abstraction and thus would most likely not be accepted as a solution. Might be better to just have some temporary storage in an attribute of objects that are used in every call to _read and then delete the attribute once the reading is done. Or maybe allow for an optional argument to read that allowed one to specify the initial read size (and that might be a good way to see if any of these ideas are reasonable; just modify the code to read the whole thing and go at it from that). But I am in no position to make any of these calls, though, since I never use gzip. If someone cares to write up a patch to try to fix any of this it will be considered. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2003-11-25 17:05 Message: Logged In: YES user_id=764593 In the library, I see a fair amount of work that doesn't really do anything except make sure you're getting exactly a line at a time. Would it be an option to just read the file in all at once, split it on newlines, and then loop over the list? (Or read it into a cStringIO, I suppose.) ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2003-11-25 16:12 Message: Logged In: YES user_id=580910 To be more precise: $ ls -l gzippedfile -rw-r--r-- 1 ronald admin 354581 18 Nov 10:21 gzippedfile $ gzip -l gzippedfile compressed uncompr. ratio uncompressed_name 354581 1403838 74.7% gzippedfile The file contains about 45K lines of text (about 40 characters/line) $ time gzip -dc gzippedfile > /dev/null real 0m0.100s user 0m0.060s sys 0m0.000s $ python read.py gzippedfile > /dev/null real 0m3.222s user 0m3.020s sys 0m0.070s $ cat read.py #!/usr/bin/env python import sys import gzip fd = gzip.open(sys.argv[1], 'r') ln = fd.readline() while ln: sys.stdout.write(ln) ln = fd.readline() The difference is also significant for larger files (e.g. the difference is not caused by the different startup-times) ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2003-11-25 16:03 Message: Logged In: YES user_id=580910 The files are created using GzipFile. That speed is acceptable because it happens in a batch-job, reading back is the problem because that happens on demand and a user is waiting for the results. gzcat is a *uncompress* utility (specifically it is "gzip -dc"), the compression level is irrelevant for this discussion. The python code seems to do quite some string manipulation, maybe that is causing the slowdown (I'm using fd.readline() in a fairly tight loop). I'll do some profiling to check what is taking so much time. BTW. I'm doing this on Unix systems (Sun Solaris and Mac OS X). ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2003-11-25 12:35 Message: Logged In: YES user_id=764593 Which compression level are you using? It looks like most of the work is already done by zlib (which is in C), but GzipFile defaults to compression level 9. Many other zips (including your gzcat?) default to a lower (but much faster) compression level. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=849046&group_id=5470 From noreply at sourceforge.net Tue Dec 23 14:14:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 23 14:14:19 2003 Subject: [ python-Bugs-849218 ] ZipInfo shows incorrect file size for large files Message-ID: Bugs item #849218, was opened at 2003-11-25 15:09 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=849218&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Waldemar Osuch (osuchw) Assigned to: Nobody/Anonymous (nobody) Summary: ZipInfo shows incorrect file size for large files Initial Comment: When dealing with large zipped files I've noticed that ZipInfo instance was reporting incorrect file size. I could reproduce the error by: txtfile = file('bigone.txt','w') for i in xrange(10**8): txtfile.write('%-9s Hello World\n'%i) txtfile.close() os.stat('bigone.txt').st_size 2300000000L Now I zip the bugger and: z = zipfile.ZipFile(file('bigone.zip','r')) fi = z.infolist()[0] fi.file_size -1994967296 After changing zipfile.py on line 26 from: structCentralDir = "<4s4B4H3l5HLl" to: structCentralDir = "<4s4B4H3L5HLl" I get: z = zipfile.ZipFile(file('bigone.zip','r')) fi = z.infolist()[0] fi.file_size 2300000000L Sorry for a digression but it would be nice to have something similar to a module from Twisted distribution (twisted.python.zipstream) in standard library. The above module allows to read a zipped file in chunks using iterator. It would help tremendously when dealing with large files. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-12-23 14:14 Message: Logged In: YES user_id=11375 This isn't a sufficient fix; zipfile.py doesn't seem to handle files whose sizes don't fit into 32 bits. The ZIP specification at http://www.pkware. com/products/enterprise/white_papers/appnote.html#2 describes a zip64 format which can handle files larger than this limit; supporting it would require more extensive changes to zipfile.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=849218&group_id=5470 From noreply at sourceforge.net Tue Dec 23 14:16:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 23 14:17:07 2003 Subject: [ python-Bugs-851020 ] Missing BuildRequires in src rpm specfile Message-ID: Bugs item #851020, was opened at 2003-11-28 22:17 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851020&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael P. Soulier (msoulier) Assigned to: Nobody/Anonymous (nobody) Summary: Missing BuildRequires in src rpm specfile Initial Comment: I'm trying to build Python 2.3.2 on Fedora Core 1. The configure runs without errors, but I then get an odd error about pyconfig.h during the build. gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/dictobject.o Objects/dictobject.c In file included from Objects/dictobject.c:10: Include/Python.h:8:22: pyconfig.h: No such file or directory Include/Python.h:21:2: #error "limits.h is required by std C -- why isn't HAVE_LIMITS_H defined?" In file included from Include/Python.h:48, from Objects/dictobject.c:10: Include/pyport.h:4:48: pyconfig.h: No such file or directory Include/pyport.h:536:2: #error "could not set LONG_MAX in pyport.h" Objects/dictobject.c: In function `dictresize': Objects/dictobject.c:477: warning: implicit declaration of function `free' make: *** [Objects/dictobject.o] Error 1 [msoulier@tigger Python-2.3.2]$ find . -name pyconfig.h ./Mac/Include/pyconfig.h ./PC/pyconfig.h ./PC/os2emx/pyconfig.h ./PC/os2vacpp/pyconfig.h ./RISCOS/pyconfig.h ./pyconfig.h I'm not sure what the issue is here. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-12-23 14:16 Message: Logged In: YES user_id=11375 Closed per jafo's request. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-12-07 20:22 Message: Logged In: YES user_id=81797 Please go ahead and close this. See patch #855999, which includes a patch for the .spec file which seems to work with Fedora Core 1. I've also uploaded a new SRPM and Fedora binaries to the FTP site, and will be updating the web-page in a bit. Sean ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-12-04 20:08 Message: Logged In: YES user_id=81797 I guess I can't attach files to this bug. I've uploaded the patch and the patched .spec file to ftp://ftp.tummy.com/pub/tummy/Python/patches/ Let me know how this looks, and I'll either fix it or submit it as a patch. Thanks, Sean ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-12-04 20:03 Message: Logged In: YES user_id=81797 Ugh, sorry, I wasn't logged in. The last message was from me. Sean ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-12-04 20:02 Message: Logged In: NO I'm attaching a patch and a patched version of the spec-file which adds the tcl and tk prerequesites for building if tkinter is enabled. I'm running into a problem when building with these on Fedora, but I'm not sure if it's an environment problem or a .spec problem. I'd appreciate feedback on wether this spec file works for anyone. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-12-04 02:20 Message: Logged In: YES user_id=21627 Can you contribute a patch for the spec files (in Misc/RPM)? ---------------------------------------------------------------------- Comment By: Michael P. Soulier (msoulier) Date: 2003-12-03 21:18 Message: Logged In: YES user_id=470843 > Building now... It worked! Cool. Changing Summary: Was: building on Fedora Core 1 Is: Missing BuildRequires in src rpm specfile ---------------------------------------------------------------------- Comment By: Michael P. Soulier (msoulier) Date: 2003-12-03 20:53 Message: Logged In: YES user_id=470843 > Make sure you have the tcl-devel and tk-devel RPMs installed. I did not have tcl-devel installed. I'll try again now. Note that if tk-devel and tcl-devel are required to build this src rpm, then they should be listed in the BuildRequires section of the specfile. Building now... ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-12-03 17:59 Message: Logged In: YES user_id=29957 Note that I build the 23-maint and HEAD on FC1 frequently, and haven't had any problems like this at all. Make sure you have the tcl-devel and tk-devel RPMs installed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-12-03 01:49 Message: Logged In: YES user_id=21627 It would be good if you could add print statements to setup.py:detect_tkinter, to find out why it gives up. Alternatively, you can edit Modules/Setup to force _tkinter being built. ---------------------------------------------------------------------- Comment By: Michael P. Soulier (msoulier) Date: 2003-12-02 20:20 Message: Logged In: YES user_id=470843 Well, this is quite odd, but I rebuilt and the error didn't happen this time. I'm not sure why. However, I'm having a problem getting Tkinter built. I'm trying to port the src rpm currently, but when I do the --rebuild, I get this in post-processing. RPM build errors: File not found by glob: /var/tmp/python2.3-2.3.2-root/usr/lib/python2.3/lib-dynload/_tkinter.so* Looks like it was never built. [msoulier@tigger msoulier]$ cd rpms [msoulier@tigger rpms]$ cd BUILD/ [msoulier@tigger BUILD]$ ls Python-2.3.2 [msoulier@tigger BUILD]$ find Python-2.3.2/ -name "_tkinter*" Python-2.3.2/Modules/_tkinter.c Python-2.3.2/PC/os2vacpp/_tkinter.def Python-2.3.2/PCbuild/_tkinter.dsp I logged the entire build, if you'd like me to attach it. [msoulier@tigger msoulier]$ rpm -q tk-devel tk-devel-8.3.5-93 Thanks. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-12-01 16:43 Message: Logged In: YES user_id=21627 Can you pleas invoke the gcc command line manually, passing -v to gcc? This looks like a bug in the gcc installation: If -I. is given, it should find ./pyconfig.h. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851020&group_id=5470 From noreply at sourceforge.net Tue Dec 23 14:21:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 23 14:21:42 2003 Subject: [ python-Bugs-832236 ] Build fails in ossaudiodev.c with missing macros Message-ID: Bugs item #832236, was opened at 2003-10-29 04:05 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832236&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Daniel Parks (danielparks) >Assigned to: Greg Ward (gward) Summary: Build fails in ossaudiodev.c with missing macros Initial Comment: I'm building Python 2.3.2 with no configure flags on MkLinux Pre-R1. uname -a: Linux gondor.middle.earth 2.0.37-osfmach3 GENERIC_08alpha-20 Fri Jul 30 11:07:38 PDT 1999 ppc unknown The missing macros are: SOUND_MIXER_DIGITAL1, SOUND_MIXER_DIGITAL2, SOUND_MIXER_DIGITAL3, SOUND_MIXER_PHONEIN, SOUND_MIXER_PHONEOUT, SOUND_MIXER_VIDEO, SOUND_MIXER_RADIO, SOUND_MIXER_MONITOR, SNDCTL_DSP_GETODELAY I commented out two lines in setup.py and it seems to have built correctly. I would test it, but I need to go to bed, and I will forget to add this bug tomorrow. I will update this if Python actually works. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-12-23 14:21 Message: Logged In: YES user_id=11375 The fix is probably straightforward; add #ifdef ...#endif around each use of the problematic macros. If you do this, please submit a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832236&group_id=5470 From noreply at sourceforge.net Tue Dec 23 14:23:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 23 14:23:32 2003 Subject: [ python-Bugs-812325 ] tarfile violates bufsize Message-ID: Bugs item #812325, was opened at 2003-09-25 05:08 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812325&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Johan Fredrik ?hman (johanfo) >Assigned to: A.M. Kuchling (akuchling) Summary: tarfile violates bufsize Initial Comment: tf = tarfile.open(mode = 'w|gz', fileobj=fileName, bufsize=20*512) The following text says how many bytes tarfile writes to the 'fileName.write' function. Notice that when closing the tarfile it writes way to many bytes! This happes just sometimes. Some directories might work, other might not. ... write len: 10240 write len: 10240 Closing archive write len: 24815 # Somthing is wrong? write len: 4 write len: 4 ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-09-25 14:33 Message: Logged In: YES user_id=11375 The close() method just writes the contents of self.buf to the file without breaking it up into blocks. Please try the attached patch and let us know if it fixes the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812325&group_id=5470 From noreply at sourceforge.net Tue Dec 23 14:42:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 23 14:42:54 2003 Subject: [ python-Bugs-865120 ] bsddb test_all.py - incorrect Message-ID: Bugs item #865120, was opened at 2003-12-23 19:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=865120&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Shura Zam (debil_urod) Assigned to: Nobody/Anonymous (nobody) Summary: bsddb test_all.py - incorrect Initial Comment: bsddb\test\test_all.py raise exception, bat all other tests work correct. ======Command Line======= c:\>python c:\Python\Lib\bsddb\test\test_all.py ======Output============ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Sleepycat Software: Berkeley DB 4.1.25: (December 19, 2002) bsddb.db.version(): (4, 1, 25) bsddb.db.__version__: 4.2.0 bsddb.db.cvsid: $Id: _bsddb.c,v 1.17.6.2 2003/09/21 23:10:23 greg Exp $ python version: 2.3.2 (#49, Oct 2 2003, 20:02:00) [MSC v.1200 32 bit (Intel)] My pid: 2012 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Traceback (most recent call last): File "C:\Lang\ActiveState\Python\Lib\bsddb\test\test_all. py", line 81, in ? unittest.main(defaultTest='suite') File "C:\Lang\ACTIVE~1\Python\lib\unittest.py", line 720, in __init__ self.parseArgs(argv) File "C:\Lang\ACTIVE~1\Python\lib\unittest.py", line 747, in parseArgs self.createTests() File "C:\Lang\ACTIVE~1\Python\lib\unittest.py", line 753, in createTests self.module) File "C:\Lang\ACTIVE~1\Python\lib\unittest.py", line 519, in loadTestsFromNames suites.append(self.loadTestsFromName(name, module)) File "C:\Lang\ACTIVE~1\Python\lib\unittest.py", line 504, in loadTestsFromName test = obj() File "C:\Lang\ActiveState\Python\Lib\bsddb\test\test_all. py", line 69, in suite alltests.addTest(module.suite()) AttributeError: 'module' object has no attribute 'suite' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=865120&group_id=5470 From noreply at sourceforge.net Tue Dec 23 22:32:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 23 22:32:36 2003 Subject: [ python-Bugs-864379 ] Python 2.3.3 make test core dump on HP-UX11i Message-ID: Bugs item #864379, was opened at 2003-12-22 06:40 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864379&group_id=5470 Category: Build >Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.3.3 make test core dump on HP-UX11i Initial Comment: I built Python-2.3.3 on HP-UX11i in the same way that I built Python-2.3.2. However, this time running 'make test' core dumps on the second pass with: test_sax *** Termination signal 138 Stop. The output from test_sax.py is given below. Each test appears to fail, but the summary gives zero failures (this also happens with Python 2.3.2, but 'make test' doesn't core dump on that release). > ./python ./Lib/test/test_sax.py Failed test_attrs_empty Failed test_attrs_wattr Failed test_double_quoteattr Failed test_escape_all Failed test_escape_basic Failed test_escape_extra Failed test_expat_attrs_empty Failed test_expat_attrs_wattr Failed test_expat_dtdhandler Failed test_expat_entityresolver Failed test_expat_file Failed test_expat_incomplete Failed test_expat_incremental Failed test_expat_incremental_reset Failed test_expat_inpsource_filename Failed test_expat_inpsource_location Failed test_expat_inpsource_stream Failed test_expat_inpsource_sysid Failed test_expat_locator_noinfo Failed test_expat_locator_withinfo Failed test_expat_nsattrs_empty Failed test_expat_nsattrs_wattr Failed test_filter_basic Failed test_make_parser Failed test_make_parser2 Failed test_nsattrs_empty Failed test_nsattrs_wattr Failed test_quoteattr_basic Failed test_single_double_quoteattr Failed test_single_quoteattr Failed test_unescape_all Failed test_unescape_amp_extra Failed test_unescape_basic Failed test_unescape_extra Failed test_xmlgen_attr_escape Failed test_xmlgen_basic Failed test_xmlgen_content Failed test_xmlgen_content_escape Failed test_xmlgen_ignorable Failed test_xmlgen_ns Failed test_xmlgen_pi 41 tests, 0 failures ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-23 22:32 Message: Logged In: YES user_id=33168 On an HP box I tried, I don't have any problems. * HP-UX taylor B.11.00 A 9000/829 * gcc 3.2 What compiler are you using? Have you tried on the HP test drive machines? Are you compiling with optimization? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864379&group_id=5470 From noreply at sourceforge.net Wed Dec 24 03:08:43 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 24 03:08:49 2003 Subject: [ python-Bugs-862600 ] Assignment to __builtins__.__debug__ doesn't do anything. Message-ID: Bugs item #862600, was opened at 2003-12-18 18:55 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=862600&group_id=5470 >Category: Python Interpreter Core >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) >Assigned to: Raymond Hettinger (rhettinger) Summary: Assignment to __builtins__.__debug__ doesn't do anything. Initial Comment: In 2.2, it would dynamically turn off asserts: Python 2.2.3+ (#1, Sep 30 2003, 01:19:08) [GCC 3.3.2 20030908 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> __debug__ 1 >>> __builtins__.__debug__ = 0 >>> assert 0, "There should be nothing raised." >>> But in 2.3, this changed: Python 2.3.2 (#2, Nov 11 2003, 00:22:57) [GCC 3.3.2 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> __debug__ True >>> __builtins__debug__ = False >>> assert 0, "There should be nothing raised." Traceback (most recent call last): File "", line 1, in ? AssertionError: There should be nothing raised. >>> If this is in fact the intended behavior (I hope it's not) then what's an application author to do when he wants to offer users a -O option *to his application* that turns off asserts? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=862600&group_id=5470 From noreply at sourceforge.net Wed Dec 24 04:25:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 24 04:25:47 2003 Subject: [ python-Bugs-864379 ] Python 2.3.3 make test core dump on HP-UX11i Message-ID: Bugs item #864379, was opened at 2003-12-22 11:40 Message generated for change (Comment added) made by rptownsend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864379&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.3.3 make test core dump on HP-UX11i Initial Comment: I built Python-2.3.3 on HP-UX11i in the same way that I built Python-2.3.2. However, this time running 'make test' core dumps on the second pass with: test_sax *** Termination signal 138 Stop. The output from test_sax.py is given below. Each test appears to fail, but the summary gives zero failures (this also happens with Python 2.3.2, but 'make test' doesn't core dump on that release). > ./python ./Lib/test/test_sax.py Failed test_attrs_empty Failed test_attrs_wattr Failed test_double_quoteattr Failed test_escape_all Failed test_escape_basic Failed test_escape_extra Failed test_expat_attrs_empty Failed test_expat_attrs_wattr Failed test_expat_dtdhandler Failed test_expat_entityresolver Failed test_expat_file Failed test_expat_incomplete Failed test_expat_incremental Failed test_expat_incremental_reset Failed test_expat_inpsource_filename Failed test_expat_inpsource_location Failed test_expat_inpsource_stream Failed test_expat_inpsource_sysid Failed test_expat_locator_noinfo Failed test_expat_locator_withinfo Failed test_expat_nsattrs_empty Failed test_expat_nsattrs_wattr Failed test_filter_basic Failed test_make_parser Failed test_make_parser2 Failed test_nsattrs_empty Failed test_nsattrs_wattr Failed test_quoteattr_basic Failed test_single_double_quoteattr Failed test_single_quoteattr Failed test_unescape_all Failed test_unescape_amp_extra Failed test_unescape_basic Failed test_unescape_extra Failed test_xmlgen_attr_escape Failed test_xmlgen_basic Failed test_xmlgen_content Failed test_xmlgen_content_escape Failed test_xmlgen_ignorable Failed test_xmlgen_ns Failed test_xmlgen_pi 41 tests, 0 failures ---------------------------------------------------------------------- >Comment By: Richard Townsend (rptownsend) Date: 2003-12-24 09:25 Message: Logged In: YES user_id=200117 HP-UX capulet B.11.11 U 9000/785 2002932658 unlimited-user license This is the configure command I used: base_inst_dir=/opt python_link=${base_inst_dir}/python CC=cc OPT="+O2 -z +Onofltacc +ESlit +Oentrysched +Odataprefetch +Onolimit +DA2.0" INSTALL="./install-sh -c" ./configure --with-threads --without-gcc --with-cxx=/opt/aCC/bin/aCC --without-libd --with-cycle-gc --prefix=$python_link --exec-prefix=$python_link This is exactly the same command I have used on previous Python 2.3 releases which did not core dump in 'make test'. Note it uses the native HP compiler. I have now just rebuilt without optimisation, using: CC=cc INSTALL="./install-sh -c" ./configure --with-threads --without-gcc --with-cxx=/opt/aCC/bin/aCC --without-libd --with-cycle-gc --prefix=$python_link --exec-prefix=$python_link It still core dumps at the same point in the second pass of 'make test'. I have attached a stack trace from the core file. I noticed that this has references to /opt/python/lib/python2.3/site- packages/_xmlplus/parsers/pyexpat.sl. This is the previous installation of Python 2.3.2 plus PyXML-0.8.3. I wondered if I had forgotten to reset $PYTHONPATH before running 'make test', so I did that and tried again but it still core dumped. So next I reset the symbolic link /opt/python to the empty directory /opt/python-2.3.3 and ran 'make test' again. This time it didn't core dump! So why does the test suite access the previous installation when PYTHONPATH doesn't include it? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-24 03:32 Message: Logged In: YES user_id=33168 On an HP box I tried, I don't have any problems. * HP-UX taylor B.11.00 A 9000/829 * gcc 3.2 What compiler are you using? Have you tried on the HP test drive machines? Are you compiling with optimization? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864379&group_id=5470 From noreply at sourceforge.net Wed Dec 24 07:46:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 24 07:46:22 2003 Subject: [ python-Bugs-864379 ] Python 2.3.3 make test core dump on HP-UX11i Message-ID: Bugs item #864379, was opened at 2003-12-22 11:40 Message generated for change (Comment added) made by rptownsend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864379&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.3.3 make test core dump on HP-UX11i Initial Comment: I built Python-2.3.3 on HP-UX11i in the same way that I built Python-2.3.2. However, this time running 'make test' core dumps on the second pass with: test_sax *** Termination signal 138 Stop. The output from test_sax.py is given below. Each test appears to fail, but the summary gives zero failures (this also happens with Python 2.3.2, but 'make test' doesn't core dump on that release). > ./python ./Lib/test/test_sax.py Failed test_attrs_empty Failed test_attrs_wattr Failed test_double_quoteattr Failed test_escape_all Failed test_escape_basic Failed test_escape_extra Failed test_expat_attrs_empty Failed test_expat_attrs_wattr Failed test_expat_dtdhandler Failed test_expat_entityresolver Failed test_expat_file Failed test_expat_incomplete Failed test_expat_incremental Failed test_expat_incremental_reset Failed test_expat_inpsource_filename Failed test_expat_inpsource_location Failed test_expat_inpsource_stream Failed test_expat_inpsource_sysid Failed test_expat_locator_noinfo Failed test_expat_locator_withinfo Failed test_expat_nsattrs_empty Failed test_expat_nsattrs_wattr Failed test_filter_basic Failed test_make_parser Failed test_make_parser2 Failed test_nsattrs_empty Failed test_nsattrs_wattr Failed test_quoteattr_basic Failed test_single_double_quoteattr Failed test_single_quoteattr Failed test_unescape_all Failed test_unescape_amp_extra Failed test_unescape_basic Failed test_unescape_extra Failed test_xmlgen_attr_escape Failed test_xmlgen_basic Failed test_xmlgen_content Failed test_xmlgen_content_escape Failed test_xmlgen_ignorable Failed test_xmlgen_ns Failed test_xmlgen_pi 41 tests, 0 failures ---------------------------------------------------------------------- >Comment By: Richard Townsend (rptownsend) Date: 2003-12-24 12:46 Message: Logged In: YES user_id=200117 I have now installed Python-2.3.3 plus PyXML-0.8.3 and the core dump in 'make test' has returned. So, it looks like a compatability problem with PyXML-0.8.3 ? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-12-24 09:25 Message: Logged In: YES user_id=200117 HP-UX capulet B.11.11 U 9000/785 2002932658 unlimited-user license This is the configure command I used: base_inst_dir=/opt python_link=${base_inst_dir}/python CC=cc OPT="+O2 -z +Onofltacc +ESlit +Oentrysched +Odataprefetch +Onolimit +DA2.0" INSTALL="./install-sh -c" ./configure --with-threads --without-gcc --with-cxx=/opt/aCC/bin/aCC --without-libd --with-cycle-gc --prefix=$python_link --exec-prefix=$python_link This is exactly the same command I have used on previous Python 2.3 releases which did not core dump in 'make test'. Note it uses the native HP compiler. I have now just rebuilt without optimisation, using: CC=cc INSTALL="./install-sh -c" ./configure --with-threads --without-gcc --with-cxx=/opt/aCC/bin/aCC --without-libd --with-cycle-gc --prefix=$python_link --exec-prefix=$python_link It still core dumps at the same point in the second pass of 'make test'. I have attached a stack trace from the core file. I noticed that this has references to /opt/python/lib/python2.3/site- packages/_xmlplus/parsers/pyexpat.sl. This is the previous installation of Python 2.3.2 plus PyXML-0.8.3. I wondered if I had forgotten to reset $PYTHONPATH before running 'make test', so I did that and tried again but it still core dumped. So next I reset the symbolic link /opt/python to the empty directory /opt/python-2.3.3 and ran 'make test' again. This time it didn't core dump! So why does the test suite access the previous installation when PYTHONPATH doesn't include it? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-24 03:32 Message: Logged In: YES user_id=33168 On an HP box I tried, I don't have any problems. * HP-UX taylor B.11.00 A 9000/829 * gcc 3.2 What compiler are you using? Have you tried on the HP test drive machines? Are you compiling with optimization? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864379&group_id=5470 From noreply at sourceforge.net Wed Dec 24 08:23:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 24 08:23:46 2003 Subject: [ python-Bugs-864379 ] Python 2.3.3 make test core dump on HP-UX11i Message-ID: Bugs item #864379, was opened at 2003-12-22 06:40 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864379&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) >Assigned to: Martin v. L?wis (loewis) Summary: Python 2.3.3 make test core dump on HP-UX11i Initial Comment: I built Python-2.3.3 on HP-UX11i in the same way that I built Python-2.3.2. However, this time running 'make test' core dumps on the second pass with: test_sax *** Termination signal 138 Stop. The output from test_sax.py is given below. Each test appears to fail, but the summary gives zero failures (this also happens with Python 2.3.2, but 'make test' doesn't core dump on that release). > ./python ./Lib/test/test_sax.py Failed test_attrs_empty Failed test_attrs_wattr Failed test_double_quoteattr Failed test_escape_all Failed test_escape_basic Failed test_escape_extra Failed test_expat_attrs_empty Failed test_expat_attrs_wattr Failed test_expat_dtdhandler Failed test_expat_entityresolver Failed test_expat_file Failed test_expat_incomplete Failed test_expat_incremental Failed test_expat_incremental_reset Failed test_expat_inpsource_filename Failed test_expat_inpsource_location Failed test_expat_inpsource_stream Failed test_expat_inpsource_sysid Failed test_expat_locator_noinfo Failed test_expat_locator_withinfo Failed test_expat_nsattrs_empty Failed test_expat_nsattrs_wattr Failed test_filter_basic Failed test_make_parser Failed test_make_parser2 Failed test_nsattrs_empty Failed test_nsattrs_wattr Failed test_quoteattr_basic Failed test_single_double_quoteattr Failed test_single_quoteattr Failed test_unescape_all Failed test_unescape_amp_extra Failed test_unescape_basic Failed test_unescape_extra Failed test_xmlgen_attr_escape Failed test_xmlgen_basic Failed test_xmlgen_content Failed test_xmlgen_content_escape Failed test_xmlgen_ignorable Failed test_xmlgen_ns Failed test_xmlgen_pi 41 tests, 0 failures ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-24 08:23 Message: Logged In: YES user_id=33168 I think I remember hearing something about an incompatibility. The two best people to discuss this are probably Martin v. Loewis and Fred Drake. I'm assigning to Martin, perhaps he can shed some more light on the issues. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-12-24 07:46 Message: Logged In: YES user_id=200117 I have now installed Python-2.3.3 plus PyXML-0.8.3 and the core dump in 'make test' has returned. So, it looks like a compatability problem with PyXML-0.8.3 ? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-12-24 04:25 Message: Logged In: YES user_id=200117 HP-UX capulet B.11.11 U 9000/785 2002932658 unlimited-user license This is the configure command I used: base_inst_dir=/opt python_link=${base_inst_dir}/python CC=cc OPT="+O2 -z +Onofltacc +ESlit +Oentrysched +Odataprefetch +Onolimit +DA2.0" INSTALL="./install-sh -c" ./configure --with-threads --without-gcc --with-cxx=/opt/aCC/bin/aCC --without-libd --with-cycle-gc --prefix=$python_link --exec-prefix=$python_link This is exactly the same command I have used on previous Python 2.3 releases which did not core dump in 'make test'. Note it uses the native HP compiler. I have now just rebuilt without optimisation, using: CC=cc INSTALL="./install-sh -c" ./configure --with-threads --without-gcc --with-cxx=/opt/aCC/bin/aCC --without-libd --with-cycle-gc --prefix=$python_link --exec-prefix=$python_link It still core dumps at the same point in the second pass of 'make test'. I have attached a stack trace from the core file. I noticed that this has references to /opt/python/lib/python2.3/site- packages/_xmlplus/parsers/pyexpat.sl. This is the previous installation of Python 2.3.2 plus PyXML-0.8.3. I wondered if I had forgotten to reset $PYTHONPATH before running 'make test', so I did that and tried again but it still core dumped. So next I reset the symbolic link /opt/python to the empty directory /opt/python-2.3.3 and ran 'make test' again. This time it didn't core dump! So why does the test suite access the previous installation when PYTHONPATH doesn't include it? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-23 22:32 Message: Logged In: YES user_id=33168 On an HP box I tried, I don't have any problems. * HP-UX taylor B.11.00 A 9000/829 * gcc 3.2 What compiler are you using? Have you tried on the HP test drive machines? Are you compiling with optimization? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864379&group_id=5470 From noreply at sourceforge.net Wed Dec 24 12:28:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 24 12:28:05 2003 Subject: [ python-Bugs-857881 ] ConfigParser bug Message-ID: Bugs item #857881, was opened at 2003-12-10 16:00 Message generated for change (Comment added) made by jrm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857881&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michel Martin (mrsmile) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser bug Initial Comment: Python Version: 2.3.2c1 OS: Windows 2000 ----------------------- Hello, I was trying to use the ConfigParser provided with Python when I realized that there is a problem with the case in the string passed in the Interpolation feature. Explicitely, test1 works but test2 doesn't. You can see by yourself with the attachment. =========================== [Test1] logFullPath: c:/logs/%(logfilename)s logFilename=test.log [Test2] logFullPath: c:/logs/%(logFilename)s logFilename=test.log =========================== Using a capital letter in %('string')s doesn't work, even if the key is declared with a capital letter. How could we fix this? Thanks for your help, Best regards, Michel Martin ---------------------------------------------------------------------- Comment By: Jordan R McCoy (jrm) Date: 2003-12-24 11:28 Message: Logged In: YES user_id=813983 See patch request #865455 for an explanation of the problem and a patch solution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857881&group_id=5470 From noreply at sourceforge.net Wed Dec 24 12:40:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 24 12:40:30 2003 Subject: [ python-Bugs-856617 ] HTMLParser parsers AT&T to AT Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Bugs item #856617, was opened at 2003-12-08 20:47 Message generated for change (Comment added) made by jrm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856617&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hammer Lee (lhy719) Assigned to: Nobody/Anonymous (nobody) Summary: HTMLParser parsers AT&T to AT Initial Comment: I use HTMLParser to parse HTML files. There is an mistake when HTML contents have '&', like
AT&T Research Labs Cambridge - WinVNC Version 3, 3, 3, 7. HTMLParser parses "AT&T Research" to "AT Research". It happens on "ETTC&P EpSCTWeb_Fr Application Version 1, 0, 0, 1" also. I'm a newbie in Python, I don't know how to solve it. ---------------------------------------------------------------------- Comment By: Jordan R McCoy (jrm) Date: 2003-12-24 11:40 Message: Logged In: YES user_id=813983 The HTML being parsed should use '&' for the '&'; however, HTMLParser uses this regexp to identify entity references (line 20): entityref = re.compile( '&([a-zA-Z][-.a-zA-Z0-9]*)[^a-zA-Z0-9]') which doesn't match the ';' required at the end by the HTML specification. This may or may not be intentional. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2003-12-11 12:32 Message: Logged In: YES user_id=764593 Technically, that isn't legal html; they're supposed to write & (follow the & with the word "amp;"), because & is an escape character. That said, it is a pretty common error in web pages. The parser already recovers at the next space (instead of waiting for a ";", and I think it would be reasonable to just return the "&T" when T doesn't turn out to be a known entity. You would do this by overriding handle_entityref -- but to be honest, I suspect that you're "really" using some other library (or local code) which already does this, so you may have to make the modification there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856617&group_id=5470 From noreply at sourceforge.net Thu Dec 25 14:42:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 25 14:43:01 2003 Subject: [ python-Bugs-856706 ] popen3 under threads reports different stderr results Message-ID: Bugs item #856706, was opened at 2003-12-09 01:08 Message generated for change (Comment added) made by gaul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856706&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Steven Howe (stevenhowe) Assigned to: Nobody/Anonymous (nobody) Summary: popen3 under threads reports different stderr results Initial Comment: Using os.popen3 inside a thread (start_new_thread) returns different results from the stderr file dev. I discovered this while trying to trap badblocks program output. I have usb floppy I am trying to format, after a badblock check. My floppy is on /dev/sdb. code: import thread import os def dd( outfilename ): cmd='/sbin/badblocks -n -s -v -c 16 -b 512 /dev/sdb' channels = os.popen3( cmd ) ch = ' ' ff = '/tmp/%s' % outfilename out=open( ff ,'w') while ch != '': ch = channels[2].read(1) out.write( ch ) Run two ways. First as a stand alone code. Then as a threaded program. def( 'nothread.err' ) thead.start_new_thread( def, ( 'thread.err' ) ) --------------- Now view the results with od -ta. You will see that the results are very different. All the the verbose data, on current blocks completed, are missing. Steven Howe ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-12-25 13:42 Message: Logged In: YES user_id=139865 This appears to be a duplicate of #853411. The thread on python-dev with subject "Python threads end up blocking signals in subprocesses" discusses this. ---------------------------------------------------------------------- Comment By: Steven Howe (stevenhowe) Date: 2003-12-12 13:02 Message: Logged In: YES user_id=916892 Hello Gaul. Well I found a work around. Using threading.Thread, I init a routine that forks and execv's a script (execv has no method to accept redirects '> 2>') that runs the badblocks program and route output to files. Then I the a thread that uses open() to attach the to a progress reading routine and when complete for the badblock list (if any). This method created another problem. Popen3 does not return an end of file ( '' ) until the process has ended. With badblocks forked, there is no syncronization between my script and the badblocks output. So I can and do overrun the output, which then returns an EOF. Another workaround: I wrote a routine to make sure I never read to the end of file: readsize = os.stat(fname)[stat.ST_SIZE] - fptr.tell() - BIAS All this so I can using threading. No doubt you're asking why use threading? I'm making a pygtk app similar to 'gfloppy' that can handle USB floppies. I need to make a progress meter. Using threading allows a GTK call back to examine the current status of badblocks. But a fix would be preferable. Thanks, Steven Howe ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-12-12 04:03 Message: Logged In: YES user_id=139865 Confirmed with Python CVS and Fedora on x86. e2fsprogs/misc/badblocks:alarm_intr sets a SIGALRM handler and calls alarm(1), but it is not getting fired. I will look into this further. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856706&group_id=5470 From noreply at sourceforge.net Fri Dec 26 15:29:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 26 15:29:49 2003 Subject: [ python-Bugs-866081 ] re infinite loop on valid input Message-ID: Bugs item #866081, was opened at 2003-12-26 20:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=866081&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: David Jeske (jeske) Assigned to: Nobody/Anonymous (nobody) Summary: re infinite loop on valid input Initial Comment: Run the following two lines in an interpreter and watch your CPU get eaten in an infinite loop inside the RE library: >>> a_line = " http://groups.yahoo.com/group/tuna/" >>> re.search("/(([^ ]+)){30,}",a_line) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=866081&group_id=5470 From noreply at sourceforge.net Sat Dec 27 01:18:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 27 01:18:14 2003 Subject: [ python-Bugs-866222 ] SimpleHTTPServer docs out of date Message-ID: Bugs item #866222, was opened at 2003-12-27 03:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=866222&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gabriel Genellina (gagenellina) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleHTTPServer docs out of date Initial Comment: The Library documentation about SimpleHTTPServer. py is out of date: In extensions_map: Default is signified by an empty string, and is considered to be text/plain.[...] should read Default is signified by an empty string, and is considered to be application/octet-stream. In do_GET: If the request was mapped to a directory, a 403 respond is output, followed by the explanation 'Directory listing not supported'. Any IOError [...] should read: If the request was mapped to a directory, a file named index.html or index.htm (in that order) is searched inside it. If found, then its contents are returned; otherwise a directory listing is generated using os.listdir. (In case the os.listdir call fails, a 404 error response is sent). Any IOError [...] Later in do_GET: The file is always opened in binary mode. should read: If the file MIME type starts with 'text/' the file is opened in text mode; in any other case binary mode is used. The docstrings inside the module are outdated too. Line 28 (class SimpleHTTPRequestHandler) says: It assumes that all files are plain text files unless they have the extension ".html" in which case it assumes they are HTML files. That's not true; that paragraph should be deleted, or make a reference to method guess_type() below. Docstring for method guess_type() says: [...] using text/plain as a default [...] should read: [...] using application/octet-stream as a default [...] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=866222&group_id=5470 From noreply at sourceforge.net Sun Dec 28 11:25:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 28 11:25:35 2003 Subject: [ python-Bugs-849046 ] gzip.GzipFile is slow Message-ID: Bugs item #849046, was opened at 2003-11-25 16:45 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=849046&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 3 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: gzip.GzipFile is slow Initial Comment: gzip.GzipFile is significantly (an order of a magnitude) slower than using the gzip binary. I've been bitten by this several times, and have replaced "fd = gzip.open('somefile', 'r')" by "fd = os.popen('gzcat somefile', 'r')" on several occassions. Would a patch that implemented GzipFile in C have any change of being accepted? ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2003-12-28 17:25 Message: Logged In: YES user_id=580910 Leaving out the assignment sure sped thing up, but only because the input didn't contain lines anymore ;-) I did an experiment where I replaced self.extrabuf by a list, but that did slow things down. This may be because there seemed to be very few chunks in the buffer (most of the time just 2) According to profile.run('testit()') the function below spends about 50% of its time in the readline method: def testit() fd = gzip.open('testfile.gz', 'r') ln = fd.readline() cnt = bcnt = 0 while ln: ln = fd.readline() cnt += 1 bcnt += len(ln) print bcnt, cnt return bcnt,cnt testfile.gz is a simple textfile containing 40K lines of about 70 characters each. Replacing the 'buffers' in readline by a string (instead of a list) slightly speeds things up (about 10%). Other experiments did not bring any improvement. Even writing a simple C function to split the buffer returned by self.read() didn't help a lot (splitline(strval, max) -> match, rest, match is strval upto the first newline and at most max characters, rest is the rest of strval). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-12-23 18:10 Message: Logged In: YES user_id=11375 It should be simple to check if the string operations are responsible -- comment out the 'self.extrabuf = self.extrabuf + data' in _add_read_data. If that makes a big difference, then _read should probably be building a list instead of modifying a string. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-12-04 20:51 Message: Logged In: YES user_id=357491 Looking at GzipFile.read and ._read , I think a large chunk of time is burned in the decompression of small chunks of data. It initially reads and decompresses 1024 bits, and then if that read did not hit the EOF, it multiplies it by 2 and continues until the EOF is reached and then finishes up. The problem is that for each read a call to _read is made that sets up a bunch of objects. I would not be surprised if the object creation and teardown is hurting the performance. I would also not be surprised if the reading of small chunks of data is an initial problem as well. This is all guesswork, though, since I did not run the profiler on this. *But*, there might be a good reason for reading small chunks. If you are decompressing a large file, you might run out of memory very quickly by reading the file into memory *and* decompressing at the same time. Reading it in successively larger chunks means you don't hold the file's entire contents in memory at any one time. So the question becomes whether causing your memory to get overloaded and major thrashing on your swap space is worth the performance increase. There is also the option of inlining _read into 'read', but since it makes two calls that seems like poor abstraction and thus would most likely not be accepted as a solution. Might be better to just have some temporary storage in an attribute of objects that are used in every call to _read and then delete the attribute once the reading is done. Or maybe allow for an optional argument to read that allowed one to specify the initial read size (and that might be a good way to see if any of these ideas are reasonable; just modify the code to read the whole thing and go at it from that). But I am in no position to make any of these calls, though, since I never use gzip. If someone cares to write up a patch to try to fix any of this it will be considered. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2003-11-25 23:05 Message: Logged In: YES user_id=764593 In the library, I see a fair amount of work that doesn't really do anything except make sure you're getting exactly a line at a time. Would it be an option to just read the file in all at once, split it on newlines, and then loop over the list? (Or read it into a cStringIO, I suppose.) ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2003-11-25 22:12 Message: Logged In: YES user_id=580910 To be more precise: $ ls -l gzippedfile -rw-r--r-- 1 ronald admin 354581 18 Nov 10:21 gzippedfile $ gzip -l gzippedfile compressed uncompr. ratio uncompressed_name 354581 1403838 74.7% gzippedfile The file contains about 45K lines of text (about 40 characters/line) $ time gzip -dc gzippedfile > /dev/null real 0m0.100s user 0m0.060s sys 0m0.000s $ python read.py gzippedfile > /dev/null real 0m3.222s user 0m3.020s sys 0m0.070s $ cat read.py #!/usr/bin/env python import sys import gzip fd = gzip.open(sys.argv[1], 'r') ln = fd.readline() while ln: sys.stdout.write(ln) ln = fd.readline() The difference is also significant for larger files (e.g. the difference is not caused by the different startup-times) ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2003-11-25 22:03 Message: Logged In: YES user_id=580910 The files are created using GzipFile. That speed is acceptable because it happens in a batch-job, reading back is the problem because that happens on demand and a user is waiting for the results. gzcat is a *uncompress* utility (specifically it is "gzip -dc"), the compression level is irrelevant for this discussion. The python code seems to do quite some string manipulation, maybe that is causing the slowdown (I'm using fd.readline() in a fairly tight loop). I'll do some profiling to check what is taking so much time. BTW. I'm doing this on Unix systems (Sun Solaris and Mac OS X). ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2003-11-25 18:35 Message: Logged In: YES user_id=764593 Which compression level are you using? It looks like most of the work is already done by zlib (which is in C), but GzipFile defaults to compression level 9. Many other zips (including your gzcat?) default to a lower (but much faster) compression level. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=849046&group_id=5470 From noreply at sourceforge.net Sun Dec 28 17:05:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 28 17:05:55 2003 Subject: [ python-Bugs-864944 ] doctest chokes on recursive members Message-ID: Bugs item #864944, was opened at 2003-12-23 06:51 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864944&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gintautas Miliauskas (gintautasm) Assigned to: Nobody/Anonymous (nobody) Summary: doctest chokes on recursive members Initial Comment: doctests recurse infinitely when they find a recursive member in a class. A simple example: --b0rk.py-- class Crash: pass Crash.c = Crash ----- --test.py-- import doctest import b0rk doctest.testmod(b0rk) ----- --output of test.py-- Traceback (most recent call last): File "test.py", line 5, in ? doctest.testmod(b0rk) File "/usr/lib/python2.3/doctest.py", line 1148, in testmod f, t = tester.rundict(m.__dict__, name, m) File "/usr/lib/python2.3/doctest.py", line 908, in rundict f2, t2 = self.__runone(value, name + "." + thisname) File "/usr/lib/python2.3/doctest.py", line 1069, in __runone return self.rundoc(target, name) File "/usr/lib/python2.3/doctest.py", line 828, in rundoc f2, t2 = self.run__test__(d, name) <.............................> File "/usr/lib/python2.3/doctest.py", line 935, in run__test__ f, t = self.rundoc(v, thisname) File "/usr/lib/python2.3/doctest.py", line 790, in rundoc for tag, kind, homecls, value in _classify_class_attrs(object): File "/usr/lib/python2.3/inspect.py", line 201, in classify_class_attrs mro = getmro(cls) RuntimeError: maximum recursion depth exceeded ----- ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-12-28 17:05 Message: Logged In: YES user_id=593130 Traceback says crash happens in inspect.getmro and not in doctest itself. In 2.2.1, I get >>> class C: pass ... >>> C.c=C >>> import inspect as i >>> i.getmro(C) (,) However, mro resolution was changed for 2.3. See if above changes in 2.3. Or if calling on class inside imported module makes a difference. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864944&group_id=5470 From noreply at sourceforge.net Mon Dec 29 05:46:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 29 05:46:57 2003 Subject: [ python-Bugs-864944 ] doctest chokes on recursive members Message-ID: Bugs item #864944, was opened at 2003-12-23 13:51 Message generated for change (Comment added) made by gintautasm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864944&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gintautas Miliauskas (gintautasm) Assigned to: Nobody/Anonymous (nobody) Summary: doctest chokes on recursive members Initial Comment: doctests recurse infinitely when they find a recursive member in a class. A simple example: --b0rk.py-- class Crash: pass Crash.c = Crash ----- --test.py-- import doctest import b0rk doctest.testmod(b0rk) ----- --output of test.py-- Traceback (most recent call last): File "test.py", line 5, in ? doctest.testmod(b0rk) File "/usr/lib/python2.3/doctest.py", line 1148, in testmod f, t = tester.rundict(m.__dict__, name, m) File "/usr/lib/python2.3/doctest.py", line 908, in rundict f2, t2 = self.__runone(value, name + "." + thisname) File "/usr/lib/python2.3/doctest.py", line 1069, in __runone return self.rundoc(target, name) File "/usr/lib/python2.3/doctest.py", line 828, in rundoc f2, t2 = self.run__test__(d, name) <.............................> File "/usr/lib/python2.3/doctest.py", line 935, in run__test__ f, t = self.rundoc(v, thisname) File "/usr/lib/python2.3/doctest.py", line 790, in rundoc for tag, kind, homecls, value in _classify_class_attrs(object): File "/usr/lib/python2.3/inspect.py", line 201, in classify_class_attrs mro = getmro(cls) RuntimeError: maximum recursion depth exceeded ----- ---------------------------------------------------------------------- >Comment By: Gintautas Miliauskas (gintautasm) Date: 2003-12-29 12:46 Message: Logged In: YES user_id=936754 I guess I snipped a little too much traceback... Here is a part of traceback (reproduced with python 2.2.) that illustrates the idea: <...> File "/usr/lib/python2.2/doctest.py", line 905, in run__test__ f, t = self.rundoc(v, thisname) File "/usr/lib/python2.2/doctest.py", line 798, in rundoc f2, t2 = self.run__test__(d, name) File "/usr/lib/python2.2/doctest.py", line 905, in run__test__ f, t = self.rundoc(v, thisname) File "/usr/lib/python2.2/doctest.py", line 798, in rundoc f2, t2 = self.run__test__(d, name) File "/usr/lib/python2.2/doctest.py", line 905, in run__test__ f, t = self.rundoc(v, thisname) File "/usr/lib/python2.2/doctest.py", line 798, in rundoc f2, t2 = self.run__test__(d, name) <...> It's definitely not a fault of getmro(). Besides, I've tested and the crash occurs on Python 2.1, 2.2 and 2.3. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-12-29 00:05 Message: Logged In: YES user_id=593130 Traceback says crash happens in inspect.getmro and not in doctest itself. In 2.2.1, I get >>> class C: pass ... >>> C.c=C >>> import inspect as i >>> i.getmro(C) (,) However, mro resolution was changed for 2.3. See if above changes in 2.3. Or if calling on class inside imported module makes a difference. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864944&group_id=5470 From noreply at sourceforge.net Mon Dec 29 05:52:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 29 05:52:39 2003 Subject: [ python-Bugs-864944 ] doctest chokes on recursive members Message-ID: Bugs item #864944, was opened at 2003-12-23 13:51 Message generated for change (Comment added) made by mgedmin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864944&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gintautas Miliauskas (gintautasm) Assigned to: Nobody/Anonymous (nobody) Summary: doctest chokes on recursive members Initial Comment: doctests recurse infinitely when they find a recursive member in a class. A simple example: --b0rk.py-- class Crash: pass Crash.c = Crash ----- --test.py-- import doctest import b0rk doctest.testmod(b0rk) ----- --output of test.py-- Traceback (most recent call last): File "test.py", line 5, in ? doctest.testmod(b0rk) File "/usr/lib/python2.3/doctest.py", line 1148, in testmod f, t = tester.rundict(m.__dict__, name, m) File "/usr/lib/python2.3/doctest.py", line 908, in rundict f2, t2 = self.__runone(value, name + "." + thisname) File "/usr/lib/python2.3/doctest.py", line 1069, in __runone return self.rundoc(target, name) File "/usr/lib/python2.3/doctest.py", line 828, in rundoc f2, t2 = self.run__test__(d, name) <.............................> File "/usr/lib/python2.3/doctest.py", line 935, in run__test__ f, t = self.rundoc(v, thisname) File "/usr/lib/python2.3/doctest.py", line 790, in rundoc for tag, kind, homecls, value in _classify_class_attrs(object): File "/usr/lib/python2.3/inspect.py", line 201, in classify_class_attrs mro = getmro(cls) RuntimeError: maximum recursion depth exceeded ----- ---------------------------------------------------------------------- Comment By: Marius Gedminas (mgedmin) Date: 2003-12-29 12:52 Message: Logged In: YES user_id=44660 The fact that the traceback ends in getmro is just an accident. There is an infinite recursion between run__test__ and rundoc when a class attribute references the class itself. The problem was originally noticed by playing with Zope 3. Apparently Zope 3 interfaces add a class attribute that references the class itself (perhaps indirectly) and causes this problem to appear whenever a class declares that it implements some interface, e.g. from zope.interface import implements class SomeClass(object): """docstring >>> x = SomeClass() ... """ implements(ISomeInterface) Since Zope 3 component architecture requires that virtually all classes declare what interfaces they implement, it makes class doctests unusable with Zope 3. A possible solution is to keep a set of "seen" objects and check near the beginning of Tester.rundoc whether an object was already processed. ---------------------------------------------------------------------- Comment By: Gintautas Miliauskas (gintautasm) Date: 2003-12-29 12:46 Message: Logged In: YES user_id=936754 I guess I snipped a little too much traceback... Here is a part of traceback (reproduced with python 2.2.) that illustrates the idea: <...> File "/usr/lib/python2.2/doctest.py", line 905, in run__test__ f, t = self.rundoc(v, thisname) File "/usr/lib/python2.2/doctest.py", line 798, in rundoc f2, t2 = self.run__test__(d, name) File "/usr/lib/python2.2/doctest.py", line 905, in run__test__ f, t = self.rundoc(v, thisname) File "/usr/lib/python2.2/doctest.py", line 798, in rundoc f2, t2 = self.run__test__(d, name) File "/usr/lib/python2.2/doctest.py", line 905, in run__test__ f, t = self.rundoc(v, thisname) File "/usr/lib/python2.2/doctest.py", line 798, in rundoc f2, t2 = self.run__test__(d, name) <...> It's definitely not a fault of getmro(). Besides, I've tested and the crash occurs on Python 2.1, 2.2 and 2.3. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-12-29 00:05 Message: Logged In: YES user_id=593130 Traceback says crash happens in inspect.getmro and not in doctest itself. In 2.2.1, I get >>> class C: pass ... >>> C.c=C >>> import inspect as i >>> i.getmro(C) (,) However, mro resolution was changed for 2.3. See if above changes in 2.3. Or if calling on class inside imported module makes a difference. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864944&group_id=5470 From noreply at sourceforge.net Mon Dec 29 06:46:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 29 06:46:26 2003 Subject: [ python-Bugs-867012 ] socket: missing IPV6 constants Message-ID: Bugs item #867012, was opened at 2003-12-29 11:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=867012&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: cypherpunks (cypherpunks) Assigned to: Nobody/Anonymous (nobody) Summary: socket: missing IPV6 constants Initial Comment: From: Erno Kuusela hello, there are some IPV6-related constants missing from the socket module. IPV6_V6ONLY is one that i ran into, and looking at http://www.ietf.org/rfc/rfc3493.txt AI_NUMERICSERV and PF_INET6 are missing. in addition in the gnu libc headers () there are many more next to IPV6_V6ONLY that aren't included. i don't know which of those are relevant because some require structs as arguments and handling those requires more than just a constant and python has not traditionally provided all of them even for ipv4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=867012&group_id=5470 From noreply at sourceforge.net Mon Dec 29 09:49:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 29 09:49:52 2003 Subject: [ python-Bugs-852347 ] add support for cjkcodecs to Python email Message-ID: Bugs item #852347, was opened at 2003-12-01 17:05 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852347&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Barry A. Warsaw (bwarsaw) Summary: add support for cjkcodecs to Python email Initial Comment: As discussed last week on the email-sig list, the attached patch adds support for the CJKCodecs package as an alternative to the {Chinese,Japanese,Korean}Codecs packages. CJKCodecs 1.0.2 and above should work with this patch. This is advantageous because the Chinese and KoreanCodecs packages are no longer supported,maintained or available for download. This patch does not break compatibility with {Chinese,Japanese,Korean}Codecs, so they can still be used if desired. Lastly, this patch fixes a small typo that broke GB2312. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-29 09:49 Message: Logged In: YES user_id=12800 Correct me if I'm wrong, but won't the attached patch work better? It simply removes the entries from CODEC_MAP that are already provided by cjkcodecs.aliases (and japanese.aliases and korean.aliases). See Charset.py.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852347&group_id=5470 From noreply at sourceforge.net Mon Dec 29 09:52:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 29 09:52:29 2003 Subject: [ python-Bugs-852347 ] add support for cjkcodecs to Python email Message-ID: Bugs item #852347, was opened at 2003-12-01 17:05 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852347&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Barry A. Warsaw (bwarsaw) Summary: add support for cjkcodecs to Python email Initial Comment: As discussed last week on the email-sig list, the attached patch adds support for the CJKCodecs package as an alternative to the {Chinese,Japanese,Korean}Codecs packages. CJKCodecs 1.0.2 and above should work with this patch. This is advantageous because the Chinese and KoreanCodecs packages are no longer supported,maintained or available for download. This patch does not break compatibility with {Chinese,Japanese,Korean}Codecs, so they can still be used if desired. Lastly, this patch fixes a small typo that broke GB2312. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-29 09:52 Message: Logged In: YES user_id=12800 Oops, with the typo fix for gb2312. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-29 09:49 Message: Logged In: YES user_id=12800 Correct me if I'm wrong, but won't the attached patch work better? It simply removes the entries from CODEC_MAP that are already provided by cjkcodecs.aliases (and japanese.aliases and korean.aliases). See Charset.py.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852347&group_id=5470 From noreply at sourceforge.net Mon Dec 29 10:19:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 29 10:19:20 2003 Subject: [ python-Bugs-852347 ] add support for cjkcodecs to Python email Message-ID: Bugs item #852347, was opened at 2003-12-01 17:05 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852347&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Barry A. Warsaw (bwarsaw) Summary: add support for cjkcodecs to Python email Initial Comment: As discussed last week on the email-sig list, the attached patch adds support for the CJKCodecs package as an alternative to the {Chinese,Japanese,Korean}Codecs packages. CJKCodecs 1.0.2 and above should work with this patch. This is advantageous because the Chinese and KoreanCodecs packages are no longer supported,maintained or available for download. This patch does not break compatibility with {Chinese,Japanese,Korean}Codecs, so they can still be used if desired. Lastly, this patch fixes a small typo that broke GB2312. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-29 10:19 Message: Logged In: YES user_id=12800 One more rev of Charset.py.diff ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-29 09:52 Message: Logged In: YES user_id=12800 Oops, with the typo fix for gb2312. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-29 09:49 Message: Logged In: YES user_id=12800 Correct me if I'm wrong, but won't the attached patch work better? It simply removes the entries from CODEC_MAP that are already provided by cjkcodecs.aliases (and japanese.aliases and korean.aliases). See Charset.py.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852347&group_id=5470 From noreply at sourceforge.net Mon Dec 29 23:33:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 29 23:33:33 2003 Subject: [ python-Bugs-852347 ] add support for cjkcodecs to Python email Message-ID: Bugs item #852347, was opened at 2003-12-01 17:05 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852347&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Barry A. Warsaw (bwarsaw) Summary: add support for cjkcodecs to Python email Initial Comment: As discussed last week on the email-sig list, the attached patch adds support for the CJKCodecs package as an alternative to the {Chinese,Japanese,Korean}Codecs packages. CJKCodecs 1.0.2 and above should work with this patch. This is advantageous because the Chinese and KoreanCodecs packages are no longer supported,maintained or available for download. This patch does not break compatibility with {Chinese,Japanese,Korean}Codecs, so they can still be used if desired. Lastly, this patch fixes a small typo that broke GB2312. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-29 23:33 Message: Logged In: YES user_id=12800 I'm not even sure this patch is correct, since it breaks the test suite. The problem is that self.output_codec ends up being different with the patch than without it (in Charset.__init__()). For example: Python 2.3.3 (#1, Dec 19 2003, 11:33:00) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from email.Charset import Charset >>> c = Charset('euc-jp') >>> c.output_codec 'japanese.iso-2022-jp' >>> But now with Charset.py.diff applied: ... >>> c.output_codec 'euc-jp' We need to figure out what the right thing to do here is. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-29 10:19 Message: Logged In: YES user_id=12800 One more rev of Charset.py.diff ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-29 09:52 Message: Logged In: YES user_id=12800 Oops, with the typo fix for gb2312. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-29 09:49 Message: Logged In: YES user_id=12800 Correct me if I'm wrong, but won't the attached patch work better? It simply removes the entries from CODEC_MAP that are already provided by cjkcodecs.aliases (and japanese.aliases and korean.aliases). See Charset.py.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852347&group_id=5470 From noreply at sourceforge.net Tue Dec 30 00:59:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 30 00:59:32 2003 Subject: [ python-Bugs-852347 ] add support for cjkcodecs to Python email Message-ID: Bugs item #852347, was opened at 2003-12-01 15:05 Message generated for change (Comment added) made by jasonrm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852347&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Barry A. Warsaw (bwarsaw) Summary: add support for cjkcodecs to Python email Initial Comment: As discussed last week on the email-sig list, the attached patch adds support for the CJKCodecs package as an alternative to the {Chinese,Japanese,Korean}Codecs packages. CJKCodecs 1.0.2 and above should work with this patch. This is advantageous because the Chinese and KoreanCodecs packages are no longer supported,maintained or available for download. This patch does not break compatibility with {Chinese,Japanese,Korean}Codecs, so they can still be used if desired. Lastly, this patch fixes a small typo that broke GB2312. ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2003-12-29 22:59 Message: Logged In: YES user_id=85984 comments regarding Barry's Charset.py.diff: You shouldn't mention KoreanCodecs and ChineseCodecs in the comments as alternatives to CJKCodecs. Both are no longer maintained, or even available for download. Both have been completely replaced by CJKCodecs. Only JapaneseCodecs remains as a substitute package. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-29 21:33 Message: Logged In: YES user_id=12800 I'm not even sure this patch is correct, since it breaks the test suite. The problem is that self.output_codec ends up being different with the patch than without it (in Charset.__init__()). For example: Python 2.3.3 (#1, Dec 19 2003, 11:33:00) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from email.Charset import Charset >>> c = Charset('euc-jp') >>> c.output_codec 'japanese.iso-2022-jp' >>> But now with Charset.py.diff applied: ... >>> c.output_codec 'euc-jp' We need to figure out what the right thing to do here is. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-29 08:19 Message: Logged In: YES user_id=12800 One more rev of Charset.py.diff ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-29 07:52 Message: Logged In: YES user_id=12800 Oops, with the typo fix for gb2312. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-29 07:49 Message: Logged In: YES user_id=12800 Correct me if I'm wrong, but won't the attached patch work better? It simply removes the entries from CODEC_MAP that are already provided by cjkcodecs.aliases (and japanese.aliases and korean.aliases). See Charset.py.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852347&group_id=5470 From noreply at sourceforge.net Tue Dec 30 04:15:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 30 04:15:40 2003 Subject: [ python-Bugs-867556 ] html problem in mailbox docs Message-ID: Bugs item #867556, was opened at 2003-12-30 18:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=867556&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: html problem in mailbox docs Initial Comment: The document of mailbox has an odd hyperlink. http://www.python.org/doc/current/lib/module- mailbox.html For more information, see Unix: Why the Content- Length Format is Bad" >Configuring Netscape Mail on Unix: Why the Content-Length Format is Bad. The site title is duplicated and includes a '>'. The link should look like this: For more information, see Configuring Netscape Mail on Unix: Why the Content-Length Format is Bad. Probably UNIX in libmailbox.tex causes the problem and fails to convert to a valid html markup. In Python 2.2, I can't see this bug. http://www.python.org/doc/2.2.3/lib/module- mailbox.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=867556&group_id=5470 From noreply at sourceforge.net Tue Dec 30 06:16:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 30 06:16:52 2003 Subject: [ python-Bugs-867012 ] socket: missing IPV6 constants Message-ID: Bugs item #867012, was opened at 2003-12-29 12:46 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=867012&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: cypherpunks (cypherpunks) Assigned to: Nobody/Anonymous (nobody) Summary: socket: missing IPV6 constants Initial Comment: From: Erno Kuusela hello, there are some IPV6-related constants missing from the socket module. IPV6_V6ONLY is one that i ran into, and looking at http://www.ietf.org/rfc/rfc3493.txt AI_NUMERICSERV and PF_INET6 are missing. in addition in the gnu libc headers () there are many more next to IPV6_V6ONLY that aren't included. i don't know which of those are relevant because some require structs as arguments and handling those requires more than just a constant and python has not traditionally provided all of them even for ipv4. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-12-30 12:16 Message: Logged In: YES user_id=21627 This is now fixed in socketmodule.c 1.281, where I have added constants from RFCs 3493 and 3542 (IPV6_* from the latter). I haven't added PF_INET6, since we don't have any other PF_ constants (except for PF_PACKET); they are redundant with the AF_ constants, right? In any case, if you find that more constants are still missing, please submit a new report. Ideally, please include a use case for the constant as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=867012&group_id=5470 From noreply at sourceforge.net Tue Dec 30 06:21:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 30 06:21:31 2003 Subject: [ python-Bugs-856617 ] HTMLParser parsers AT&T to AT Message-ID: Bugs item #856617, was opened at 2003-12-09 03:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856617&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Hammer Lee (lhy719) Assigned to: Nobody/Anonymous (nobody) >Summary: HTMLParser parsers AT&T to AT Initial Comment: I use HTMLParser to parse HTML files. There is an mistake when HTML contents have '&', like
AT&T Research Labs Cambridge - WinVNC Version 3, 3, 3, 7. HTMLParser parses "AT&T Research" to "AT Research". It happens on "ETTC&P EpSCTWeb_Fr Application Version 1, 0, 0, 1" also. I'm a newbie in Python, I don't know how to solve it. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-12-30 12:21 Message: Logged In: YES user_id=21627 What do you mean, "it parses it to AT Research". It most certainly does no such thing. Instead, it invokes handle_entityref with the "T" entity, which you should process. Closing as not-a-bug ---------------------------------------------------------------------- Comment By: Jordan R McCoy (jrm) Date: 2003-12-24 18:40 Message: Logged In: YES user_id=813983 The HTML being parsed should use '&' for the '&'; however, HTMLParser uses this regexp to identify entity references (line 20): entityref = re.compile( '&([a-zA-Z][-.a-zA-Z0-9]*)[^a-zA-Z0-9]') which doesn't match the ';' required at the end by the HTML specification. This may or may not be intentional. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2003-12-11 19:32 Message: Logged In: YES user_id=764593 Technically, that isn't legal html; they're supposed to write & (follow the & with the word "amp;"), because & is an escape character. That said, it is a pretty common error in web pages. The parser already recovers at the next space (instead of waiting for a ";", and I think it would be reasonable to just return the "&T" when T doesn't turn out to be a known entity. You would do this by overriding handle_entityref -- but to be honest, I suspect that you're "really" using some other library (or local code) which already does this, so you may have to make the modification there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856617&group_id=5470 From noreply at sourceforge.net Tue Dec 30 06:25:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 30 06:25:50 2003 Subject: [ python-Bugs-618593 ] Windows binary missing IPv6 support Message-ID: Bugs item #618593, was opened at 2002-10-04 17:07 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618593&group_id=5470 Category: Windows >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Toni Garcia (zolty) Assigned to: Nobody/Anonymous (nobody) Summary: Windows binary missing IPv6 support Initial Comment: The Windows binary build from www.python.org appears to be missing IPv6 support. The IP configuration in my Windows XP + Service Pack 1: C:\Documents and Settings\zolty>ipconfig Configuraci?n IP de Windows Adaptador Ethernet Conexi?n de ?rea local : Sufijo de conexi?n espec?fica DNS : Direcci?n IP. . . . . . . . . . . : 192.168.0.2 M?scara de subred . . . . . . . . : 255.255.255.0 Direcci?n IP. . . . . . . . . . . : fe80::200:1cff:fe04:cae6%4 Puerta de enlace predeterminada : 192.168.0.1 Here's an example of a socket with ipv6 protocol/family: Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import socket >>> a=socket.socket (socket.AF_INET6,socket.SOCK_STREAM) Traceback (most recent call last): File "", line 1, in ? AttributeError: 'module' object has no attribute 'AF_INET6' >>> ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-12-30 12:25 Message: Logged In: YES user_id=21627 Since Python 2.3 is not build with VC.NET either, moving the target release for this issue to Python 2.4. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-05 11:56 Message: Logged In: YES user_id=21627 While your observation is correct, I fail to see the importance of this problem. Please understand that what you want is unimplementable with MSVC6, since it does not provide the necessary header files and library routines. IPv6 support is only available if you use CVS Python, and VC.NET. I have changed the group to Python 2.3; for Python 2.2, this would be a new feature, and thus won't be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618593&group_id=5470 From noreply at sourceforge.net Tue Dec 30 06:27:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 30 06:27:26 2003 Subject: [ python-Bugs-744164 ] ipv6 sockaddr is bad Message-ID: Bugs item #744164, was opened at 2003-05-27 12:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=744164&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: cypherpunks (cypherpunks) Assigned to: Nobody/Anonymous (nobody) Summary: ipv6 sockaddr is bad Initial Comment: ipv6 addrinfo becomes a 4-tuple in python, with additional scope-id and flowinfo members that are never used in practice by normal apps. scope id might be used once in a blue moon by something like a dhcp server (use link local addresses). this difference causes a large portion of work involved in porting python apps to suppot v6. i suggest it be changed to just an address-port tuple, or add some kind of hack to allow it ot be unpacked like "host, port = addr". -- erno kuusela ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-12-30 12:27 Message: Logged In: YES user_id=21627 Closing as not-a-bug. RFC 3493 still lists flowinfo as being present in an IPv6 address, so we should keep it. Removing it now would break compatibility, anyway. ---------------------------------------------------------------------- Comment By: cypherpunks (cypherpunks) Date: 2003-06-17 03:28 Message: Logged In: YES user_id=16535 (sorry, title should have sockaddr and not addrinfo.) It is a bug because it is gratuitous incompatibility between 6/4. "large portion" does not mean "huge absolute amount" - just that at least for server apps otherwise you'd only need to change a couple of lines and libraries expecting ipv4 sockets wouldn't know the difference. just grep 'host, port' from most networking programs. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-06-14 10:20 Message: Logged In: YES user_id=21627 Why is this a bug, and what kind of large portion of work is involved to support IPv6? Please have a look at httplib/ftplib, which both support IPv6, with minimum amount of work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=744164&group_id=5470 From noreply at sourceforge.net Tue Dec 30 06:28:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 30 06:28:45 2003 Subject: [ python-Bugs-761267 ] Failure in comparing unicode string Message-ID: Bugs item #761267, was opened at 2003-06-26 18:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761267&group_id=5470 Category: Unicode Group: Python 2.2.3 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Stephen Brown (skbrown1975) Assigned to: Nobody/Anonymous (nobody) Summary: Failure in comparing unicode string Initial Comment: Received a SystemError: C:\Code\22 \Objects\longobject.c:231: bad argument to internal function The code was "if items[0] == self.InfoShareName:" where items is an array of strings and self.InfoShareName is a unicode string declared by self.InfoShareName = unicode(ShareName) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-12-30 12:28 Message: Logged In: YES user_id=21627 Closing as not reproducable. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-06-28 16:01 Message: Logged In: YES user_id=38388 I can't see how your code could possibly cause the error you indicate. Please provide an executable example with real data. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-27 05:01 Message: Logged In: YES user_id=33168 Can you attach a file which demonstrates this bug. I cannot reproduce it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761267&group_id=5470 From noreply at sourceforge.net Tue Dec 30 10:16:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 30 10:16:33 2003 Subject: [ python-Bugs-852347 ] add support for cjkcodecs to Python email Message-ID: Bugs item #852347, was opened at 2003-12-01 17:05 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852347&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Barry A. Warsaw (bwarsaw) Summary: add support for cjkcodecs to Python email Initial Comment: As discussed last week on the email-sig list, the attached patch adds support for the CJKCodecs package as an alternative to the {Chinese,Japanese,Korean}Codecs packages. CJKCodecs 1.0.2 and above should work with this patch. This is advantageous because the Chinese and KoreanCodecs packages are no longer supported,maintained or available for download. This patch does not break compatibility with {Chinese,Japanese,Korean}Codecs, so they can still be used if desired. Lastly, this patch fixes a small typo that broke GB2312. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-30 10:16 Message: Logged In: YES user_id=12800 Latest version of the patch, with updated comments as per Jason's followup, and including Tokio Kikuchi's fix for the test suite regression. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2003-12-30 00:59 Message: Logged In: YES user_id=85984 comments regarding Barry's Charset.py.diff: You shouldn't mention KoreanCodecs and ChineseCodecs in the comments as alternatives to CJKCodecs. Both are no longer maintained, or even available for download. Both have been completely replaced by CJKCodecs. Only JapaneseCodecs remains as a substitute package. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-29 23:33 Message: Logged In: YES user_id=12800 I'm not even sure this patch is correct, since it breaks the test suite. The problem is that self.output_codec ends up being different with the patch than without it (in Charset.__init__()). For example: Python 2.3.3 (#1, Dec 19 2003, 11:33:00) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from email.Charset import Charset >>> c = Charset('euc-jp') >>> c.output_codec 'japanese.iso-2022-jp' >>> But now with Charset.py.diff applied: ... >>> c.output_codec 'euc-jp' We need to figure out what the right thing to do here is. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-29 10:19 Message: Logged In: YES user_id=12800 One more rev of Charset.py.diff ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-29 09:52 Message: Logged In: YES user_id=12800 Oops, with the typo fix for gb2312. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-29 09:49 Message: Logged In: YES user_id=12800 Correct me if I'm wrong, but won't the attached patch work better? It simply removes the entries from CODEC_MAP that are already provided by cjkcodecs.aliases (and japanese.aliases and korean.aliases). See Charset.py.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852347&group_id=5470 From noreply at sourceforge.net Tue Dec 30 11:52:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 30 11:53:05 2003 Subject: [ python-Bugs-852347 ] add support for cjkcodecs to Python email Message-ID: Bugs item #852347, was opened at 2003-12-01 17:05 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852347&group_id=5470 Category: Python Library Group: Feature Request Status: Open >Resolution: Accepted Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Barry A. Warsaw (bwarsaw) Summary: add support for cjkcodecs to Python email Initial Comment: As discussed last week on the email-sig list, the attached patch adds support for the CJKCodecs package as an alternative to the {Chinese,Japanese,Korean}Codecs packages. CJKCodecs 1.0.2 and above should work with this patch. This is advantageous because the Chinese and KoreanCodecs packages are no longer supported,maintained or available for download. This patch does not break compatibility with {Chinese,Japanese,Korean}Codecs, so they can still be used if desired. Lastly, this patch fixes a small typo that broke GB2312. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-30 11:52 Message: Logged In: YES user_id=12800 Applied to Python trunk (2.4). This will be applied to Python 2.3 and closed when that branch's freeze is lifted. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-30 10:16 Message: Logged In: YES user_id=12800 Latest version of the patch, with updated comments as per Jason's followup, and including Tokio Kikuchi's fix for the test suite regression. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2003-12-30 00:59 Message: Logged In: YES user_id=85984 comments regarding Barry's Charset.py.diff: You shouldn't mention KoreanCodecs and ChineseCodecs in the comments as alternatives to CJKCodecs. Both are no longer maintained, or even available for download. Both have been completely replaced by CJKCodecs. Only JapaneseCodecs remains as a substitute package. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-29 23:33 Message: Logged In: YES user_id=12800 I'm not even sure this patch is correct, since it breaks the test suite. The problem is that self.output_codec ends up being different with the patch than without it (in Charset.__init__()). For example: Python 2.3.3 (#1, Dec 19 2003, 11:33:00) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from email.Charset import Charset >>> c = Charset('euc-jp') >>> c.output_codec 'japanese.iso-2022-jp' >>> But now with Charset.py.diff applied: ... >>> c.output_codec 'euc-jp' We need to figure out what the right thing to do here is. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-29 10:19 Message: Logged In: YES user_id=12800 One more rev of Charset.py.diff ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-29 09:52 Message: Logged In: YES user_id=12800 Oops, with the typo fix for gb2312. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-29 09:49 Message: Logged In: YES user_id=12800 Correct me if I'm wrong, but won't the attached patch work better? It simply removes the entries from CODEC_MAP that are already provided by cjkcodecs.aliases (and japanese.aliases and korean.aliases). See Charset.py.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852347&group_id=5470 From noreply at sourceforge.net Wed Dec 31 10:37:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 31 10:37:10 2003 Subject: [ python-Bugs-786827 ] IDLE starts with no menus (Cygwin build of python2.3) Message-ID: Bugs item #786827, was opened at 2003-08-11 11:58 Message generated for change (Comment added) made by duanekaufman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786827&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Duane Kaufman (duanekaufman) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE starts with no menus (Cygwin build of python2.3) Initial Comment: When started from a Cygwin window (duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py) The IDLE window has no menus. If started as: duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py -n (no subprocess) the menus are present. Starting Python: duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ python Python 2.3 (#1, Aug 1 2003, 15:01:23) [GCC 3.2 20020927 (prerelease)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> Win2k SP2 Duane Kaufman duane.kaufman@med.ge.com ---------------------------------------------------------------------- >Comment By: Duane Kaufman (duanekaufman) Date: 2003-12-31 09:37 Message: Logged In: YES user_id=574999 Hi, I was wondering if there has been any motion on this item yet? Thanks, Duane ---------------------------------------------------------------------- Comment By: Duane Kaufman (duanekaufman) Date: 2003-08-14 11:53 Message: Logged In: YES user_id=574999 I am seeing the same behavior, and do _not_ see menus when started with a sub-process. Duane ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 11:47 Message: Logged In: YES user_id=86216 > It sounds like you are getting farther than Duane > Kaufman. I don't think so. AFAICT, we are observing the same behavior. > I wonder if he was seeing the initial message in the > shell window like you are. My WAG is yes. Duane, please confirm. > Do you see the menus? No. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 11:39 Message: Logged In: YES user_id=149084 Oh, big differences: Without the -n switch, which makes IDLE act like the 2.2 version, IDLE starts up an execution server subprocess which then connects to the user's GUI. This subprocess is restarted every time the user does a Run/F5 or a Shell/Restart Shell. There are other major differences. The IDLE in 2.3 is the version developed on the IDLEfork project at Sourceforge. It sounds like you are getting farther than Duane Kaufman. I wonder if he was seeing the initial message in the shell window like you are. Do you see the menus? Well, gotta go :-) ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 11:06 Message: Logged In: YES user_id=86216 > what bug are you thinking of? Nothing in particular. However, experience has taught me to consider Cygwin bugs when porting to Cygwin... Anyway, I just found a difference between Python 2.2.3 and 2.3 after starting IDLE. Under 2.2.3: $ ps | fgrep python 3308 1400 3308 3092 0 19695 11:57:56 /home/jt/src/python-2.2.3-2/python Under 2.3: $ ps | fgrep python 2244 1400 2244 2864 0 19695 12:02:57 /usr/bin/python2.3 700 2244 2244 3592 0 19695 12:02:58 /usr/bin/python2.3 Note one python process under 2.2.3 and two under 2.3. This may explain why IDLE works under 2.2.3 and not. Were there major IDLE changes between 2.2.3 and 2.3? If so, what? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 10:21 Message: Logged In: YES user_id=149084 Well, that's peculiar. So the subprocess is starting up ok but the menus aren't posted. Now I'm thinking a TK problem -- what bug are you thinking of? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 09:49 Message: Logged In: YES user_id=86216 kbk> There are no error messages in the kbk> shell window? No, the shell window just looks like the following: Python 2.3 (#1, Aug 5 2003, 09:49:11) [GCC 3.2 20020927 (prerelease)] on cygwin Type "copyright", "credits" or "license()" for more information. ********************************************** ****************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ********************************************** ****************** IDLE 1.0 >>> And appears to work, until one types "^D", then it hangs. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 09:20 Message: Logged In: YES user_id=149084 It appears that IDLE can't start its subprocess. I have a patch in process that will give proper error messages and timeouts under that condition, at least giving the user a notice about the failure. Then there is the question why the subprocess doesn't start under Cygwin. There are no error messages in the shell window? I'm going to be away for a few days myself. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 07:00 Message: Logged In: YES user_id=86216 I would like to assign this (at least temporarily) to Kurt for the following reasons: 1. I will be off-net for a while 2. I am not very familiar with Tkinter 3. I am not very familiar with IDLE 4. IDLE works fine under Python 2.2.3 with the identical underlying software (e.g, Cygwin, Tcl/Tk, etc.) However, IDLE under Python 2.3 could be tickling YA Cygwin bug... I will check in when I'm back... Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-13 17:38 Message: Logged In: YES user_id=33168 Jason, if you can't help can you assign to Kurt (kbk)? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786827&group_id=5470 From noreply at sourceforge.net Wed Dec 31 12:43:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 31 12:43:44 2003 Subject: [ python-Bugs-868529 ] Configure error with 2.3.3 on AIX 5.2 using gcc 3.3.2 Message-ID: Bugs item #868529, was opened at 2003-12-31 12:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868529&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard Wheeler (wheelrl) Assigned to: Nobody/Anonymous (nobody) Summary: Configure error with 2.3.3 on AIX 5.2 using gcc 3.3.2 Initial Comment: aixth4(cmadmin)# gcc -v -save-temps -o conftest -g - O2 conftest.c Reading specs from /cmDevTest/Dev/local/bin/../lib/gcc- lib/powerpc-ibm- aix5.1.0.0/3.3.2/specs Configured with: ../gcc-3.3.2/configure --disable-nls Thread model: aix gcc version 3.3.2 /cmDevTest/Dev/local/bin/../lib/gcc-lib/powerpc-ibm- aix5.1.0.0/3.3.2/cc1 -E - quiet -v -iprefix / cmDevTest/Dev/local/bin/../lib/gcc-lib/powerpc-ibm- aix5.1.0.0/3.3.2/ - D__GNUC__=3 -D__GNUC_MINOR_ _=3 -D__GNUC_PATCHLEVEL__=2 conftest.c -O2 conftest.i ignoring nonexistent directory "/cmDevTest/Dev/local/bin/../powerpc-ibm- aix5.1.0.0/include" ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "NONE/include" ignoring nonexistent directory "/usr/local/lib/gcc- lib/powerpc-ibm- aix5.1.0.0/3.3.2/include" ignoring nonexistent directory "/usr/local/powerpc-ibm- aix5.1.0.0/include" #include "..." search starts here: #include <...> search starts here: /cmDevTest/Dev/local/bin/../lib/gcc-lib/powerpc-ibm- aix5.1.0.0/3.3.2/include /usr/include End of search list. /cmDevTest/Dev/local/bin/../lib/gcc-lib/powerpc-ibm- aix5.1.0.0/3.3.2/cc1 - fpreprocessed conftest .i -quiet -dumpbase conftest.c -auxbase conftest -g - O2 -version -o conftest.s GNU C version 3.3.2 (powerpc-ibm-aix5.1.0.0) compiled by GNU C version 3.3.2. GGC heuristics: --param ggc-min-expand=32 --param ggc-min-heapsize=4096 In file included from conftest.c:23: /usr/include/pthread.h:554: error: parse error before '*' token /usr/include/pthread.h:557: error: parse error before '*' token /usr/include/pthread.h:561: error: parse error before '*' token /usr/include/pthread.h:564: error: parse error before '*' token /usr/include/pthread.h:567: error: parse error before '*' token /usr/include/pthread.h:570: error: parse error before '*' token /usr/include/pthread.h:573: error: parse error before '*' token /usr/include/pthread.h:576: error: parse error before '*' token /usr/include/pthread.h:579: error: parse error before '*' token /usr/include/pthread.h:583: error: parse error before '*' token ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868529&group_id=5470 From noreply at sourceforge.net Wed Dec 31 12:48:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 31 12:48:12 2003 Subject: [ python-Bugs-786827 ] IDLE starts with no menus (Cygwin build of python2.3) Message-ID: Bugs item #786827, was opened at 2003-08-11 08:58 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786827&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Duane Kaufman (duanekaufman) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE starts with no menus (Cygwin build of python2.3) Initial Comment: When started from a Cygwin window (duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py) The IDLE window has no menus. If started as: duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py -n (no subprocess) the menus are present. Starting Python: duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ python Python 2.3 (#1, Aug 1 2003, 15:01:23) [GCC 3.2 20020927 (prerelease)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> Win2k SP2 Duane Kaufman duane.kaufman@med.ge.com ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-12-31 08:48 Message: Logged In: YES user_id=86216 Unfortunately, not. The bug report was created right before I was going on vacation last summer. Since I'm still on vacation... :,) Well...actually the assumed high "head banger" factor has facilitated my procrastination. Additionally, since I do not use use IDLE, I'm not very motivated to build a debuggable Python and Cygwin and attach to the hung process with gdb and debug. FWIW, I haven't forgetton. The bug report stares me in the face everytime I read my email. Unfortunately, I haven't taken any action. :,( Are you a developer type? If so, would you be willing to try to debug this problem yourself? ---------------------------------------------------------------------- Comment By: Duane Kaufman (duanekaufman) Date: 2003-12-31 06:37 Message: Logged In: YES user_id=574999 Hi, I was wondering if there has been any motion on this item yet? Thanks, Duane ---------------------------------------------------------------------- Comment By: Duane Kaufman (duanekaufman) Date: 2003-08-14 08:53 Message: Logged In: YES user_id=574999 I am seeing the same behavior, and do _not_ see menus when started with a sub-process. Duane ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 08:47 Message: Logged In: YES user_id=86216 > It sounds like you are getting farther than Duane > Kaufman. I don't think so. AFAICT, we are observing the same behavior. > I wonder if he was seeing the initial message in the > shell window like you are. My WAG is yes. Duane, please confirm. > Do you see the menus? No. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 08:39 Message: Logged In: YES user_id=149084 Oh, big differences: Without the -n switch, which makes IDLE act like the 2.2 version, IDLE starts up an execution server subprocess which then connects to the user's GUI. This subprocess is restarted every time the user does a Run/F5 or a Shell/Restart Shell. There are other major differences. The IDLE in 2.3 is the version developed on the IDLEfork project at Sourceforge. It sounds like you are getting farther than Duane Kaufman. I wonder if he was seeing the initial message in the shell window like you are. Do you see the menus? Well, gotta go :-) ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 08:06 Message: Logged In: YES user_id=86216 > what bug are you thinking of? Nothing in particular. However, experience has taught me to consider Cygwin bugs when porting to Cygwin... Anyway, I just found a difference between Python 2.2.3 and 2.3 after starting IDLE. Under 2.2.3: $ ps | fgrep python 3308 1400 3308 3092 0 19695 11:57:56 /home/jt/src/python-2.2.3-2/python Under 2.3: $ ps | fgrep python 2244 1400 2244 2864 0 19695 12:02:57 /usr/bin/python2.3 700 2244 2244 3592 0 19695 12:02:58 /usr/bin/python2.3 Note one python process under 2.2.3 and two under 2.3. This may explain why IDLE works under 2.2.3 and not. Were there major IDLE changes between 2.2.3 and 2.3? If so, what? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 07:21 Message: Logged In: YES user_id=149084 Well, that's peculiar. So the subprocess is starting up ok but the menus aren't posted. Now I'm thinking a TK problem -- what bug are you thinking of? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 06:49 Message: Logged In: YES user_id=86216 kbk> There are no error messages in the kbk> shell window? No, the shell window just looks like the following: Python 2.3 (#1, Aug 5 2003, 09:49:11) [GCC 3.2 20020927 (prerelease)] on cygwin Type "copyright", "credits" or "license()" for more information. ********************************************** ****************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ********************************************** ****************** IDLE 1.0 >>> And appears to work, until one types "^D", then it hangs. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 06:20 Message: Logged In: YES user_id=149084 It appears that IDLE can't start its subprocess. I have a patch in process that will give proper error messages and timeouts under that condition, at least giving the user a notice about the failure. Then there is the question why the subprocess doesn't start under Cygwin. There are no error messages in the shell window? I'm going to be away for a few days myself. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 04:00 Message: Logged In: YES user_id=86216 I would like to assign this (at least temporarily) to Kurt for the following reasons: 1. I will be off-net for a while 2. I am not very familiar with Tkinter 3. I am not very familiar with IDLE 4. IDLE works fine under Python 2.2.3 with the identical underlying software (e.g, Cygwin, Tcl/Tk, etc.) However, IDLE under Python 2.3 could be tickling YA Cygwin bug... I will check in when I'm back... Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-13 14:38 Message: Logged In: YES user_id=33168 Jason, if you can't help can you assign to Kurt (kbk)? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786827&group_id=5470 From noreply at sourceforge.net Wed Dec 31 13:23:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 31 13:23:35 2003 Subject: [ python-Bugs-853061 ] bz2:compress empty string inconsistent Message-ID: Bugs item #853061, was opened at 2003-12-02 22:43 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853061&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) >Assigned to: Gustavo Niemeyer (niemeyer) Summary: bz2:compress empty string inconsistent Initial Comment: There are three ways to compress data in bz2 but they don't handle an empty string same way. BZ2File and compress can accept an empty string but BZ2Compressor raises ValueError. >>> import bz2 >>> bz2f = bz2.BZ2File('test', 'w') >>> bz2f.write('') >>> bz2f.close() >>> bz2.compress('') 'BZh9\x17rE8P\x90\x00\x00\x00\x00' >>> bz2c = bz2.BZ2Compressor() >>> bz2c.compress('') Traceback (most recent call last): File "", line 1, in ? ValueError: the bz2 library has received wrong parameters ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853061&group_id=5470 From noreply at sourceforge.net Wed Dec 31 14:18:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 31 14:18:23 2003 Subject: [ python-Bugs-868571 ] HTTPResponse.read(amt) fails when response length is UNKNOWN Message-ID: Bugs item #868571, was opened at 2003-12-31 11:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868571&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Grant Monroe (gmonroe) Assigned to: Nobody/Anonymous (nobody) Summary: HTTPResponse.read(amt) fails when response length is UNKNOWN Initial Comment: If the length of the reponse from an HTTPConnection is unknown, then a read with a specified amount fails. File "/home/grant/local/lib/python2.3/httplib.py", line 404, in read self.length -= amt TypeError: unsupported operand type(s) for -=: 'str' and 'int' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868571&group_id=5470 From noreply at sourceforge.net Wed Dec 31 22:41:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 31 22:41:18 2003 Subject: [ python-Bugs-868706 ] Calling builtin function 'eval' from C causes seg fault. Message-ID: Bugs item #868706, was opened at 2004-01-01 14:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868706&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zac Evans (karadoc) Assigned to: Nobody/Anonymous (nobody) Summary: Calling builtin function 'eval' from C causes seg fault. Initial Comment: Using C to get the eval function from builtins then call it causes a Seg-Fault. I've tried calling it using PyObject_CallObject, "_CallFunction, "_CallFunctionObjArg s. All cause the same problem. Other builtin functions seem to work correctly. and eval seems to work correctly from python (obviously). It's just calling eval from C which causes the crash. Attached is some sample code which demonstrates the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868706&group_id=5470 From noreply at sourceforge.net Wed Dec 31 22:42:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 31 22:42:19 2003 Subject: [ python-Bugs-825810 ] reference to Built-In Types section in file() documentation Message-ID: Bugs item #825810, was opened at 2003-10-17 20:22 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=825810&group_id=5470 Category: Documentation Group: Python 2.2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: ewan (gorku) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: reference to Built-In Types section in file() documentation Initial Comment: The file() documentation in section 2.1 says: Return a new file object (described earlier under Built-in Types) but Built-in Types is the _next_ section; this should probably also be a link ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-12-31 22:42 Message: Logged In: YES user_id=3066 These sections used to be in a different order, so at least the text you cite used to be right. Clearly wrong now. Fixed in CVS: Doc/lib/libfuncs.tex revisions 1.161, 1.143.8.10 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=825810&group_id=5470