From noreply@sourceforge.net Thu Feb 1 16:44:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Feb 2001 08:44:19 -0800 Subject: [Patches] [Patch #103547] Fix mpz.binary method to handle 64-bit systems Message-ID: Patch #103547 has been updated. Project: python Category: Modules Status: Open Submitted by: rfish Assigned to : nobody Summary: Fix mpz.binary method to handle 64-bit systems ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103547&group_id=5470 From noreply@sourceforge.net Thu Feb 1 14:47:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Feb 2001 06:47:58 -0800 Subject: [Patches] [Patch #103495] case sensitive import for case insensitive FileSystem Message-ID: Patch #103495 has been updated. Project: python Category: core (C code) Status: Open Submitted by: sdm7g Assigned to : gvanrossum Summary: case sensitive import for case insensitive FileSystem Follow-Ups: Date: 2001-Feb-01 06:47 By: jlt63 Comment: Scratch the comment about the bug -- I've too much C++ on the head to think in straight C anymore. ------------------------------------------------------- Date: 2001-Jan-31 18:20 By: jlt63 Comment: Guido, Do you find the style of this patch more acceptable than mine (103154)? If so, would you consider including a cleaned up version into 2.1a2? Note that I have found one bug (MatchFilename() does not handle a NULL pathname correctly) and the code should probably be enabled on something more specific than HAVE_DIRENT_H (e.g., platform #defs, UNIX_STYLE_CHECK_IMPORT_CASE, etc). ------------------------------------------------------- Date: 2001-Jan-29 20:30 By: sdm7g Comment: Oops! The previous patch crashes if the path is empty, which is the case for the current directory. Added a line to check for that and use "." instead on diropen. -- Steve M. ------------------------------------------------------- Date: 2001-Jan-29 20:27 By: sdm7g Comment: Oops! The previous patch crashes if the path is empty, which is the case for the current directory. Added a line to check for that and use "." instead on diropen. -- Steve M. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103495&group_id=5470 From noreply@sourceforge.net Thu Feb 1 13:02:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Feb 2001 05:02:29 -0800 Subject: [Patches] [Patch #103544] Minor cleanup and support for NIS and bsddb on BSD systems Message-ID: Patch #103544 has been updated. Project: python Category: Build Status: Open Submitted by: nobody Assigned to : nobody Summary: Minor cleanup and support for NIS and bsddb on BSD systems ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103544&group_id=5470 From noreply@sourceforge.net Thu Feb 1 12:59:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Feb 2001 04:59:46 -0800 Subject: [Patches] [Patch #103543] `result' undeclared in Objects/floatobject.c Message-ID: Patch #103543 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nobody Assigned to : nobody Summary: `result' undeclared in Objects/floatobject.c ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103543&group_id=5470 From noreply@sourceforge.net Thu Feb 1 05:30:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 21:30:00 -0800 Subject: [Patches] [Patch #103203] PEP 205: weak references implementation Message-ID: Patch #103203 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: fdrake Assigned to : fdrake Summary: PEP 205: weak references implementation Follow-Ups: Date: 2001-Jan-31 21:30 By: fdrake Comment: Checked in at Tim's urging. If this isn't quite right, file a bug report. ------------------------------------------------------- Date: 2001-Jan-31 13:01 By: fdrake Comment: - The .islive() method has been removed. - .get() has been replaced with calling the reference. - Reference and proxy objects which have no callbacks are "shared"; new objects are not created for every requestor in this case. - The new() function has been renamed ref(), since there's no requirement that it return a new reference or proxy object. - Callback functions no longer receive the objects that are about to be finalized; the weak reference object or proxy that fired the callback is passed instead. Proxy objects still need support for rich comparisons. (PEP 205 has also been updated.) ------------------------------------------------------- Date: 2001-Jan-30 07:34 By: gvanrossum Comment: Grabbing this for code review (finally!) ------------------------------------------------------- Date: 2001-Jan-22 14:01 By: fdrake Comment: Removed the .clear() method from reference objects. Made proxy objects unhashable -- the semantics of hashing something that can mutate in fundamental ways is pretty painful; just don't use these as dictionary keys! Added strong warnings to the documentation that proxy semantics may change a bit before the final release that the weak dictionaries are unclear -- additional feedback is requested. These are not thread-safe. ------------------------------------------------------- Date: 2001-Jan-20 09:42 By: gvanrossum Comment: I think callbacks are needed to implement various forms of weak dicts: when the object is deleted, whatever's in the weak dict for it should be deleted as well. Even though we may not provide weak dicts in 2.1a1, we should still support writing them using what we *do* provide. IMHO (I still haven't had the time to read the PEP or Fred's code. :-( ) ------------------------------------------------------- Date: 2001-Jan-20 09:12 By: nascheme Comment: Why do weak references need callbacks? I see nothing in the PEP to justify this feature. If there is no good reason for them, I propose that the feature be removed for 2.1. Allowing callbacks may make it harder to implement weak references more efficiently later. ------------------------------------------------------- Date: 2001-Jan-18 16:03 By: loewis Comment: The patch looks ok in general, pending resolution of the issues on the PEP itself. Some nits: Integration with GC is still fuzzy. If an instance is GC collected and had a weak ref to it and the weak ref had a callback and the callback choses to resurrect the object, semantics is unclear. This is equivalent to the object having an __del__; the GC would normally *not* collect such objects, but put them into gc.garbage. Proposed resolution: it is a fatal error to resurrect an object in a weakref callback. Hashing: it appears that the hash of a weakref can change when the underlying object goes away. If the weakref is used as key in a dictionary, it appears to be impossible to get the key out of the dictionary after the underlying object is gone. Proposed resolution: a proxy weak ref should cache the hash of the underlying object after its hash function was called for the first time. Comparing: why is the return value of tp_compare -1 when try_3way_compare expects -2 on error? Shouldn't there be some exception set when the underlying object goes away? ------------------------------------------------------- Date: 2001-Jan-17 13:53 By: fdrake Comment: Ok, I tihnk this is it! http://starship.python.net/crew/fdrake/patches/weakref.patch-5 This patch fixes the compilation problems from the previoous patch related to the introduction of rich comparisons, and makes a change in the way new objects are initialized by PyObject_New() and PyObject_NEW() (and all their friends!) -- those functions now know to initialize the weak reference list to NULL for objects which support weak references. Without this change, more places in the code (especially extension modules) need to know more about initialization of weakly-referencable objects. For instance, the "cPickle" and "new" modules both can create instances without calling the code in classobject.c (using PyObject_New()), causing core dumps when such instances are deallocated if the weak-reference list for instances was not properly initialized. Since these modules (properly) tried to avoid call PyInstance_New(), core dumps ensued and the world fell apart. By moving the initialization of the weak reference list into the core object allocators, this problem is averted and extension code to construct new weakly referencable types is simplified. The documentation still needs work, and there are a few new entries for the Python/C API manual as well. A new constructor for instances, PyInstance_NewRaw(), will be added in a separate patch. ------------------------------------------------------- Date: 2001-Jan-17 11:58 By: nascheme Comment: The magic test is: ./python Lib/test/regrtest.py test_weakref test_new Try adding this patch: --- Modules/newmodule.c 2000/11/13 20:29:20 2.29 +++ Modules/newmodule.c 2001/01/17 19:55:46 @@ -24,6 +24,7 @@ Py_INCREF(dict); inst->in_class = (PyClassObject *)klass; inst->in_dict = dict; + inst->in_weakreflist = NULL; PyObject_GC_Init(inst); return (PyObject *)inst; } ------------------------------------------------------- Date: 2001-Jan-17 08:04 By: fdrake Comment: New version of the patch that's still broken but doesn't conflict with the rich comparisons changes: http://starship.python.net/crew/fdrake/patches/weakref.patch-4 ------------------------------------------------------- Date: 2001-Jan-16 21:35 By: fdrake Comment: Added a new (but broken!) version of the patch that fixes WeakDictionary.get() but doesn't interact properly with GC (appearantly) -- not usable as is: http://starship.python.net/crew/fdrake/patches/weakref.patch-3 Neil made the mistake of volunteering to look at the current problem, so assigning to him. (Thanks!) ------------------------------------------------------- Date: 2001-Jan-16 19:39 By: tim_one Comment: Just mentioning a general scenario in which weak keys are the bee's knees: sometimes you want to add attributes to objects dynamically, in ways the original class author(s -- may cut across many classes! even non-instance objects; or objects from extension modules that don't support setattr) never anticipated. Like maybe a German translation of the object's docstrings; or a list of JPEG contents referenced by a URLish object; or a table of usage statistics on methods and functions; etc. Then it's natural to use the conceptual attr name as the name of a dict instead, and write attr[object] = whatever instead of object.attr = whatever There's no point keeping the "whatever" around when the object goes away, but a regular dict makes the object and its "whatever" immortal. A dict with weak keys is exactly on-target. ------------------------------------------------------- Date: 2001-Jan-16 19:14 By: fdrake Comment: I'm not entirely sure why one would want weak keys rather than weak values, but I suspect it has to do with expectations of how the dict will be used in applications. I don't think it would be hard to support both flavors of dictionaries using the primitive reference objects. The constructor does not check that all incoming values are weak because that isn't required. It uses self.update() rather than self.data.update() to perform the inclusion, so any mapping that supports .keys() and .__getitem__() is sufficient. Some additional checking could be done to make sure that all added entries can be created before inserting any of them, offering more atomicity. .get() will be fixed in the next version of the patch; thanks! I've added GC support, but don't have it working quite right. I'm trying to isolate the failure now. ------------------------------------------------------- Date: 2001-Jan-12 14:36 By: loewis Comment: The weak dictionary data type needs more clarification in documentation and implementation. In java.util.WeakHashMap, they keys are weak, not the values (i.e. once the key is forgotten, the entry is cleared). In http://www.handshake.de/~dieter/weakdict.html, the values are weak, but it raises KeyErrors for entries that are collected. The initializer of a weak dict does not check the invariant (all values are weak). get() of a weakdict does not support an optional second parameter. weakref and friends need to participate in garbage collection, as the reference to the callback can create a cycle. ------------------------------------------------------- Date: 2001-Jan-12 11:27 By: fdrake Comment: Updated patch to also support proxy semantics using the same invalidation machinery as the basic weak reference type. The additional code is *heavily* borrowed from Neil Schemenauer. ------------------------------------------------------- Date: 2001-Jan-12 01:00 By: nobody Comment: Neil, you may want to have a look at mxProxy. This is a proxy implementation which already provides weak references (among other things) and has the advantages you talked about in your reply. -- Marc-Andre ------------------------------------------------------- Date: 2001-Jan-11 15:27 By: nascheme Comment: Hmm, I think this can be done more cleanly with a proxy now the the coercion stuff has been cleaned up. I will probably give it a go tonight. The advantage of using a proxy is that you can have a weak reference to any object and you only pay memory for weak references if you use them. ------------------------------------------------------- Date: 2001-Jan-11 14:05 By: fdrake Comment: Assigned to Martin, since he's indicated he intends to go over this very carefully! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470 From noreply@sourceforge.net Thu Feb 1 02:20:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 18:20:37 -0800 Subject: [Patches] [Patch #103495] case sensitive import for case insensitive FileSystem Message-ID: Patch #103495 has been updated. Project: python Category: core (C code) Status: Open Submitted by: sdm7g Assigned to : gvanrossum Summary: case sensitive import for case insensitive FileSystem Follow-Ups: Date: 2001-Jan-31 18:20 By: jlt63 Comment: Guido, Do you find the style of this patch more acceptable than mine (103154)? If so, would you consider including a cleaned up version into 2.1a2? Note that I have found one bug (MatchFilename() does not handle a NULL pathname correctly) and the code should probably be enabled on something more specific than HAVE_DIRENT_H (e.g., platform #defs, UNIX_STYLE_CHECK_IMPORT_CASE, etc). ------------------------------------------------------- Date: 2001-Jan-29 20:30 By: sdm7g Comment: Oops! The previous patch crashes if the path is empty, which is the case for the current directory. Added a line to check for that and use "." instead on diropen. -- Steve M. ------------------------------------------------------- Date: 2001-Jan-29 20:27 By: sdm7g Comment: Oops! The previous patch crashes if the path is empty, which is the case for the current directory. Added a line to check for that and use "." instead on diropen. -- Steve M. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103495&group_id=5470 From noreply@sourceforge.net Thu Feb 1 01:30:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jan 2001 17:30:34 -0800 Subject: [Patches] [Patch #103512] symtable['.noopt'] = None, should be = 0 Message-ID: Patch #103512 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: donnc Assigned to : jhylton Summary: symtable['.noopt'] = None, should be = 0 Follow-Ups: Date: 2001-Jan-31 17:30 By: jhylton Comment: will checkin a similar fix ------------------------------------------------------- Date: 2001-Jan-30 18:45 By: tim_one Comment: Assigned to Jeremy; sounds right to me! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103512&group_id=5470 From noreply@sourceforge.net Thu Feb 1 16:01:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Feb 2001 08:01:47 -0800 Subject: [Patches] [Patch #102684] ceval/getargs: better messages for argument handling Message-ID: Patch #102684 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: ping Assigned to : jhylton Summary: ceval/getargs: better messages for argument handling Follow-Ups: Date: 2001-Feb-01 08:01 By: jhylton Comment: already applied ------------------------------------------------------- Date: 2000-Dec-06 04:56 By: ping Comment: This is an attempt to unify and improve the various kinds of TypeError messages that are produced by the wrong type or number of arguments. The function name is now provided whenever possible, and presented first in the resulting error message. (Previously it was not shown in certain cases.) The messages for wrong number of arguments to built-ins and user-defined functions used to be different, and this patch makes them consistent. Also this attempts to clarify the wording of some of the less-than-obvious messages about keyword arguments. Lots of test cases and output are included. ------------------------------------------------------- Date: 2000-Dec-06 09:57 By: gvanrossum Comment: No time to evaluate all of this, but I agree with the goal. Reviewers, please! (Temporarily assigned to Jeremy because he's the function call expert. :-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102684&group_id=5470 From noreply@sourceforge.net Thu Feb 1 18:14:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Feb 2001 10:14:36 -0800 Subject: [Patches] [Patch #102227] make BUILD_MAP use it's argument Message-ID: Patch #102227 has been updated. Project: python Category: core (C code) Status: Rejected Submitted by: mwh Assigned to : jhylton Summary: make BUILD_MAP use it's argument Follow-Ups: Date: 2001-Feb-01 10:14 By: jhylton Comment: While this change make the generated code a lot simpler, it also has a high cost in speed and memory. The stack for a code object needs to be big enough to hold all the keys and values, which can be costly. The pybench dict creation benchmark slows down about 15%. ------------------------------------------------------- Date: 2000-Nov-02 09:00 By: mwh Comment: This patch makes BUILD_MAP more like BUILD_LIST, and uses these newfound abilities to compile literal dictionaries into code more like that for lists and tuples. No reason, really, beyong asthetics & the fact that this'll make some hacks I want to inflict on the function call mechanism easier... ------------------------------------------------------- Date: 2000-Nov-13 11:40 By: gvanrossum Comment: I'll give this to Jeremy for consideration, since he's working on a restructuring of the function call code anyway. I'll note thta this is really low priority. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102227&group_id=5470 From noreply@sourceforge.net Fri Feb 2 03:23:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Feb 2001 19:23:41 -0800 Subject: [Patches] [Patch #101137] Add raw packet support to socketmodule.c Message-ID: Patch #101137 has been updated. Project: python Category: Modules Status: Accepted Submitted by: grante Assigned to : jhylton Summary: Add raw packet support to socketmodule.c Follow-Ups: Date: 2001-Feb-01 19:23 By: jhylton Comment: checked in as rev 1.134 Grant-- Could you supply a short example that demonstrates how to use raw sockets? We can't really include the code in the test suite, since you need to be root to use them, but perhaps in the Demo directory. ------------------------------------------------------- Date: 2001-Jan-27 17:02 By: grante Comment: Revised patch: 1) fixed indentation style. 2) fixed possible strncpy buffer overrun. 3) fixed bug in getsockname. 4) exposed sll_pkttype and sll_hatype fields of sockaddr_ll struct (AFAICT, they're not useful). 5) changed conditional compilation so AF_PACKET stuff is only built under Linux. (patch is against 2.0) ------------------------------------------------------- Date: 2001-Jan-18 10:01 By: nobody Comment: Yes, I'm still interested in this patch. Winthin the next week or two I'll try to get a revised patch submitted that addresses some of the comments. Two things I can't do much about are: 1) I only have Linux systems for testing: I don't have root privledges on any other type of system. 2) Unless it is agreed to change parameters for makesockaddr, I can't do anything except create a temporary socket in order to look up the interface name. I suppose I could require user code to provide an interface index, but I don't really like that option since it diverges quite a bit from the "C" usage. ------------------------------------------------------- Date: 2001-Jan-18 09:39 By: jhylton Comment: Is Grant still interested in this patch? I don't have time to fix it myself, but I would be happy to look at it again if we comments and questions are addressed. ------------------------------------------------------- Date: 2000-Aug-09 14:49 By: grante Comment: Patch has only been tested on Linux: RH6.2 (Intel). Patch is against 1.6b1 ------------------------------------------------------- Date: 2000-Aug-15 15:15 By: tim_one Comment: Assigned to Barry, since he just volunteered to rewrite all of Python's socket code anyway . ------------------------------------------------------- Date: 2000-Aug-24 14:27 By: jhylton Comment: Not sure about this patch. It needs to be tested on more platforms than just Linux, but I don't see that we'll have time before 2.0. There are several other issues that must be resolved, too. Thus, this patch falls subject to the feature freeze. Style points: Indention is wrong. The opening curly brace of an if belongs on the same line as the test. Whitespace is required around = and after commas in argument lists. The strncpy in makesockaddr does not check the size of the source string. It could overflow the buffer. In makesockaddr, a new socket is created just to look up the interface name associated with a particular interface. This seems wasteful, particularly in cases where few file descriptors are available. I'm not sure what the solution is, although it might be to change the makesockaddr function so that it takes the socket itself. Perhaps that socket address for AF_PACKET should also accept and/or produce interface numbers which the client can convert to names manually. The sockaddr_ll has members ssl_hatype and ssl_pkttype, which are not made accessible by this patch. It seems like they should be, but I am not sure. Can you use SOCK_DGRAM without specifying the packet type? getsockaddrarg is handled, but getsockaddrlen is not. Question: Are there any other constants that should be added? This relates to the packet type question. * ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101137&group_id=5470 From noreply@sourceforge.net Thu Feb 1 22:41:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Feb 2001 14:41:37 -0800 Subject: [Patches] [Patch #103048] Generate simple JUMP_FORWARD for 'break' outside 'try' Message-ID: Patch #103048 has been updated. Project: python Category: core (C code) Status: Postponed Submitted by: twouters Assigned to : jhylton Summary: Generate simple JUMP_FORWARD for 'break' outside 'try' Follow-Ups: Date: 2001-Feb-01 14:41 By: jhylton Comment: At Thomas's suggestion ------------------------------------------------------- Date: 2001-Jan-18 08:37 By: twouters Comment: I'm going to suggest postponing this patch until 2.2, unless someone comes up and disagrees :) This is not a terribly useful feature, it's not visible from the 'outside' to start with, and the benifits are unclear. I'm also not sure if it works properly yet. I mostly submitted this patch to get rid of the 'TODO' entry at the top of compile.c. ------------------------------------------------------- Date: 2000-Dec-29 15:28 By: twouters Comment: Assigned to Jeremy because he's also got the 'continue inside try' patch, and it's vaguely similar. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103048&group_id=5470 From noreply@sourceforge.net Thu Feb 1 22:42:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Feb 2001 14:42:25 -0800 Subject: [Patches] [Patch #102989] Allow 'continue' inside 'try' clause Message-ID: Patch #102989 has been updated. Project: python Category: core (C code) Status: Accepted Submitted by: twouters Assigned to : jhylton Summary: Allow 'continue' inside 'try' clause Follow-Ups: Date: 2001-Feb-01 14:42 By: jhylton Comment: Except for the /* Uglee hack */ comment this looks good; a comment explaining the hack would be helpful. I'll try adding one when I commit. ------------------------------------------------------- Date: 2001-Jan-18 09:32 By: jhylton Comment: I will take a look at this patch before 2.1a1. I am trying to finish up some fairly major compiler changes, so it seems natural to review this patch next. ------------------------------------------------------- Date: 2001-Jan-18 08:35 By: twouters Comment: It seems Jeremy doesn't have time to review it right now, either. Which is not suprising, looking at the number of tasks assigned to him ;) Maybe someone else can take a look at this ? It shouldn't be that hard, the patch isn't *that* controversial, and it would be nice to have this in alpha1, I do think. The patch still applies fine, though it gives some harmless offset/fuzz warnings. Also, you need either to bump the bytecode magic or remove all .pyc files for it to actually matter (or run 'make distclean'.) ------------------------------------------------------- Date: 2000-Dec-28 07:09 By: gvanrossum Comment: I don't have time to review this myself for now, so I've assigned it to Jeremy, who is pretty familiar with the compiler and virtual machine. I do appreciate the effort very much! If it works, it should go in. (What's the JPython situation?) ------------------------------------------------------- Date: 2000-Dec-27 16:01 By: twouters Comment: Okay, really a new version now. (Forgot to click on 'Upload revised patch' last time.) Added documentation changes; the implementation-limitation of 'continue' inside 'try' was less extensively documented than I feared, and actually pretty incomplete. TeX code is untested, as I don't have network connectivity on my laptop right now, and that's the only place I got Fred's shakey LaTeX setup to work ;) ------------------------------------------------------- Date: 2000-Dec-27 15:46 By: twouters Comment: New version, 'final' as far as I'm concerned, unless the Power that Is prefers a 'PyFrame_GetCurrentBlock()' function over the ugly 'pop-and-push' hack that the current patch uses. Finally figured out why 'try: pass; finally: continue' wasn't raising the proper error: it never did ! It's just a bug in the current implementation, not this patch :) Updated test suites, including a test for the newly functional syntax (in test_grammar.) Not yet updated docs, those will follow. (Found another bug in the docs: it says you can do 'continue' inside 'finally', but you never could.) ------------------------------------------------------- Date: 2000-Dec-21 14:01 By: twouters Comment: Slightly better version, that actually compiles ;P Not done yet, though, the error for 'continue' inside 'finally' is still off. ------------------------------------------------------- Date: 2000-Dec-21 13:23 By: twouters Comment: This patch allows the use of 'continue' inside the 'try' part of try/except and try/finally. Allowing it inside the 'finally' clause requires more tricky juggling, however. (Suggestions welcome, of course :) The patch adds a new opcode, but does not update the bytecode magic. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102989&group_id=5470 From noreply@sourceforge.net Thu Feb 1 22:50:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Feb 2001 14:50:07 -0800 Subject: [Patches] [Patch #102989] Allow 'continue' inside 'try' clause Message-ID: Patch #102989 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: twouters Assigned to : jhylton Summary: Allow 'continue' inside 'try' clause Follow-Ups: Date: 2001-Feb-01 14:50 By: jhylton Comment: Checked in; ceval.c rev 2.226, compile.c rev 2.155, + others ------------------------------------------------------- Date: 2001-Feb-01 14:42 By: jhylton Comment: Except for the /* Uglee hack */ comment this looks good; a comment explaining the hack would be helpful. I'll try adding one when I commit. ------------------------------------------------------- Date: 2001-Jan-18 09:32 By: jhylton Comment: I will take a look at this patch before 2.1a1. I am trying to finish up some fairly major compiler changes, so it seems natural to review this patch next. ------------------------------------------------------- Date: 2001-Jan-18 08:35 By: twouters Comment: It seems Jeremy doesn't have time to review it right now, either. Which is not suprising, looking at the number of tasks assigned to him ;) Maybe someone else can take a look at this ? It shouldn't be that hard, the patch isn't *that* controversial, and it would be nice to have this in alpha1, I do think. The patch still applies fine, though it gives some harmless offset/fuzz warnings. Also, you need either to bump the bytecode magic or remove all .pyc files for it to actually matter (or run 'make distclean'.) ------------------------------------------------------- Date: 2000-Dec-28 07:09 By: gvanrossum Comment: I don't have time to review this myself for now, so I've assigned it to Jeremy, who is pretty familiar with the compiler and virtual machine. I do appreciate the effort very much! If it works, it should go in. (What's the JPython situation?) ------------------------------------------------------- Date: 2000-Dec-27 16:01 By: twouters Comment: Okay, really a new version now. (Forgot to click on 'Upload revised patch' last time.) Added documentation changes; the implementation-limitation of 'continue' inside 'try' was less extensively documented than I feared, and actually pretty incomplete. TeX code is untested, as I don't have network connectivity on my laptop right now, and that's the only place I got Fred's shakey LaTeX setup to work ;) ------------------------------------------------------- Date: 2000-Dec-27 15:46 By: twouters Comment: New version, 'final' as far as I'm concerned, unless the Power that Is prefers a 'PyFrame_GetCurrentBlock()' function over the ugly 'pop-and-push' hack that the current patch uses. Finally figured out why 'try: pass; finally: continue' wasn't raising the proper error: it never did ! It's just a bug in the current implementation, not this patch :) Updated test suites, including a test for the newly functional syntax (in test_grammar.) Not yet updated docs, those will follow. (Found another bug in the docs: it says you can do 'continue' inside 'finally', but you never could.) ------------------------------------------------------- Date: 2000-Dec-21 14:01 By: twouters Comment: Slightly better version, that actually compiles ;P Not done yet, though, the error for 'continue' inside 'finally' is still off. ------------------------------------------------------- Date: 2000-Dec-21 13:23 By: twouters Comment: This patch allows the use of 'continue' inside the 'try' part of try/except and try/finally. Allowing it inside the 'finally' clause requires more tricky juggling, however. (Suggestions welcome, of course :) The patch adds a new opcode, but does not update the bytecode magic. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102989&group_id=5470 From noreply@sourceforge.net Thu Feb 1 22:50:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Feb 2001 14:50:44 -0800 Subject: [Patches] [Patch #102864] prototype closure implementation (PEP 227) Message-ID: Patch #102864 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jhylton Assigned to : jhylton Summary: prototype closure implementation (PEP 227) Follow-Ups: Date: 2001-Feb-01 14:50 By: jhylton Comment: PEP 227 was done a while ago; forgot about this patch. ------------------------------------------------------- Date: 2000-Dec-18 14:18 By: gvanrossum Comment: Back to Jeremy. We had a code review session today. ------------------------------------------------------- Date: 2000-Dec-15 15:29 By: jhylton Comment: Guido, Here's a very rough implementation of closures. It uses flat closures that do not track rebindings of names in its original namespace. This is discussed briefly in the PEP; it should be straightforward to add a level of indirection to fix this. I rushed to get something implemented today; it's not the cleanest code. The changes to compile.c are particularly hackish, because the new function find_names() does a lot of work that can simplify code generation for LOAD_NAME, etc. and probably eliminate the need for a separate optimize() pass. I haven't made any attempt to integrate the closure creation cleanly, though; it's just wedged in there. The patch deals with functions only. Ultimately, classes will have to grow closures, too. The simple examples using classes should work, e.g. def make_adder(x): def adder(y): return x + y return adder dec = make_adder(-1) dec(1) == 0 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102864&group_id=5470 From noreply@sourceforge.net Thu Feb 1 23:36:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Feb 2001 15:36:54 -0800 Subject: [Patches] [Patch #101162] a Python/C API testing framework (simple simple) Message-ID: Patch #101162 has been updated. Project: python Category: Build Status: Open Submitted by: tmick Assigned to : tim_one Summary: a Python/C API testing framework (simple simple) Follow-Ups: Date: 2001-Feb-01 15:36 By: jhylton Comment: Will it be possible to include this in 2.1a2? ------------------------------------------------------- Date: 2001-Jan-29 12:51 By: akuchling Comment: Assuming that the _test module doesn't need anything special to compile (and why should it?), the change to setup.py is simple, adding the following line: exts.append( Extension('_test', ['_testmodule.c']) ) ------------------------------------------------------- Date: 2001-Jan-25 05:37 By: nobody Comment: This patch needs to be modified to use setup.py rather then Makefile.pre.in ------------------------------------------------------- Date: 2000-Aug-11 13:37 By: tmick Comment: Here is a proposed patch for a Python/C API testing framework. Simple simple. Basic Overview: - add a _test C extension module that exports test functions beginning with 'test_'; NULL and a TestError exception indicates a test failure and Py_None indicate a test pass - add a test_capi.py test module that calls each of the 'test_' exported functions in the '_test' module - changes to the build system files for Win32 and Unix are includes to build _testmodule.c as a shared extension - new files: Lib/test/test_capi.py, Lib/test/output/test_capi, Modules/_testmodule.c, and PCbuild/_test.dsp ------------------------------------------------------- Date: 2000-Aug-11 13:48 By: tmick Comment: don't use C++ style comments ------------------------------------------------------- Date: 2000-Aug-12 13:46 By: tmick Comment: Skip, You seemed to have some interest in this the couple of times it came up on python-dev. I wonder if you might want to review this. No rush, I don't expect this to go in anytime soon. Unless, of course, people just *have* to have it. ------------------------------------------------------- Date: 2000-Aug-15 15:23 By: tim_one Comment: Sorry, but there is a rush! Since Python 2.0 is scheduled to have only 1 beta cycle, if this doesn't make it into the beta (< 2 weeks, according to the schedule), it's for 2.1 at best. It would be very good to have a start at this (no matter how simple) in place for 2.0. ------------------------------------------------------- Date: 2000-Aug-16 12:05 By: tmick Comment: re: delaying to 2.1: doesn't bother me much Should it now be "postponed", Tim? ------------------------------------------------------- Date: 2000-Aug-21 19:54 By: montanaro Comment: postponed until 2.1 ------------------------------------------------------- Date: 2000-Nov-27 07:47 By: gvanrossum Comment: Randomly reassigned for review now that 2.1 is open and Skip seems to be too busy to look at this. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101162&group_id=5470 From noreply@sourceforge.net Thu Feb 1 23:37:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Feb 2001 15:37:48 -0800 Subject: [Patches] [Patch #103544] Minor cleanup and support for NIS and bsddb on BSD systems Message-ID: Patch #103544 has been updated. Project: python Category: Build Status: Open Submitted by: nobody Assigned to : akuchling Summary: Minor cleanup and support for NIS and bsddb on BSD systems ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103544&group_id=5470 From noreply@sourceforge.net Thu Feb 1 23:54:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Feb 2001 15:54:00 -0800 Subject: [Patches] [Patch #103543] `result' undeclared in Objects/floatobject.c Message-ID: Patch #103543 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: nobody Assigned to : jhylton Summary: `result' undeclared in Objects/floatobject.c Follow-Ups: Date: 2001-Feb-01 15:54 By: jhylton Comment: Ok. rev 2.79 ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103543&group_id=5470 From noreply@sourceforge.net Fri Feb 2 06:02:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Feb 2001 22:02:55 -0800 Subject: [Patches] [Patch #101162] a Python/C API testing framework (simple simple) Message-ID: Patch #101162 has been updated. Project: python Category: Build Status: Open Submitted by: tmick Assigned to : jhylton Summary: a Python/C API testing framework (simple simple) Follow-Ups: Date: 2001-Feb-01 22:02 By: tim_one Comment: Duh, yes, this has been a blind spot. Assigned to Jeremy to assign to someone to do the Unix build changes (sounds like Andrew is begging for it ). Checked in derived changes, like so: Modules/_testmodule.c initial revision: 1.1 test_capi.py initial revision: 1.1 output/test_capi initial revision: 1.1 NEWS new revision: 1.117 PCbuild/_test.dsp initial revision: 1.1 PCbuild/pcbuild.dsw new revision: 1.24 PCbuild/readme.txt new revision: 1.18 ------------------------------------------------------- Date: 2001-Feb-01 15:36 By: jhylton Comment: Will it be possible to include this in 2.1a2? ------------------------------------------------------- Date: 2001-Jan-29 12:51 By: akuchling Comment: Assuming that the _test module doesn't need anything special to compile (and why should it?), the change to setup.py is simple, adding the following line: exts.append( Extension('_test', ['_testmodule.c']) ) ------------------------------------------------------- Date: 2001-Jan-25 05:37 By: nobody Comment: This patch needs to be modified to use setup.py rather then Makefile.pre.in ------------------------------------------------------- Date: 2000-Aug-11 13:37 By: tmick Comment: Here is a proposed patch for a Python/C API testing framework. Simple simple. Basic Overview: - add a _test C extension module that exports test functions beginning with 'test_'; NULL and a TestError exception indicates a test failure and Py_None indicate a test pass - add a test_capi.py test module that calls each of the 'test_' exported functions in the '_test' module - changes to the build system files for Win32 and Unix are includes to build _testmodule.c as a shared extension - new files: Lib/test/test_capi.py, Lib/test/output/test_capi, Modules/_testmodule.c, and PCbuild/_test.dsp ------------------------------------------------------- Date: 2000-Aug-11 13:48 By: tmick Comment: don't use C++ style comments ------------------------------------------------------- Date: 2000-Aug-12 13:46 By: tmick Comment: Skip, You seemed to have some interest in this the couple of times it came up on python-dev. I wonder if you might want to review this. No rush, I don't expect this to go in anytime soon. Unless, of course, people just *have* to have it. ------------------------------------------------------- Date: 2000-Aug-15 15:23 By: tim_one Comment: Sorry, but there is a rush! Since Python 2.0 is scheduled to have only 1 beta cycle, if this doesn't make it into the beta (< 2 weeks, according to the schedule), it's for 2.1 at best. It would be very good to have a start at this (no matter how simple) in place for 2.0. ------------------------------------------------------- Date: 2000-Aug-16 12:05 By: tmick Comment: re: delaying to 2.1: doesn't bother me much Should it now be "postponed", Tim? ------------------------------------------------------- Date: 2000-Aug-21 19:54 By: montanaro Comment: postponed until 2.1 ------------------------------------------------------- Date: 2000-Nov-27 07:47 By: gvanrossum Comment: Randomly reassigned for review now that 2.1 is open and Skip seems to be too busy to look at this. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101162&group_id=5470 From noreply@sourceforge.net Fri Feb 2 09:01:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Feb 2001 01:01:22 -0800 Subject: [Patches] [Patch #103557] Speed-up PyObject_IsTrue Message-ID: Patch #103557 has been updated. Project: python Category: core (C code) Status: Open Submitted by: loewis Assigned to : nobody Summary: Speed-up PyObject_IsTrue ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103557&group_id=5470 From noreply@sourceforge.net Fri Feb 2 09:18:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Feb 2001 01:18:58 -0800 Subject: [Patches] [Patch #103557] Speed-up PyObject_IsTrue Message-ID: Patch #103557 has been updated. Project: python Category: core (C code) Status: Rejected Submitted by: loewis Assigned to : nobody Summary: Speed-up PyObject_IsTrue Follow-Ups: Date: 2001-Feb-02 01:18 By: loewis Comment: The reported numbers are completely bogus. The observed speed-up was caused by inconsistent -O usage; the actual speed-up is 0.1%, if any. So the only value of the patch might be that it saves other the time to benchmark that function. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103557&group_id=5470 From noreply@sourceforge.net Fri Feb 2 17:02:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Feb 2001 09:02:53 -0800 Subject: [Patches] [Patch #101137] Add raw packet support to socketmodule.c Message-ID: Patch #101137 has been updated. Project: python Category: Modules Status: Accepted Submitted by: grante Assigned to : jhylton Summary: Add raw packet support to socketmodule.c Follow-Ups: Date: 2001-Feb-02 09:02 By: grante Comment: Sure -- I've got a small demo program. But, when cleaning up the demo program, I realized that I screwed-up and forgot to include the Ethernet address in the tuple returned by makesockaddr(). Since the user has to fill in the source Ethernet address when a frame is sent, he has to have access to the Ethernet address of the socket. I've made that change, and I've also gotten rid of the need to create a "spare" socket on which to do an interface name lookup. I added the socket file descriptor to the parameter list for makesockname as was suggested earlier. Q: should I revise this patch, or submit a new patch against sources that have already had this patch applied? ------------------------------------------------------- Date: 2001-Feb-01 19:23 By: jhylton Comment: checked in as rev 1.134 Grant-- Could you supply a short example that demonstrates how to use raw sockets? We can't really include the code in the test suite, since you need to be root to use them, but perhaps in the Demo directory. ------------------------------------------------------- Date: 2001-Jan-27 17:02 By: grante Comment: Revised patch: 1) fixed indentation style. 2) fixed possible strncpy buffer overrun. 3) fixed bug in getsockname. 4) exposed sll_pkttype and sll_hatype fields of sockaddr_ll struct (AFAICT, they're not useful). 5) changed conditional compilation so AF_PACKET stuff is only built under Linux. (patch is against 2.0) ------------------------------------------------------- Date: 2001-Jan-18 10:01 By: nobody Comment: Yes, I'm still interested in this patch. Winthin the next week or two I'll try to get a revised patch submitted that addresses some of the comments. Two things I can't do much about are: 1) I only have Linux systems for testing: I don't have root privledges on any other type of system. 2) Unless it is agreed to change parameters for makesockaddr, I can't do anything except create a temporary socket in order to look up the interface name. I suppose I could require user code to provide an interface index, but I don't really like that option since it diverges quite a bit from the "C" usage. ------------------------------------------------------- Date: 2001-Jan-18 09:39 By: jhylton Comment: Is Grant still interested in this patch? I don't have time to fix it myself, but I would be happy to look at it again if we comments and questions are addressed. ------------------------------------------------------- Date: 2000-Aug-09 14:49 By: grante Comment: Patch has only been tested on Linux: RH6.2 (Intel). Patch is against 1.6b1 ------------------------------------------------------- Date: 2000-Aug-15 15:15 By: tim_one Comment: Assigned to Barry, since he just volunteered to rewrite all of Python's socket code anyway . ------------------------------------------------------- Date: 2000-Aug-24 14:27 By: jhylton Comment: Not sure about this patch. It needs to be tested on more platforms than just Linux, but I don't see that we'll have time before 2.0. There are several other issues that must be resolved, too. Thus, this patch falls subject to the feature freeze. Style points: Indention is wrong. The opening curly brace of an if belongs on the same line as the test. Whitespace is required around = and after commas in argument lists. The strncpy in makesockaddr does not check the size of the source string. It could overflow the buffer. In makesockaddr, a new socket is created just to look up the interface name associated with a particular interface. This seems wasteful, particularly in cases where few file descriptors are available. I'm not sure what the solution is, although it might be to change the makesockaddr function so that it takes the socket itself. Perhaps that socket address for AF_PACKET should also accept and/or produce interface numbers which the client can convert to names manually. The sockaddr_ll has members ssl_hatype and ssl_pkttype, which are not made accessible by this patch. It seems like they should be, but I am not sure. Can you use SOCK_DGRAM without specifying the packet type? getsockaddrarg is handled, but getsockaddrlen is not. Question: Are there any other constants that should be added? This relates to the packet type question. * ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101137&group_id=5470 From jeremy@alum.mit.edu Fri Feb 2 17:13:26 2001 From: jeremy@alum.mit.edu (Jeremy Hylton) Date: Fri, 2 Feb 2001 12:13:26 -0500 (EST) Subject: [Patches] Re: [Patch #101137] Add raw packet support to socketmodule.c In-Reply-To: References: Message-ID: <14970.60086.890219.903533@w221.z064000254.bwi-md.dsl.cnc.net> Can you send me a patch against the current source ASAP? I'd like to include it in the alpha. Jeremy From noreply@sourceforge.net Fri Feb 2 17:35:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Feb 2001 09:35:51 -0800 Subject: [Patches] [Patch #101104] Optional object mem allocator Message-ID: Patch #101104 has been updated. Project: python Category: core (C code) Status: Open Submitted by: marangoz Assigned to : bwarsaw Summary: Optional object mem allocator Follow-Ups: Date: 2000-Aug-06 21:05 By: marangoz Comment: A stab on obmalloc.c -- an optional object allocator. A configure "--with(out)-pymalloc" option is introduced for enabling specialized mallocs. Off by default. The code is included conditionally at the end of object.c obmalloc.c contains only the core malloc functionality. No profiling, nor debugging are there -- these would come as separate (and optional) modules: memprof.c & memdebug.c in the Modules/ directory and will exploit the hooks of the allocator. I've managed to draw a rather nice diagram in the comments at the top of obmalloc.c explaining what this stuff is all about. Look there. ------------------------------------------------------- Date: 2000-Aug-07 06:30 By: twouters Comment: Small nit: you shouldn't edit config.h.in yourself, it's autogenerated from acconfig.h and configure.in (with 'autoheader', part of 'autoconf.) You should define WITH_PYMALLOC in acconfig.h, not config.h.in, and run 'autoheader' and 'autoconf' to generate a new 'configure'. I'm in the process of testing this patch on Linux and BSDI, by the way :) ------------------------------------------------------- Date: 2000-Aug-07 09:19 By: marangoz Comment: Thanks. Fixed (acconfig.h) ------------------------------------------------------- Date: 2000-Aug-12 13:31 By: marangoz Comment: Status set to Postponed. Although promising, this hasn't enjoyed much user testing for the 2.0 time frame (partly because of the lack of an introspective Python interface which can't be completed in time according to the release schedule). Assigned to marangoz who's responsible to reopen it again in due time (except if BDFL decides otherwise). ------------------------------------------------------- Date: 2000-Aug-18 21:11 By: marangoz Comment: Update: (1) fixing a missing case for realloc(p,0) == free(p) + ret NULL (2) simplify the hooks interface: set_hooks/fetch_hooks are better than install/uninstall. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101104&group_id=5470 From noreply@sourceforge.net Fri Feb 2 18:35:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Feb 2001 10:35:44 -0800 Subject: [Patches] [Patch #101782] Enhances 1.6 compiler to raise 'proper' SyntaxErrors Message-ID: Patch #101782 has been updated. Project: python Category: Parser/Compiler Status: Open Submitted by: roman_sulzhyk Assigned to : jhylton Summary: Enhances 1.6 compiler to raise 'proper' SyntaxErrors Follow-Ups: Date: 2001-Feb-02 10:35 By: jhylton Comment: I didn't get a chance to look at this before 2.1a2. I will look at it before 2.1b1, because it appears to fall under the bug fix category. ------------------------------------------------------- Date: 2001-Jan-19 14:51 By: gvanrossum Comment: This is better for Jeremy to review, since he has done a major refactoring on the compiler code. Jeremy, I don't want this in 2.1a1, but could you see if you can get it either approved or rejected in time for 2.1a2? ------------------------------------------------------- Date: 2000-Oct-04 12:29 By: roman_sulzhyk Comment: Hello: There's a problem with the compiler.c (which persists in 2.0 also) which means it raises 'old style' SyntaxErrors, which could not be formatted properly. I mentioned this to Guido during the last conference, and he said it can best be done by moving parts of the 'linecache' functionality to core python, or something along those lines. Well, I've put together something which is not so far-fetching, but plugs this hole. The only time it reverts to the 'old style' compile error is when the input file is not a regular file (like stdin), since the line information is lost at that point - don't think parser.c saves it anywhere. Tell me what you think - should I port it to 2.0, or just drop it altogether if it's not needed. Thanks, Roman ------------------------------------------------------- Date: 2000-Oct-04 23:40 By: fdrake Comment: This needs to be ported to the latest CVS version before being considered for implementation (but discussion of the feature is welcome!). This cannot be considered for inclusion in 2.0 since we're in feature freeze already, and are only fixing bugs at this point. This can be considered for 2.1. Marking as postponed. ------------------------------------------------------- Date: 2000-Oct-09 10:59 By: roman_sulzhyk Comment: I've ported it to the latest CVS version - check it out, Roman ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101782&group_id=5470 From noreply@sourceforge.net Fri Feb 2 18:36:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Feb 2001 10:36:36 -0800 Subject: [Patches] [Patch #101782] Enhances 1.6 compiler to raise 'proper' SyntaxErrors Message-ID: Patch #101782 has been updated. Project: python Category: Parser/Compiler Status: Open Submitted by: roman_sulzhyk Assigned to : jhylton Summary: Enhances 1.6 compiler to raise 'proper' SyntaxErrors Follow-Ups: Date: 2001-Feb-02 10:36 By: jhylton Comment: Oh, BTW, with all the changes to the compiler for 2.1, this patch no longer works. If you're interested in updating it, I'd appreciate it. I'll look at the patch either way, though. ------------------------------------------------------- Date: 2001-Feb-02 10:35 By: jhylton Comment: I didn't get a chance to look at this before 2.1a2. I will look at it before 2.1b1, because it appears to fall under the bug fix category. ------------------------------------------------------- Date: 2001-Jan-19 14:51 By: gvanrossum Comment: This is better for Jeremy to review, since he has done a major refactoring on the compiler code. Jeremy, I don't want this in 2.1a1, but could you see if you can get it either approved or rejected in time for 2.1a2? ------------------------------------------------------- Date: 2000-Oct-04 12:29 By: roman_sulzhyk Comment: Hello: There's a problem with the compiler.c (which persists in 2.0 also) which means it raises 'old style' SyntaxErrors, which could not be formatted properly. I mentioned this to Guido during the last conference, and he said it can best be done by moving parts of the 'linecache' functionality to core python, or something along those lines. Well, I've put together something which is not so far-fetching, but plugs this hole. The only time it reverts to the 'old style' compile error is when the input file is not a regular file (like stdin), since the line information is lost at that point - don't think parser.c saves it anywhere. Tell me what you think - should I port it to 2.0, or just drop it altogether if it's not needed. Thanks, Roman ------------------------------------------------------- Date: 2000-Oct-04 23:40 By: fdrake Comment: This needs to be ported to the latest CVS version before being considered for implementation (but discussion of the feature is welcome!). This cannot be considered for inclusion in 2.0 since we're in feature freeze already, and are only fixing bugs at this point. This can be considered for 2.1. Marking as postponed. ------------------------------------------------------- Date: 2000-Oct-09 10:59 By: roman_sulzhyk Comment: I've ported it to the latest CVS version - check it out, Roman ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101782&group_id=5470 From noreply@sourceforge.net Fri Feb 2 18:37:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Feb 2001 10:37:18 -0800 Subject: [Patches] [Patch #101162] a Python/C API testing framework (simple simple) Message-ID: Patch #101162 has been updated. Project: python Category: Build Status: Closed Submitted by: tmick Assigned to : jhylton Summary: a Python/C API testing framework (simple simple) Follow-Ups: Date: 2001-Feb-02 10:37 By: jhylton Comment: MAL added the necessary setup.py entry ------------------------------------------------------- Date: 2001-Feb-01 22:02 By: tim_one Comment: Duh, yes, this has been a blind spot. Assigned to Jeremy to assign to someone to do the Unix build changes (sounds like Andrew is begging for it ). Checked in derived changes, like so: Modules/_testmodule.c initial revision: 1.1 test_capi.py initial revision: 1.1 output/test_capi initial revision: 1.1 NEWS new revision: 1.117 PCbuild/_test.dsp initial revision: 1.1 PCbuild/pcbuild.dsw new revision: 1.24 PCbuild/readme.txt new revision: 1.18 ------------------------------------------------------- Date: 2001-Feb-01 15:36 By: jhylton Comment: Will it be possible to include this in 2.1a2? ------------------------------------------------------- Date: 2001-Jan-29 12:51 By: akuchling Comment: Assuming that the _test module doesn't need anything special to compile (and why should it?), the change to setup.py is simple, adding the following line: exts.append( Extension('_test', ['_testmodule.c']) ) ------------------------------------------------------- Date: 2001-Jan-25 05:37 By: nobody Comment: This patch needs to be modified to use setup.py rather then Makefile.pre.in ------------------------------------------------------- Date: 2000-Aug-11 13:37 By: tmick Comment: Here is a proposed patch for a Python/C API testing framework. Simple simple. Basic Overview: - add a _test C extension module that exports test functions beginning with 'test_'; NULL and a TestError exception indicates a test failure and Py_None indicate a test pass - add a test_capi.py test module that calls each of the 'test_' exported functions in the '_test' module - changes to the build system files for Win32 and Unix are includes to build _testmodule.c as a shared extension - new files: Lib/test/test_capi.py, Lib/test/output/test_capi, Modules/_testmodule.c, and PCbuild/_test.dsp ------------------------------------------------------- Date: 2000-Aug-11 13:48 By: tmick Comment: don't use C++ style comments ------------------------------------------------------- Date: 2000-Aug-12 13:46 By: tmick Comment: Skip, You seemed to have some interest in this the couple of times it came up on python-dev. I wonder if you might want to review this. No rush, I don't expect this to go in anytime soon. Unless, of course, people just *have* to have it. ------------------------------------------------------- Date: 2000-Aug-15 15:23 By: tim_one Comment: Sorry, but there is a rush! Since Python 2.0 is scheduled to have only 1 beta cycle, if this doesn't make it into the beta (< 2 weeks, according to the schedule), it's for 2.1 at best. It would be very good to have a start at this (no matter how simple) in place for 2.0. ------------------------------------------------------- Date: 2000-Aug-16 12:05 By: tmick Comment: re: delaying to 2.1: doesn't bother me much Should it now be "postponed", Tim? ------------------------------------------------------- Date: 2000-Aug-21 19:54 By: montanaro Comment: postponed until 2.1 ------------------------------------------------------- Date: 2000-Nov-27 07:47 By: gvanrossum Comment: Randomly reassigned for review now that 2.1 is open and Skip seems to be too busy to look at this. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101162&group_id=5470 From noreply@sourceforge.net Fri Feb 2 19:08:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Feb 2001 11:08:02 -0800 Subject: [Patches] [Patch #103495] case sensitive import for case insensitive FileSystem Message-ID: Patch #103495 has been updated. Project: python Category: core (C code) Status: Open Submitted by: sdm7g Assigned to : gvanrossum Summary: case sensitive import for case insensitive FileSystem Follow-Ups: Date: 2001-Feb-02 11:08 By: bwarsaw Comment: Here's a version of the patch that applies cleanly to the 2.1a2 source, conforms to C coding styles, and builds on Linux RH 6.1. It passes regrtest and "import getpass" (termios/TERMIOS). I cannot test it on any other platform. I'm marking this as accepted and commiting it to the 2.1a2 tree. Once other platforms have verified that it works for them, we can close the patch. ------------------------------------------------------- Date: 2001-Feb-01 06:47 By: jlt63 Comment: Scratch the comment about the bug -- I've too much C++ on the head to think in straight C anymore. ------------------------------------------------------- Date: 2001-Jan-31 18:20 By: jlt63 Comment: Guido, Do you find the style of this patch more acceptable than mine (103154)? If so, would you consider including a cleaned up version into 2.1a2? Note that I have found one bug (MatchFilename() does not handle a NULL pathname correctly) and the code should probably be enabled on something more specific than HAVE_DIRENT_H (e.g., platform #defs, UNIX_STYLE_CHECK_IMPORT_CASE, etc). ------------------------------------------------------- Date: 2001-Jan-29 20:30 By: sdm7g Comment: Oops! The previous patch crashes if the path is empty, which is the case for the current directory. Added a line to check for that and use "." instead on diropen. -- Steve M. ------------------------------------------------------- Date: 2001-Jan-29 20:27 By: sdm7g Comment: Oops! The previous patch crashes if the path is empty, which is the case for the current directory. Added a line to check for that and use "." instead on diropen. -- Steve M. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103495&group_id=5470 From noreply@sourceforge.net Fri Feb 2 19:09:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 02 Feb 2001 11:09:44 -0800 Subject: [Patches] [Patch #103495] case sensitive import for case insensitive FileSystem Message-ID: Patch #103495 has been updated. Project: python Category: core (C code) Status: Accepted Submitted by: sdm7g Assigned to : gvanrossum Summary: case sensitive import for case insensitive FileSystem Follow-Ups: Date: 2001-Feb-02 11:09 By: bwarsaw Comment: Whoops! Marking as accepted. ------------------------------------------------------- Date: 2001-Feb-02 11:08 By: bwarsaw Comment: Here's a version of the patch that applies cleanly to the 2.1a2 source, conforms to C coding styles, and builds on Linux RH 6.1. It passes regrtest and "import getpass" (termios/TERMIOS). I cannot test it on any other platform. I'm marking this as accepted and commiting it to the 2.1a2 tree. Once other platforms have verified that it works for them, we can close the patch. ------------------------------------------------------- Date: 2001-Feb-01 06:47 By: jlt63 Comment: Scratch the comment about the bug -- I've too much C++ on the head to think in straight C anymore. ------------------------------------------------------- Date: 2001-Jan-31 18:20 By: jlt63 Comment: Guido, Do you find the style of this patch more acceptable than mine (103154)? If so, would you consider including a cleaned up version into 2.1a2? Note that I have found one bug (MatchFilename() does not handle a NULL pathname correctly) and the code should probably be enabled on something more specific than HAVE_DIRENT_H (e.g., platform #defs, UNIX_STYLE_CHECK_IMPORT_CASE, etc). ------------------------------------------------------- Date: 2001-Jan-29 20:30 By: sdm7g Comment: Oops! The previous patch crashes if the path is empty, which is the case for the current directory. Added a line to check for that and use "." instead on diropen. -- Steve M. ------------------------------------------------------- Date: 2001-Jan-29 20:27 By: sdm7g Comment: Oops! The previous patch crashes if the path is empty, which is the case for the current directory. Added a line to check for that and use "." instead on diropen. -- Steve M. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103495&group_id=5470 From noreply@sourceforge.net Sat Feb 3 17:37:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 03 Feb 2001 09:37:31 -0800 Subject: [Patches] [Patch #103578] setup.py: _tkinter build fix for Debian unstable Message-ID: Patch #103578 has been updated. Project: python Category: None Status: Open Submitted by: mfx Assigned to : nobody Summary: setup.py: _tkinter build fix for Debian unstable ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103578&group_id=5470 From noreply@sourceforge.net Sat Feb 3 22:46:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 03 Feb 2001 14:46:57 -0800 Subject: [Patches] [Patch #103587] Python 2.1a2 distutils install_data command broken Message-ID: Patch #103587 has been updated. Project: python Category: distutils Status: Open Submitted by: uche Assigned to : nobody Summary: Python 2.1a2 distutils install_data command broken ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103587&group_id=5470 From noreply@sourceforge.net Sun Feb 4 00:23:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 03 Feb 2001 16:23:56 -0800 Subject: [Patches] [Patch #103589] Fix segfault related to nested scopes Message-ID: Patch #103589 has been updated. Project: python Category: Parser/Compiler Status: Open Submitted by: nickm Assigned to : nobody Summary: Fix segfault related to nested scopes ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103589&group_id=5470 From noreply@sourceforge.net Sun Feb 4 15:18:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 04 Feb 2001 07:18:03 -0800 Subject: [Patches] [Patch #103596] Make UnboundLocalError work in nested scopes (fix segfault) Message-ID: Patch #103596 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nickm Assigned to : nobody Summary: Make UnboundLocalError work in nested scopes (fix segfault) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103596&group_id=5470 From noreply@sourceforge.net Sun Feb 4 15:22:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 04 Feb 2001 07:22:32 -0800 Subject: [Patches] [Patch #103589] Fix segfault related to nested scopes Message-ID: Patch #103589 has been updated. Project: python Category: Parser/Compiler Status: Open Submitted by: nickm Assigned to : nobody Summary: Fix segfault related to nested scopes Follow-Ups: Date: 2001-Feb-04 07:22 By: nickm Comment: Improved patch; original patch modified unreleated code. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103589&group_id=5470 From noreply@sourceforge.net Sun Feb 4 17:38:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 04 Feb 2001 09:38:11 -0800 Subject: [Patches] [Patch #103589] Fix segfault related to nested scopes Message-ID: Patch #103589 has been updated. Project: python Category: Parser/Compiler Status: Open Submitted by: nickm Assigned to : nobody Summary: Fix segfault related to nested scopes Follow-Ups: Date: 2001-Feb-04 09:38 By: nickm Comment: Oops! That wasn't a context diff. This should be. ------------------------------------------------------- Date: 2001-Feb-04 07:22 By: nickm Comment: Improved patch; original patch modified unreleated code. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103589&group_id=5470 From noreply@sourceforge.net Sun Feb 4 17:39:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 04 Feb 2001 09:39:16 -0800 Subject: [Patches] [Patch #103596] Make UnboundLocalError work in nested scopes (fix segfault) Message-ID: Patch #103596 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nickm Assigned to : nobody Summary: Make UnboundLocalError work in nested scopes (fix segfault) Follow-Ups: Date: 2001-Feb-04 09:39 By: nickm Comment: Oops! That wasn't a context diff. This is. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103596&group_id=5470 From noreply@sourceforge.net Sun Feb 4 19:18:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 04 Feb 2001 11:18:56 -0800 Subject: [Patches] [Patch #103596] Make UnboundLocalError work in nested scopes (fix segfault) Message-ID: Patch #103596 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nickm Assigned to : jhylton Summary: Make UnboundLocalError work in nested scopes (fix segfault) Follow-Ups: Date: 2001-Feb-04 11:18 By: tim_one Comment: Assigned to Jeremy. Jeremy, appears to be the same problem as I posted a case for on Python-Dev. ------------------------------------------------------- Date: 2001-Feb-04 09:39 By: nickm Comment: Oops! That wasn't a context diff. This is. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103596&group_id=5470 From noreply@sourceforge.net Mon Feb 5 16:53:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 05 Feb 2001 08:53:12 -0800 Subject: [Patches] [Patch #103596] Make UnboundLocalError work in nested scopes (fix segfault) Message-ID: Patch #103596 has been updated. Project: python Category: core (C code) Status: Accepted Submitted by: nickm Assigned to : jhylton Summary: Make UnboundLocalError work in nested scopes (fix segfault) Follow-Ups: Date: 2001-Feb-04 11:18 By: tim_one Comment: Assigned to Jeremy. Jeremy, appears to be the same problem as I posted a case for on Python-Dev. ------------------------------------------------------- Date: 2001-Feb-04 09:39 By: nickm Comment: Oops! That wasn't a context diff. This is. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103596&group_id=5470 From noreply@sourceforge.net Mon Feb 5 17:44:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 05 Feb 2001 09:44:40 -0800 Subject: [Patches] [Patch #103587] Python 2.1a2 distutils install_data command broken Message-ID: Patch #103587 has been updated. Project: python Category: distutils Status: Closed Submitted by: uche Assigned to : akuchling Summary: Python 2.1a2 distutils install_data command broken Follow-Ups: Date: 2001-Feb-05 09:44 By: akuchling Comment: Good catch. Applied. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103587&group_id=5470 From noreply@sourceforge.net Mon Feb 5 18:34:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 05 Feb 2001 10:34:39 -0800 Subject: [Patches] [Patch #103596] Make UnboundLocalError work in nested scopes (fix segfault) Message-ID: Patch #103596 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: nickm Assigned to : jhylton Summary: Make UnboundLocalError work in nested scopes (fix segfault) Follow-Ups: Date: 2001-Feb-05 10:34 By: jhylton Comment: rev 2.228 of ceval.c ------------------------------------------------------- Date: 2001-Feb-04 11:18 By: tim_one Comment: Assigned to Jeremy. Jeremy, appears to be the same problem as I posted a case for on Python-Dev. ------------------------------------------------------- Date: 2001-Feb-04 09:39 By: nickm Comment: Oops! That wasn't a context diff. This is. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103596&group_id=5470 From noreply@sourceforge.net Tue Feb 6 12:05:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 06 Feb 2001 04:05:33 -0800 Subject: [Patches] [Patch #103636] Fix for null byte strings in SSL support of socketmodule.c Message-ID: Patch #103636 has been updated. Project: python Category: Modules Status: Open Submitted by: xyld Assigned to : nobody Summary: Fix for null byte strings in SSL support of socketmodule.c ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103636&group_id=5470 From noreply@sourceforge.net Tue Feb 6 12:20:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 06 Feb 2001 04:20:37 -0800 Subject: [Patches] [Patch #103636] Fix for null byte strings in SSL support of socketmodule.c Message-ID: Patch #103636 has been updated. Project: python Category: Modules Status: Open Submitted by: xyld Assigned to : akuchling Summary: Fix for null byte strings in SSL support of socketmodule.c Follow-Ups: Date: 2001-Feb-06 04:20 By: moshez Comment: Andrew, this seems straightforward and correct. Is there supposed to be some problem with transmitting null bytes on SSL connection (I assume not...) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103636&group_id=5470 From noreply@sourceforge.net Tue Feb 6 12:34:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 06 Feb 2001 04:34:24 -0800 Subject: [Patches] [Patch #103589] Fix segfault related to nested scopes Message-ID: Patch #103589 has been updated. Project: python Category: Parser/Compiler Status: Open Submitted by: nickm Assigned to : jhylton Summary: Fix segfault related to nested scopes Follow-Ups: Date: 2001-Feb-06 04:34 By: moshez Comment: assigning to Jeremy -- I think he fixed the problems Jeremy, I think this patch is no longer relevant. ------------------------------------------------------- Date: 2001-Feb-04 09:38 By: nickm Comment: Oops! That wasn't a context diff. This should be. ------------------------------------------------------- Date: 2001-Feb-04 07:22 By: nickm Comment: Improved patch; original patch modified unreleated code. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103589&group_id=5470 From noreply@sourceforge.net Tue Feb 6 12:38:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 06 Feb 2001 04:38:48 -0800 Subject: [Patches] [Patch #103578] setup.py: _tkinter build fix for Debian unstable Message-ID: Patch #103578 has been updated. Project: python Category: None Status: Open Submitted by: mfx Assigned to : akuchling Summary: setup.py: _tkinter build fix for Debian unstable Follow-Ups: Date: 2001-Feb-06 04:38 By: moshez Comment: Assigning to Andrew -- this patch looks more complicated then it really is, just adds one more directory to the include path on debian. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103578&group_id=5470 From noreply@sourceforge.net Tue Feb 6 14:14:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 06 Feb 2001 06:14:47 -0800 Subject: [Patches] [Patch #103589] Fix segfault related to nested scopes Message-ID: Patch #103589 has been updated. Project: python Category: Parser/Compiler Status: Open Submitted by: nickm Assigned to : jhylton Summary: Fix segfault related to nested scopes Follow-Ups: Date: 2001-Feb-06 06:14 By: nickm Comment: Just to clarify, if this problem is fixed, the fix isn't in CVS. I can still induce a segfault with: def outer(*args): def inner(): print args outer(1,2,3) This patch fixes this problem. ------------------------------------------------------- Date: 2001-Feb-06 04:34 By: moshez Comment: assigning to Jeremy -- I think he fixed the problems Jeremy, I think this patch is no longer relevant. ------------------------------------------------------- Date: 2001-Feb-04 09:38 By: nickm Comment: Oops! That wasn't a context diff. This should be. ------------------------------------------------------- Date: 2001-Feb-04 07:22 By: nickm Comment: Improved patch; original patch modified unreleated code. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103589&group_id=5470 From noreply@sourceforge.net Tue Feb 6 14:57:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 06 Feb 2001 06:57:58 -0800 Subject: [Patches] [Patch #103640] incomplete proxy handling in URLLIB Message-ID: Patch #103640 has been updated. Project: python Category: library Status: Open Submitted by: nobody Assigned to : nobody Summary: incomplete proxy handling in URLLIB ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103640&group_id=5470 From noreply@sourceforge.net Tue Feb 6 18:16:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 06 Feb 2001 10:16:08 -0800 Subject: [Patches] [Patch #103642] BeOS dislikes import tempfile in _execvpe() Message-ID: Patch #103642 has been updated. Project: python Category: None Status: Open Submitted by: donnc Assigned to : nobody Summary: BeOS dislikes import tempfile in _execvpe() ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103642&group_id=5470 From noreply@sourceforge.net Tue Feb 6 22:16:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 06 Feb 2001 14:16:04 -0800 Subject: [Patches] [Patch #103578] setup.py: _tkinter build fix for Debian unstable Message-ID: Patch #103578 has been updated. Project: python Category: Build Status: Closed Submitted by: mfx Assigned to : akuchling Summary: setup.py: _tkinter build fix for Debian unstable Follow-Ups: Date: 2001-Feb-06 14:16 By: akuchling Comment: Applied; thanks! ------------------------------------------------------- Date: 2001-Feb-06 04:38 By: moshez Comment: Assigning to Andrew -- this patch looks more complicated then it really is, just adds one more directory to the include path on debian. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103578&group_id=5470 From noreply@sourceforge.net Tue Feb 6 22:31:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 06 Feb 2001 14:31:28 -0800 Subject: [Patches] [Patch #103544] Minor cleanup and support for NIS and bsddb on BSD systems Message-ID: Patch #103544 has been updated. Project: python Category: Build Status: Open Submitted by: nobody Assigned to : akuchling Summary: Minor cleanup and support for NIS and bsddb on BSD systems Follow-Ups: Date: 2001-Feb-06 14:31 By: akuchling Comment: I've applied the portion of this patch that applies to the BSDDB module, and removing the extra comment. I'm not sure of enabling the dl module, and have asked python-dev for an opinion. I'm also not sure of always trying to compile the nis module; does almost everyone have it in libc these days? A configure test for some appropriate symbol would probably be better, though then it's difficult to check that in setup.py. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103544&group_id=5470 From noreply@sourceforge.net Tue Feb 6 22:34:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 06 Feb 2001 14:34:29 -0800 Subject: [Patches] [Patch #103523] mpz module doesn't build under cygwin Message-ID: Patch #103523 has been updated. Project: python Category: Modules Status: Closed Submitted by: nobody Assigned to : akuchling Summary: mpz module doesn't build under cygwin Follow-Ups: Date: 2001-Feb-06 14:34 By: akuchling Comment: Applied without the #ifdef's, as Tim suggested. ------------------------------------------------------- Date: 2001-Jan-31 00:24 By: tim_one Comment: Assigned to Andrew, because I'm hallucinating he may know more about mpz than the rest of us. Andrew, if you approve of this change, please make it, but on *all* platforms (i.e., do what the patch is getting at but don't apply the patch as-is -- there's no need to clutter the code with #ifdefs here). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103523&group_id=5470 From noreply@sourceforge.net Tue Feb 6 22:43:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 06 Feb 2001 14:43:51 -0800 Subject: [Patches] [Patch #103473] Cookie.py: Allow values containing '=' Message-ID: Patch #103473 has been updated. Project: python Category: library Status: Accepted Submitted by: dougfort Assigned to : akuchling Summary: Cookie.py: Allow values containing '=' Follow-Ups: Date: 2001-Feb-06 14:43 By: akuchling Comment: This seems non-compliant with RFC2109, the only relevant standard, but practically no one implements 2109 to the letter anyway. Practicality beats purity, so I think it should be applied. ------------------------------------------------------- Date: 2001-Jan-29 15:53 By: gvanrossum Comment: Andrew, can you check this? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103473&group_id=5470 From noreply@sourceforge.net Tue Feb 6 22:44:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 06 Feb 2001 14:44:43 -0800 Subject: [Patches] [Patch #103334] Strip "." pathname components Message-ID: Patch #103334 has been updated. Project: python Category: distutils Status: Closed Submitted by: jackjansen Assigned to : akuchling Summary: Strip "." pathname components Follow-Ups: Date: 2001-Jan-24 17:00 By: akuchling Comment: Seems reasonable; please go ahead and check it in. ------------------------------------------------------- Date: 2001-Jan-19 14:41 By: gvanrossum Comment: Looks decent to me. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103334&group_id=5470 From noreply@sourceforge.net Tue Feb 6 22:45:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 06 Feb 2001 14:45:03 -0800 Subject: [Patches] [Patch #103333] install_data does not do pathname conversion Message-ID: Patch #103333 has been updated. Project: python Category: distutils Status: Closed Submitted by: jackjansen Assigned to : akuchling Summary: install_data does not do pathname conversion Follow-Ups: Date: 2001-Jan-24 17:01 By: akuchling Comment: Looks good; please check it in. ------------------------------------------------------- Date: 2001-Jan-19 14:42 By: gvanrossum Comment: For Andrew. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103333&group_id=5470 From noreply@sourceforge.net Tue Feb 6 22:46:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 06 Feb 2001 14:46:37 -0800 Subject: [Patches] [Patch #103279] Flag for making sysconfig assume build directories Message-ID: Patch #103279 has been updated. Project: python Category: distutils Status: Closed Submitted by: akuchling Assigned to : gward Summary: Flag for making sysconfig assume build directories Follow-Ups: Date: 2001-Feb-06 14:46 By: akuchling Comment: Moved to 'closed' status, invalidating my earlier comment of Jan. 17. ------------------------------------------------------- Date: 2001-Jan-17 07:17 By: akuchling Comment: Checked in and moved to 'Accepted' status, so gward can look at it later. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103279&group_id=5470 From noreply@sourceforge.net Tue Feb 6 22:46:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 06 Feb 2001 14:46:17 -0800 Subject: [Patches] [Patch #102971] build_ext -L typo fix Message-ID: Patch #102971 has been updated. Project: python Category: distutils Status: Closed Submitted by: calvin Assigned to : gward Summary: build_ext -L typo fix Follow-Ups: Date: 2001-Feb-06 14:46 By: akuchling Comment: Moving this to 'Closed' to clean up the list of accepted patches, invalidating my comment of Jan. 08. Greg will just have to look at the CVS logs. ------------------------------------------------------- Date: 2001-Jan-18 16:08 By: gvanrossum Comment: Sorry. I didn't realize why Andrew left it Accepted. ------------------------------------------------------- Date: 2001-Jan-18 16:05 By: gvanrossum Comment: This was checked in alrady. ------------------------------------------------------- Date: 2001-Jan-18 16:05 By: gvanrossum Comment: This was checked in alrady. ------------------------------------------------------- Date: 2001-Jan-08 19:16 By: akuchling Comment: Checked in; leaving it in "Accepted" so Greg can review it (and possibly back it out) when he gets back. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102971&group_id=5470 From noreply@sourceforge.net Tue Feb 6 22:54:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 06 Feb 2001 14:54:50 -0800 Subject: [Patches] [Patch #103487] BeOS build scripts, setup.py Message-ID: Patch #103487 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : akuchling Summary: BeOS build scripts, setup.py Follow-Ups: Date: 2001-Feb-06 14:54 By: akuchling Comment: This patch seems to be quite out of date now; it refers to setup.cfg.in which no longer exists. Perhaps setup.cfg.in needs to be resurrected. Donn, what's the current state of compiling alpha2 (or the CVS tree) on BeOS? Can you provide an updated version of this patch? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103487&group_id=5470 From noreply@sourceforge.net Tue Feb 6 22:58:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 06 Feb 2001 14:58:09 -0800 Subject: [Patches] [Patch #103636] Fix for null byte strings in SSL support of socketmodule.c Message-ID: Patch #103636 has been updated. Project: python Category: Modules Status: Closed Submitted by: xyld Assigned to : akuchling Summary: Fix for null byte strings in SSL support of socketmodule.c Follow-Ups: Date: 2001-Feb-06 14:58 By: akuchling Comment: Applied; thanks! ------------------------------------------------------- Date: 2001-Feb-06 04:20 By: moshez Comment: Andrew, this seems straightforward and correct. Is there supposed to be some problem with transmitting null bytes on SSL connection (I assume not...) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103636&group_id=5470 From noreply@sourceforge.net Tue Feb 6 23:21:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 06 Feb 2001 15:21:37 -0800 Subject: [Patches] [Patch #103277] Enables a package to have more than one source dir Message-ID: Patch #103277 has been updated. Project: python Category: distutils Status: Open Submitted by: nobody Assigned to : akuchling Summary: Enables a package to have more than one source dir Follow-Ups: Date: 2001-Feb-06 15:21 By: houmang Comment: There are various reasons. For instance numpy has several parts of the code organized as separate directories that constitute one Python package. Some of it is for historical reasons. Some of it is to control "optionality". i.e. you could build a "lite" version or a "heavy" version and whatever you choose gets merged into the installed package. Others might spread out code just for source maintenance and control reasons. ------------------------------------------------------- Date: 2001-Jan-28 10:19 By: akuchling Comment: I'm doubtful of the usefulness of this patch; can you please explain the motivation? Why do you want to have multiple directories containing the Python files for a single package? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103277&group_id=5470 From noreply@sourceforge.net Wed Feb 7 03:22:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 06 Feb 2001 19:22:35 -0800 Subject: [Patches] [Patch #103487] BeOS build scripts, setup.py Message-ID: Patch #103487 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : akuchling Summary: BeOS build scripts, setup.py Follow-Ups: Date: 2001-Feb-06 19:22 By: donnc Comment: The a2 Makefile scheme will make things simpler, but the problems addressed by the patch are still there. I can make another revision for a2, maybe tomorrow after working out an AIX build with separate read-only source directory. A lot of the design here is hardly more than personal preference - do you want setup.py to have a lot of "if platform == 'Darwin1.2' ... if platform[:4] == 'beos' ... "? Or should that go in the configure script? - that's what I think, but it's really up to whoever has to maintain this system. Issues are "what modules to try to build", "-lm or not", standard paths for libraries & includes (sadly, not everyone starts at /usr), and doubtless tons of other stuff is on its way. Does setup.cfg.in need to be resurrected? What do you think? ------------------------------------------------------- Date: 2001-Feb-06 14:54 By: akuchling Comment: This patch seems to be quite out of date now; it refers to setup.cfg.in which no longer exists. Perhaps setup.cfg.in needs to be resurrected. Donn, what's the current state of compiling alpha2 (or the CVS tree) on BeOS? Can you provide an updated version of this patch? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103487&group_id=5470 From noreply@sourceforge.net Wed Feb 7 13:30:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 07 Feb 2001 05:30:46 -0800 Subject: [Patches] [Patch #103655] configure changes for Solaris Message-ID: Patch #103655 has been updated. Project: python Category: Build Status: Open Submitted by: sgriggs Assigned to : nobody Summary: configure changes for Solaris ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103655&group_id=5470 From noreply@sourceforge.net Wed Feb 7 13:35:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 07 Feb 2001 05:35:02 -0800 Subject: [Patches] [Patch #103656] configure.in changes for Solaris Message-ID: Patch #103656 has been updated. Project: python Category: Build Status: Open Submitted by: sgriggs Assigned to : nobody Summary: configure.in changes for Solaris ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103656&group_id=5470 From noreply@sourceforge.net Wed Feb 7 13:37:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 07 Feb 2001 05:37:26 -0800 Subject: [Patches] [Patch #103657] make install on solaris dies duringing mkdir Message-ID: Patch #103657 has been updated. Project: python Category: Build Status: Open Submitted by: sgriggs Assigned to : nobody Summary: make install on solaris dies duringing mkdir ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103657&group_id=5470 From noreply@sourceforge.net Wed Feb 7 15:05:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 07 Feb 2001 07:05:34 -0800 Subject: [Patches] [Patch #103657] make install on solaris dies duringing mkdir Message-ID: Patch #103657 has been updated. Project: python Category: Build Status: Open Submitted by: sgriggs Assigned to : nobody Summary: make install on solaris dies duringing mkdir Follow-Ups: Date: 2001-Feb-07 07:05 By: nascheme Comment: Why is INSTALL=cp and not install-sh? I don't think this patch is the correct solution. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103657&group_id=5470 From noreply@sourceforge.net Wed Feb 7 20:16:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 07 Feb 2001 12:16:37 -0800 Subject: [Patches] [Patch #103665] Allow test___all__ to work with jython. Message-ID: Patch #103665 has been updated. Project: python Category: None Status: Open Submitted by: bckfnn Assigned to : nobody Summary: Allow test___all__ to work with jython. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103665&group_id=5470 From noreply@sourceforge.net Wed Feb 7 20:25:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 07 Feb 2001 12:25:06 -0800 Subject: [Patches] [Patch #103666] Allow jython to use test_new Message-ID: Patch #103666 has been updated. Project: python Category: None Status: Open Submitted by: bckfnn Assigned to : nobody Summary: Allow jython to use test_new ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103666&group_id=5470 From noreply@sourceforge.net Wed Feb 7 20:26:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 07 Feb 2001 12:26:33 -0800 Subject: [Patches] [Patch #103667] Allow jython to work with test_socket. Message-ID: Patch #103667 has been updated. Project: python Category: None Status: Open Submitted by: bckfnn Assigned to : nobody Summary: Allow jython to work with test_socket. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103667&group_id=5470 From noreply@sourceforge.net Wed Feb 7 20:28:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 07 Feb 2001 12:28:15 -0800 Subject: [Patches] [Patch #103668] Allow jython to make temporary test modules Message-ID: Patch #103668 has been updated. Project: python Category: None Status: Open Submitted by: bckfnn Assigned to : nobody Summary: Allow jython to make temporary test modules ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103668&group_id=5470 From noreply@sourceforge.net Wed Feb 7 20:31:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 07 Feb 2001 12:31:39 -0800 Subject: [Patches] [Patch #103669] Allow jython to complete the test_unicode. Message-ID: Patch #103669 has been updated. Project: python Category: None Status: Open Submitted by: bckfnn Assigned to : nobody Summary: Allow jython to complete the test_unicode. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103669&group_id=5470 From noreply@sourceforge.net Wed Feb 7 21:06:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 07 Feb 2001 13:06:11 -0800 Subject: [Patches] [Patch #103671] Allow jython to complete the test_class test Message-ID: Patch #103671 has been updated. Project: python Category: None Status: Open Submitted by: bckfnn Assigned to : nobody Summary: Allow jython to complete the test_class test ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103671&group_id=5470 From noreply@sourceforge.net Wed Feb 7 22:48:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 07 Feb 2001 14:48:02 -0800 Subject: [Patches] [Patch #103665] Allow test___all__ to work with jython. Message-ID: Patch #103665 has been updated. Project: python Category: library Status: Closed Submitted by: bckfnn Assigned to : montanaro Summary: Allow test___all__ to work with jython. Follow-Ups: Date: 2001-Feb-07 14:48 By: montanaro Comment: Finn, thanks for the patch. I've applied it and checked it in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103665&group_id=5470 From noreply@sourceforge.net Thu Feb 8 06:39:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 07 Feb 2001 22:39:06 -0800 Subject: [Patches] [Patch #103678] setup.py.in Message-ID: Patch #103678 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : nobody Summary: setup.py.in ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103678&group_id=5470 From noreply@sourceforge.net Thu Feb 8 07:04:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 07 Feb 2001 23:04:36 -0800 Subject: [Patches] [Patch #103679] AIX and BeOS build quirk revisions Message-ID: Patch #103679 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : nobody Summary: AIX and BeOS build quirk revisions ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103679&group_id=5470 From noreply@sourceforge.net Thu Feb 8 07:10:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 07 Feb 2001 23:10:25 -0800 Subject: [Patches] [Patch #103680] small change to ld_so_beos (apply after 103679) Message-ID: Patch #103680 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : nobody Summary: small change to ld_so_beos (apply after 103679) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103680&group_id=5470 From noreply@sourceforge.net Thu Feb 8 07:20:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 07 Feb 2001 23:20:20 -0800 Subject: [Patches] [Patch #103681] Remove grammar rule from Makefile Message-ID: Patch #103681 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : nobody Summary: Remove grammar rule from Makefile ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103681&group_id=5470 From noreply@sourceforge.net Thu Feb 8 07:25:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 07 Feb 2001 23:25:29 -0800 Subject: [Patches] [Patch #103487] BeOS build scripts, setup.py Message-ID: Patch #103487 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : akuchling Summary: BeOS build scripts, setup.py Follow-Ups: Date: 2001-Feb-07 23:25 By: donnc Comment: OK, please close it! Mr. Kuchling, you can follow your particular interest in this patch in 103678. The rest of the BeOS and AIX mess moves to 103679. ------------------------------------------------------- Date: 2001-Feb-06 19:22 By: donnc Comment: The a2 Makefile scheme will make things simpler, but the problems addressed by the patch are still there. I can make another revision for a2, maybe tomorrow after working out an AIX build with separate read-only source directory. A lot of the design here is hardly more than personal preference - do you want setup.py to have a lot of "if platform == 'Darwin1.2' ... if platform[:4] == 'beos' ... "? Or should that go in the configure script? - that's what I think, but it's really up to whoever has to maintain this system. Issues are "what modules to try to build", "-lm or not", standard paths for libraries & includes (sadly, not everyone starts at /usr), and doubtless tons of other stuff is on its way. Does setup.cfg.in need to be resurrected? What do you think? ------------------------------------------------------- Date: 2001-Feb-06 14:54 By: akuchling Comment: This patch seems to be quite out of date now; it refers to setup.cfg.in which no longer exists. Perhaps setup.cfg.in needs to be resurrected. Donn, what's the current state of compiling alpha2 (or the CVS tree) on BeOS? Can you provide an updated version of this patch? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103487&group_id=5470 From noreply@sourceforge.net Thu Feb 8 12:49:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 04:49:45 -0800 Subject: [Patches] [Patch #103683] Alternative dll version resources (also fixes Bug 13122) Message-ID: Patch #103683 has been updated. Project: python Category: Windows Status: Open Submitted by: lhudson Assigned to : nobody Summary: Alternative dll version resources (also fixes Bug 13122) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103683&group_id=5470 From noreply@sourceforge.net Thu Feb 8 13:01:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 05:01:49 -0800 Subject: [Patches] [Patch #103678] setup.py.in Message-ID: Patch #103678 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : nobody Summary: setup.py.in Follow-Ups: Date: 2001-Feb-08 05:01 By: lemburg Comment: Using setup.py.in is the wrong strategy here: you should consider placing the symbols into the generated Makefile or config.h and then have setup.py parse these files (the tools for this are all there in distutils). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103678&group_id=5470 From noreply@sourceforge.net Thu Feb 8 14:37:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 06:37:59 -0800 Subject: [Patches] [Patch #103685] Printing unicode Message-ID: Patch #103685 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nobody Assigned to : nobody Summary: Printing unicode ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103685&group_id=5470 From info@fotoasia.com Thu Feb 8 23:52:16 2001 From: info@fotoasia.com (Farah Cowan) Date: Thu, 8 Feb 2001 23:52:16 -0000 Subject: [Patches] 30,000 Exclusive Images of Asia Message-ID: <200102081551.f18FpD809937@roam2.singnet.com.sg> Dear Sirs, Here's how you can have access to more than 30,000 exclusive images of Asia in 4 easy steps: Step One: Go to www.FotoAsia.com Step Two: Browse or search for images by keywords Step Three: Pay through credit cards via secure transactions Step Four: Download the image/s ....and voila! you are done. If you are targeting the Asian market, we can offer you royalty-free Asian images for your creative and publishing needs at competitive prices, from as low as US$30.00. Need a catalog? Just go to www.FotoAsia.com and download our FREE e-Catalogs and browse at your own convenience. Can't find an image you need? Send us an e-mail sales@FotoAsia.com and we will be glad to do a FREE search for you! Thank you. Ms Farah Cowan Chief Marketing Officer FotoAsia Pte Ltd 11 Kallang Place #02-08 Singapore 339155 Tel: 65-398-1373 Fax: 65-398-1393 www.FotoAsia.com sales@FotoAsia.com FotoAsia - T h e h e a r t a n d S o u l o f A s i a Removal ********** We have reason to believe that this mail would be of interest to you. If not, please accept our apologies for the intrusion. Kindly reply to this email info@FotoAsia.com with "REMOVE" in subject heading and you will not receive any further mailings from us. Thank you. From noreply@sourceforge.net Thu Feb 8 16:02:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 08:02:41 -0800 Subject: [Patches] [Patch #103685] Printing unicode Message-ID: Patch #103685 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nobody Assigned to : lemburg Summary: Printing unicode Follow-Ups: Date: 2001-Feb-08 08:02 By: lemburg Comment: I don't remember the details, but there was a discussion about this problem on python-dev. The outcome was to let Unicode objects pass through as-is to the file object and then have it apply whatever conversion it takes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103685&group_id=5470 From noreply@sourceforge.net Thu Feb 8 16:33:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 08:33:24 -0800 Subject: [Patches] [Patch #101647] adds SSL server socket support to socketmodule.c Message-ID: Patch #101647 has been updated. Project: python Category: Modules Status: Open Submitted by: drew_csillag Assigned to : gvanrossum Summary: adds SSL server socket support to socketmodule.c Follow-Ups: Date: 2001-Feb-08 08:33 By: akuchling Comment: Drew provided instructions for creating a test key and certificate, but I couldn't make them work. Given that: * this SSL support is undocumented * it seems difficult to make it work * OpenSSL is a big API, and only very basic support is in socketmodule.c * M2Crypto already exists, and offers more complete support. I'd suggest dropping SSL support from 2.1. Reassigning to GvR; I can't test this code if I can't even make a client connection work! ------------------------------------------------------- Date: 2001-Jan-24 19:04 By: akuchling Comment: newServerSSLObject() is a near-duplicate of newSSLobject(). Rather than just cut-and-paste the code into a new function, newSSLobject() should take a fourth argument, and perform either the client or server initialization. I've already modified the patch to do this. Before uploading the modified version, I'd like to test it, but can't figure out what it wants for the key and cert arguments. Drew, do you have a test program you used to test the code? Can you please e-mail it to me, or add it as a comment to this patch? ------------------------------------------------------- Date: 2001-Jan-24 12:05 By: gvanrossum Comment: OK, Andrew, it's all yours. (But I disagree with your last point: client-only SSL support is still a lot better than no SSL support! :-) ------------------------------------------------------- Date: 2001-Jan-24 11:24 By: akuchling Comment: Guido, want me to re-open this patch and take it over? IMHO, if the SSL support is left in, then this patch should be added; no point in having only half-working support. ------------------------------------------------------- Date: 2001-Jan-24 11:06 By: drew_csillag Comment: Sorry for the no-reply... Anyhoo, the ssl stuff currently in the socket module only allows ssl on client connections (i.e. where you connect to somebody else) as opposed to server connections (i.e. where somebody connects to you). For example, you have a cheesy SSL socket client: from socket import * s = socket(AF_INET, SOCK_STREAM) s.connect(('',9999)) ss = ssl(s,None,None) ss.write("foo!\n") The patch is required in order to be able to write the corresponding server, as such: from socket import * s = socket(AF_INET, SOCK_STREAM) s.bind(('',9999)) s.listen(5) f,a = s.accept() ss = sslserv(f, "keyfilename", "certfilename") print ss.read(5) If you try to just use the ssl function on both sides and it doesn't work. ------------------------------------------------------- Date: 2000-Sep-25 09:41 By: jhylton Comment: too late for 2.0 ------------------------------------------------------- Date: 2000-Sep-27 03:51 By: naris Comment: too late ? this patch solves world hunger and brings world peace! such a valuable patch, but i guess deadlines are deadlines :-( ------------------------------------------------------- Date: 2000-Oct-25 13:54 By: gvanrossum Comment: Drew, could you provide an example of how this is used? If I can't test it I can't add it. It doesn't have to be a test module (although a test module for all the SSL support is sorely needed) but I would like to see a little motivation for why this is useful. Also note that the SSL support in the socket module is controversial; there are some who believe that a different approach is needed, e.g. based on M2crypto. ------------------------------------------------------- Date: 2000-Nov-13 11:41 By: gvanrossum Comment: Still no reply. I'll reject the patch now, for lack of sufficient motivation. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101647&group_id=5470 From noreply@sourceforge.net Thu Feb 8 16:38:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 08:38:05 -0800 Subject: [Patches] [Patch #103678] setup.py.in Message-ID: Patch #103678 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : akuchling Summary: setup.py.in Follow-Ups: Date: 2001-Feb-08 08:38 By: akuchling Comment: Agreed; generating Makefiles from the configure script is bad enough, and generating executable scripts is worse still. Reintroducing setup.cfg.in would be better, if that proves necessary. ------------------------------------------------------- Date: 2001-Feb-08 05:01 By: lemburg Comment: Using setup.py.in is the wrong strategy here: you should consider placing the symbols into the generated Makefile or config.h and then have setup.py parse these files (the tools for this are all there in distutils). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103678&group_id=5470 From noreply@sourceforge.net Thu Feb 8 16:38:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 08:38:29 -0800 Subject: [Patches] [Patch #103487] BeOS build scripts, setup.py Message-ID: Patch #103487 has been updated. Project: python Category: Build Status: Closed Submitted by: donnc Assigned to : akuchling Summary: BeOS build scripts, setup.py Follow-Ups: Date: 2001-Feb-08 08:38 By: akuchling Comment: Closing as per Donn's comment. ------------------------------------------------------- Date: 2001-Feb-07 23:25 By: donnc Comment: OK, please close it! Mr. Kuchling, you can follow your particular interest in this patch in 103678. The rest of the BeOS and AIX mess moves to 103679. ------------------------------------------------------- Date: 2001-Feb-06 19:22 By: donnc Comment: The a2 Makefile scheme will make things simpler, but the problems addressed by the patch are still there. I can make another revision for a2, maybe tomorrow after working out an AIX build with separate read-only source directory. A lot of the design here is hardly more than personal preference - do you want setup.py to have a lot of "if platform == 'Darwin1.2' ... if platform[:4] == 'beos' ... "? Or should that go in the configure script? - that's what I think, but it's really up to whoever has to maintain this system. Issues are "what modules to try to build", "-lm or not", standard paths for libraries & includes (sadly, not everyone starts at /usr), and doubtless tons of other stuff is on its way. Does setup.cfg.in need to be resurrected? What do you think? ------------------------------------------------------- Date: 2001-Feb-06 14:54 By: akuchling Comment: This patch seems to be quite out of date now; it refers to setup.cfg.in which no longer exists. Perhaps setup.cfg.in needs to be resurrected. Donn, what's the current state of compiling alpha2 (or the CVS tree) on BeOS? Can you provide an updated version of this patch? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103487&group_id=5470 From noreply@sourceforge.net Thu Feb 8 16:49:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 08:49:15 -0800 Subject: [Patches] [Patch #103687] Several improvements for bdist_wininst Message-ID: Patch #103687 has been updated. Project: python Category: distutils Status: Open Submitted by: theller Assigned to : nobody Summary: Several improvements for bdist_wininst ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103687&group_id=5470 From noreply@sourceforge.net Thu Feb 8 16:51:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 08:51:18 -0800 Subject: [Patches] [Patch #103687] Several improvements for bdist_wininst Message-ID: Patch #103687 has been updated. Project: python Category: distutils Status: Open Submitted by: theller Assigned to : akuchling Summary: Several improvements for bdist_wininst Follow-Ups: Date: 2001-Feb-08 08:51 By: theller Comment: Assigned to Andrew because he wanted to review this. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103687&group_id=5470 From noreply@sourceforge.net Thu Feb 8 18:12:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 10:12:08 -0800 Subject: [Patches] [Patch #103678] setup.py.in Message-ID: Patch #103678 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : akuchling Summary: setup.py.in Follow-Ups: Date: 2001-Feb-08 10:12 By: donnc Comment: That's OK with me, all I need is a place where I can deal with platform specific issues, and it doesn't matter a bit to me where. setup.py.in, Makefile, setup.cfg, write the stuff right into setup.py (e.g., if platform == 'Darwin'). What do you like? ------------------------------------------------------- Date: 2001-Feb-08 08:38 By: akuchling Comment: Agreed; generating Makefiles from the configure script is bad enough, and generating executable scripts is worse still. Reintroducing setup.cfg.in would be better, if that proves necessary. ------------------------------------------------------- Date: 2001-Feb-08 05:01 By: lemburg Comment: Using setup.py.in is the wrong strategy here: you should consider placing the symbols into the generated Makefile or config.h and then have setup.py parse these files (the tools for this are all there in distutils). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103678&group_id=5470 From noreply@sourceforge.net Thu Feb 8 18:29:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 10:29:15 -0800 Subject: [Patches] [Patch #103678] setup.py.in Message-ID: Patch #103678 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : akuchling Summary: setup.py.in Follow-Ups: Date: 2001-Feb-08 10:29 By: lemburg Comment: I'd prefer if you'd put all the code into setup.py -- the tools are all there. If you need extra symbols, then have configure place them in the Makefile or config.h. Both are available for distutils to use. Platform specifica can then be dealt with under Python's control which gives you much more power and flexibility. ------------------------------------------------------- Date: 2001-Feb-08 10:12 By: donnc Comment: That's OK with me, all I need is a place where I can deal with platform specific issues, and it doesn't matter a bit to me where. setup.py.in, Makefile, setup.cfg, write the stuff right into setup.py (e.g., if platform == 'Darwin'). What do you like? ------------------------------------------------------- Date: 2001-Feb-08 08:38 By: akuchling Comment: Agreed; generating Makefiles from the configure script is bad enough, and generating executable scripts is worse still. Reintroducing setup.cfg.in would be better, if that proves necessary. ------------------------------------------------------- Date: 2001-Feb-08 05:01 By: lemburg Comment: Using setup.py.in is the wrong strategy here: you should consider placing the symbols into the generated Makefile or config.h and then have setup.py parse these files (the tools for this are all there in distutils). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103678&group_id=5470 From noreply@sourceforge.net Thu Feb 8 18:45:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 10:45:36 -0800 Subject: [Patches] [Patch #103678] setup.py.in Message-ID: Patch #103678 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : akuchling Summary: setup.py.in Follow-Ups: Date: 2001-Feb-08 10:45 By: nascheme Comment: One more reason for not using step.py.in or setup.cfg.in: The Makefile is available to distutils when building extension modules after the source is gone (ie. its installed in lib). ------------------------------------------------------- Date: 2001-Feb-08 10:29 By: lemburg Comment: I'd prefer if you'd put all the code into setup.py -- the tools are all there. If you need extra symbols, then have configure place them in the Makefile or config.h. Both are available for distutils to use. Platform specifica can then be dealt with under Python's control which gives you much more power and flexibility. ------------------------------------------------------- Date: 2001-Feb-08 10:12 By: donnc Comment: That's OK with me, all I need is a place where I can deal with platform specific issues, and it doesn't matter a bit to me where. setup.py.in, Makefile, setup.cfg, write the stuff right into setup.py (e.g., if platform == 'Darwin'). What do you like? ------------------------------------------------------- Date: 2001-Feb-08 08:38 By: akuchling Comment: Agreed; generating Makefiles from the configure script is bad enough, and generating executable scripts is worse still. Reintroducing setup.cfg.in would be better, if that proves necessary. ------------------------------------------------------- Date: 2001-Feb-08 05:01 By: lemburg Comment: Using setup.py.in is the wrong strategy here: you should consider placing the symbols into the generated Makefile or config.h and then have setup.py parse these files (the tools for this are all there in distutils). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103678&group_id=5470 From noreply@sourceforge.net Thu Feb 8 19:16:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 11:16:52 -0800 Subject: [Patches] [Patch #103678] setup.py.in Message-ID: Patch #103678 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : akuchling Summary: setup.py.in Follow-Ups: Date: 2001-Feb-08 11:16 By: donnc Comment: I would be happy with extra symbols in Makefile, for setup.py to use. I think this system will be somewhat obscure for someone trying to figure out how to make a build work, so some pointer comments at the top of setup.py would be good. The last point there is not so clear to me -- it sounds like there's an intent to move a lot of logic from "configure" to setup.py. I look forward to seeing whether that does give us much more power and flexibility. It will put some pressure on the Python code base, though - I already have changes in for distutils and even os.py, to get through the build, not to mention the two unsuccessful attempts to get changes into setup.py. In 2.0, I came along pretty late in the beta with changes that make it build for BeOS. Here I am right at the beginning of 2.1 alpha, but the hurdle seems a lot higher. ------------------------------------------------------- Date: 2001-Feb-08 10:45 By: nascheme Comment: One more reason for not using step.py.in or setup.cfg.in: The Makefile is available to distutils when building extension modules after the source is gone (ie. its installed in lib). ------------------------------------------------------- Date: 2001-Feb-08 10:29 By: lemburg Comment: I'd prefer if you'd put all the code into setup.py -- the tools are all there. If you need extra symbols, then have configure place them in the Makefile or config.h. Both are available for distutils to use. Platform specifica can then be dealt with under Python's control which gives you much more power and flexibility. ------------------------------------------------------- Date: 2001-Feb-08 10:12 By: donnc Comment: That's OK with me, all I need is a place where I can deal with platform specific issues, and it doesn't matter a bit to me where. setup.py.in, Makefile, setup.cfg, write the stuff right into setup.py (e.g., if platform == 'Darwin'). What do you like? ------------------------------------------------------- Date: 2001-Feb-08 08:38 By: akuchling Comment: Agreed; generating Makefiles from the configure script is bad enough, and generating executable scripts is worse still. Reintroducing setup.cfg.in would be better, if that proves necessary. ------------------------------------------------------- Date: 2001-Feb-08 05:01 By: lemburg Comment: Using setup.py.in is the wrong strategy here: you should consider placing the symbols into the generated Makefile or config.h and then have setup.py parse these files (the tools for this are all there in distutils). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103678&group_id=5470 From noreply@sourceforge.net Thu Feb 8 22:05:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 14:05:28 -0800 Subject: [Patches] [Patch #103693] tupleobject.c: implement tuple.index() and tuple.count() Message-ID: Patch #103693 has been updated. Project: python Category: core (C code) Status: Open Submitted by: mfx Assigned to : nobody Summary: tupleobject.c: implement tuple.index() and tuple.count() ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103693&group_id=5470 From noreply@sourceforge.net Thu Feb 8 22:51:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 14:51:40 -0800 Subject: [Patches] [Patch #103678] setup.py.in Message-ID: Patch #103678 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : akuchling Summary: setup.py.in Follow-Ups: Date: 2001-Feb-08 14:51 By: lemburg Comment: Na, it's not higher, only in this case, the design is going in the wrong direction. The new setup.py mechanism was meant to allow as much automatic configuration as possible (previously people had to edit Modules/Setup which was not difficult, but obscure enough to keep people from enabling important add-ons such as Tkinter). Now with the setup.py auto-detection mechanisms in place, there should be much less user interaction required to get a fully functional system. As for the other patches: many of the Python core team are currently out of town so there's a natural delay there. Nothing to worry about though. ------------------------------------------------------- Date: 2001-Feb-08 11:16 By: donnc Comment: I would be happy with extra symbols in Makefile, for setup.py to use. I think this system will be somewhat obscure for someone trying to figure out how to make a build work, so some pointer comments at the top of setup.py would be good. The last point there is not so clear to me -- it sounds like there's an intent to move a lot of logic from "configure" to setup.py. I look forward to seeing whether that does give us much more power and flexibility. It will put some pressure on the Python code base, though - I already have changes in for distutils and even os.py, to get through the build, not to mention the two unsuccessful attempts to get changes into setup.py. In 2.0, I came along pretty late in the beta with changes that make it build for BeOS. Here I am right at the beginning of 2.1 alpha, but the hurdle seems a lot higher. ------------------------------------------------------- Date: 2001-Feb-08 10:45 By: nascheme Comment: One more reason for not using step.py.in or setup.cfg.in: The Makefile is available to distutils when building extension modules after the source is gone (ie. its installed in lib). ------------------------------------------------------- Date: 2001-Feb-08 10:29 By: lemburg Comment: I'd prefer if you'd put all the code into setup.py -- the tools are all there. If you need extra symbols, then have configure place them in the Makefile or config.h. Both are available for distutils to use. Platform specifica can then be dealt with under Python's control which gives you much more power and flexibility. ------------------------------------------------------- Date: 2001-Feb-08 10:12 By: donnc Comment: That's OK with me, all I need is a place where I can deal with platform specific issues, and it doesn't matter a bit to me where. setup.py.in, Makefile, setup.cfg, write the stuff right into setup.py (e.g., if platform == 'Darwin'). What do you like? ------------------------------------------------------- Date: 2001-Feb-08 08:38 By: akuchling Comment: Agreed; generating Makefiles from the configure script is bad enough, and generating executable scripts is worse still. Reintroducing setup.cfg.in would be better, if that proves necessary. ------------------------------------------------------- Date: 2001-Feb-08 05:01 By: lemburg Comment: Using setup.py.in is the wrong strategy here: you should consider placing the symbols into the generated Makefile or config.h and then have setup.py parse these files (the tools for this are all there in distutils). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103678&group_id=5470 From noreply@sourceforge.net Thu Feb 8 23:05:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 15:05:01 -0800 Subject: [Patches] [Patch #103694] fix makexp_aix path in configure.in Message-ID: Patch #103694 has been updated. Project: python Category: Build Status: Open Submitted by: bcollar Assigned to : nobody Summary: fix makexp_aix path in configure.in ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103694&group_id=5470 From noreply@sourceforge.net Thu Feb 8 23:12:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 15:12:53 -0800 Subject: [Patches] [Patch #103695] fix path to ld_so_aix Message-ID: Patch #103695 has been updated. Project: python Category: Build Status: Open Submitted by: bcollar Assigned to : nobody Summary: fix path to ld_so_aix ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103695&group_id=5470 From noreply@sourceforge.net Thu Feb 8 23:33:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 15:33:18 -0800 Subject: [Patches] [Patch #101137] Add raw packet support to socketmodule.c Message-ID: Patch #101137 has been updated. Project: python Category: Modules Status: Closed Submitted by: grante Assigned to : jhylton Summary: Add raw packet support to socketmodule.c Follow-Ups: Date: 2001-Feb-02 09:02 By: grante Comment: Sure -- I've got a small demo program. But, when cleaning up the demo program, I realized that I screwed-up and forgot to include the Ethernet address in the tuple returned by makesockaddr(). Since the user has to fill in the source Ethernet address when a frame is sent, he has to have access to the Ethernet address of the socket. I've made that change, and I've also gotten rid of the need to create a "spare" socket on which to do an interface name lookup. I added the socket file descriptor to the parameter list for makesockname as was suggested earlier. Q: should I revise this patch, or submit a new patch against sources that have already had this patch applied? ------------------------------------------------------- Date: 2001-Feb-01 19:23 By: jhylton Comment: checked in as rev 1.134 Grant-- Could you supply a short example that demonstrates how to use raw sockets? We can't really include the code in the test suite, since you need to be root to use them, but perhaps in the Demo directory. ------------------------------------------------------- Date: 2001-Jan-27 17:02 By: grante Comment: Revised patch: 1) fixed indentation style. 2) fixed possible strncpy buffer overrun. 3) fixed bug in getsockname. 4) exposed sll_pkttype and sll_hatype fields of sockaddr_ll struct (AFAICT, they're not useful). 5) changed conditional compilation so AF_PACKET stuff is only built under Linux. (patch is against 2.0) ------------------------------------------------------- Date: 2001-Jan-18 10:01 By: nobody Comment: Yes, I'm still interested in this patch. Winthin the next week or two I'll try to get a revised patch submitted that addresses some of the comments. Two things I can't do much about are: 1) I only have Linux systems for testing: I don't have root privledges on any other type of system. 2) Unless it is agreed to change parameters for makesockaddr, I can't do anything except create a temporary socket in order to look up the interface name. I suppose I could require user code to provide an interface index, but I don't really like that option since it diverges quite a bit from the "C" usage. ------------------------------------------------------- Date: 2001-Jan-18 09:39 By: jhylton Comment: Is Grant still interested in this patch? I don't have time to fix it myself, but I would be happy to look at it again if we comments and questions are addressed. ------------------------------------------------------- Date: 2000-Aug-09 14:49 By: grante Comment: Patch has only been tested on Linux: RH6.2 (Intel). Patch is against 1.6b1 ------------------------------------------------------- Date: 2000-Aug-15 15:15 By: tim_one Comment: Assigned to Barry, since he just volunteered to rewrite all of Python's socket code anyway . ------------------------------------------------------- Date: 2000-Aug-24 14:27 By: jhylton Comment: Not sure about this patch. It needs to be tested on more platforms than just Linux, but I don't see that we'll have time before 2.0. There are several other issues that must be resolved, too. Thus, this patch falls subject to the feature freeze. Style points: Indention is wrong. The opening curly brace of an if belongs on the same line as the test. Whitespace is required around = and after commas in argument lists. The strncpy in makesockaddr does not check the size of the source string. It could overflow the buffer. In makesockaddr, a new socket is created just to look up the interface name associated with a particular interface. This seems wasteful, particularly in cases where few file descriptors are available. I'm not sure what the solution is, although it might be to change the makesockaddr function so that it takes the socket itself. Perhaps that socket address for AF_PACKET should also accept and/or produce interface numbers which the client can convert to names manually. The sockaddr_ll has members ssl_hatype and ssl_pkttype, which are not made accessible by this patch. It seems like they should be, but I am not sure. Can you use SOCK_DGRAM without specifying the packet type? getsockaddrarg is handled, but getsockaddrlen is not. Question: Are there any other constants that should be added? This relates to the packet type question. * ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101137&group_id=5470 From noreply@sourceforge.net Thu Feb 8 23:33:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 15:33:41 -0800 Subject: [Patches] [Patch #103589] Fix segfault related to nested scopes Message-ID: Patch #103589 has been updated. Project: python Category: Parser/Compiler Status: Accepted Submitted by: nickm Assigned to : jhylton Summary: Fix segfault related to nested scopes Follow-Ups: Date: 2001-Feb-06 06:14 By: nickm Comment: Just to clarify, if this problem is fixed, the fix isn't in CVS. I can still induce a segfault with: def outer(*args): def inner(): print args outer(1,2,3) This patch fixes this problem. ------------------------------------------------------- Date: 2001-Feb-06 04:34 By: moshez Comment: assigning to Jeremy -- I think he fixed the problems Jeremy, I think this patch is no longer relevant. ------------------------------------------------------- Date: 2001-Feb-04 09:38 By: nickm Comment: Oops! That wasn't a context diff. This should be. ------------------------------------------------------- Date: 2001-Feb-04 07:22 By: nickm Comment: Improved patch; original patch modified unreleated code. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103589&group_id=5470 From noreply@sourceforge.net Thu Feb 8 23:43:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 15:43:03 -0800 Subject: [Patches] [Patch #103678] setup.py.in Message-ID: Patch #103678 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : akuchling Summary: setup.py.in Follow-Ups: Date: 2001-Feb-08 15:43 By: donnc Comment: Not worried, just was trying to point out the good side of a throw-away system for the dirty business of platform warts. Anyway, with all that stuff to get done in setup.py, obviously the release is a ways off yet. ------------------------------------------------------- Date: 2001-Feb-08 14:51 By: lemburg Comment: Na, it's not higher, only in this case, the design is going in the wrong direction. The new setup.py mechanism was meant to allow as much automatic configuration as possible (previously people had to edit Modules/Setup which was not difficult, but obscure enough to keep people from enabling important add-ons such as Tkinter). Now with the setup.py auto-detection mechanisms in place, there should be much less user interaction required to get a fully functional system. As for the other patches: many of the Python core team are currently out of town so there's a natural delay there. Nothing to worry about though. ------------------------------------------------------- Date: 2001-Feb-08 11:16 By: donnc Comment: I would be happy with extra symbols in Makefile, for setup.py to use. I think this system will be somewhat obscure for someone trying to figure out how to make a build work, so some pointer comments at the top of setup.py would be good. The last point there is not so clear to me -- it sounds like there's an intent to move a lot of logic from "configure" to setup.py. I look forward to seeing whether that does give us much more power and flexibility. It will put some pressure on the Python code base, though - I already have changes in for distutils and even os.py, to get through the build, not to mention the two unsuccessful attempts to get changes into setup.py. In 2.0, I came along pretty late in the beta with changes that make it build for BeOS. Here I am right at the beginning of 2.1 alpha, but the hurdle seems a lot higher. ------------------------------------------------------- Date: 2001-Feb-08 10:45 By: nascheme Comment: One more reason for not using step.py.in or setup.cfg.in: The Makefile is available to distutils when building extension modules after the source is gone (ie. its installed in lib). ------------------------------------------------------- Date: 2001-Feb-08 10:29 By: lemburg Comment: I'd prefer if you'd put all the code into setup.py -- the tools are all there. If you need extra symbols, then have configure place them in the Makefile or config.h. Both are available for distutils to use. Platform specifica can then be dealt with under Python's control which gives you much more power and flexibility. ------------------------------------------------------- Date: 2001-Feb-08 10:12 By: donnc Comment: That's OK with me, all I need is a place where I can deal with platform specific issues, and it doesn't matter a bit to me where. setup.py.in, Makefile, setup.cfg, write the stuff right into setup.py (e.g., if platform == 'Darwin'). What do you like? ------------------------------------------------------- Date: 2001-Feb-08 08:38 By: akuchling Comment: Agreed; generating Makefiles from the configure script is bad enough, and generating executable scripts is worse still. Reintroducing setup.cfg.in would be better, if that proves necessary. ------------------------------------------------------- Date: 2001-Feb-08 05:01 By: lemburg Comment: Using setup.py.in is the wrong strategy here: you should consider placing the symbols into the generated Makefile or config.h and then have setup.py parse these files (the tools for this are all there in distutils). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103678&group_id=5470 From noreply@sourceforge.net Fri Feb 9 02:21:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 18:21:12 -0800 Subject: [Patches] [Patch #103589] Fix segfault related to nested scopes Message-ID: Patch #103589 has been updated. Project: python Category: Parser/Compiler Status: Accepted Submitted by: nickm Assigned to : jhylton Summary: Fix segfault related to nested scopes Follow-Ups: Date: 2001-Feb-08 18:21 By: gvanrossum Comment: I agree with the poster, this is not fixed in CVS. Note that the example is wrong: it only fails if you actually *call* the inner function. To the poster: your diffs are malformed. Did you use cut-and-paste to upload the diff? It seems some lines are missing. Please save the diff to a file and use file upload (don't forget to click the "Upload Revised Patch" checkbox! ------------------------------------------------------- Date: 2001-Feb-06 06:14 By: nickm Comment: Just to clarify, if this problem is fixed, the fix isn't in CVS. I can still induce a segfault with: def outer(*args): def inner(): print args outer(1,2,3) This patch fixes this problem. ------------------------------------------------------- Date: 2001-Feb-06 04:34 By: moshez Comment: assigning to Jeremy -- I think he fixed the problems Jeremy, I think this patch is no longer relevant. ------------------------------------------------------- Date: 2001-Feb-04 09:38 By: nickm Comment: Oops! That wasn't a context diff. This should be. ------------------------------------------------------- Date: 2001-Feb-04 07:22 By: nickm Comment: Improved patch; original patch modified unreleated code. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103589&group_id=5470 From noreply@sourceforge.net Fri Feb 9 05:52:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 21:52:31 -0800 Subject: [Patches] [Patch #103589] Fix segfault related to nested scopes Message-ID: Patch #103589 has been updated. Project: python Category: Parser/Compiler Status: Accepted Submitted by: nickm Assigned to : jhylton Summary: Fix segfault related to nested scopes Follow-Ups: Date: 2001-Feb-08 21:52 By: nickm Comment: My apologies; Guido is correct about the example and the patch. This patch should work against the latest CVS version. Again, it includes test cases for the cases it fixes. ------------------------------------------------------- Date: 2001-Feb-08 18:21 By: gvanrossum Comment: I agree with the poster, this is not fixed in CVS. Note that the example is wrong: it only fails if you actually *call* the inner function. To the poster: your diffs are malformed. Did you use cut-and-paste to upload the diff? It seems some lines are missing. Please save the diff to a file and use file upload (don't forget to click the "Upload Revised Patch" checkbox! ------------------------------------------------------- Date: 2001-Feb-06 06:14 By: nickm Comment: Just to clarify, if this problem is fixed, the fix isn't in CVS. I can still induce a segfault with: def outer(*args): def inner(): print args outer(1,2,3) This patch fixes this problem. ------------------------------------------------------- Date: 2001-Feb-06 04:34 By: moshez Comment: assigning to Jeremy -- I think he fixed the problems Jeremy, I think this patch is no longer relevant. ------------------------------------------------------- Date: 2001-Feb-04 09:38 By: nickm Comment: Oops! That wasn't a context diff. This should be. ------------------------------------------------------- Date: 2001-Feb-04 07:22 By: nickm Comment: Improved patch; original patch modified unreleated code. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103589&group_id=5470 From noreply@sourceforge.net Fri Feb 9 06:08:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 22:08:56 -0800 Subject: [Patches] [Patch #103589] Fix segfault related to nested scopes Message-ID: Patch #103589 has been updated. Project: python Category: Parser/Compiler Status: Open Submitted by: nickm Assigned to : jhylton Summary: Fix segfault related to nested scopes Follow-Ups: Date: 2001-Feb-08 22:08 By: gvanrossum Comment: Thanks, that's much better. It seems to work for me, but I'll leave it open for Jeremy so he can proofread it! ------------------------------------------------------- Date: 2001-Feb-08 21:52 By: nickm Comment: My apologies; Guido is correct about the example and the patch. This patch should work against the latest CVS version. Again, it includes test cases for the cases it fixes. ------------------------------------------------------- Date: 2001-Feb-08 18:21 By: gvanrossum Comment: I agree with the poster, this is not fixed in CVS. Note that the example is wrong: it only fails if you actually *call* the inner function. To the poster: your diffs are malformed. Did you use cut-and-paste to upload the diff? It seems some lines are missing. Please save the diff to a file and use file upload (don't forget to click the "Upload Revised Patch" checkbox! ------------------------------------------------------- Date: 2001-Feb-06 06:14 By: nickm Comment: Just to clarify, if this problem is fixed, the fix isn't in CVS. I can still induce a segfault with: def outer(*args): def inner(): print args outer(1,2,3) This patch fixes this problem. ------------------------------------------------------- Date: 2001-Feb-06 04:34 By: moshez Comment: assigning to Jeremy -- I think he fixed the problems Jeremy, I think this patch is no longer relevant. ------------------------------------------------------- Date: 2001-Feb-04 09:38 By: nickm Comment: Oops! That wasn't a context diff. This should be. ------------------------------------------------------- Date: 2001-Feb-04 07:22 By: nickm Comment: Improved patch; original patch modified unreleated code. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103589&group_id=5470 From noreply@sourceforge.net Fri Feb 9 07:02:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 23:02:25 -0800 Subject: [Patches] [Patch #103703] Fix for Tools\compiler\transformer.py and renaming Message-ID: Patch #103703 has been updated. Project: python Category: library Status: Open Submitted by: bquinlan Assigned to : nobody Summary: Fix for Tools\compiler\transformer.py and renaming ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103703&group_id=5470 From noreply@sourceforge.net Fri Feb 9 07:05:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 23:05:27 -0800 Subject: [Patches] [Patch #103683] Alternative dll version resources (also fixes Bug 13122) Message-ID: Patch #103683 has been updated. Project: python Category: Windows Status: Closed Submitted by: lhudson Assigned to : tim_one Summary: Alternative dll version resources (also fixes Bug 13122) Follow-Ups: Date: 2001-Feb-08 23:05 By: tim_one Comment: Checked in similar patch, PC/python_nt.rc rev 1.12, ACKS rev 1.79. Checkin comment: SF bug #131225: sys.winver is still '2.0' in python 2.1a2. SF patch #103683: Alternative dll version resources. Changes similar to the patch. MarkH should review. File version and Product version text strings now 2.1a2. 64-bit file and product version numbers are now PY_MAJOR_VERSION, PY_MINOR_VERSION, messy, PYTHON_API_VERSION where messy = PY_MICRO_VERSION*1000 + PY_RELEASE_LEVEL*10 + PY_RELEASE_SERIAL Updated company name to "Digital Creations 2". Copyright now lists Guido; "C in a circle" symbol used instead of (C). Comments added so this is less likely to get flubbed again, and #if/#error guys added to trigger if the version number manipulations above overflow. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103683&group_id=5470 From noreply@sourceforge.net Fri Feb 9 07:09:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Feb 2001 23:09:43 -0800 Subject: [Patches] [Patch #102453] Modified urlencode in urllib to accept more types Message-ID: Patch #102453 has been updated. Project: python Category: library Status: Open Submitted by: nobody Assigned to : jhylton Summary: Modified urlencode in urllib to accept more types Follow-Ups: Date: 2001-Feb-08 23:09 By: bquinlan Comment: This patch has been superceeded and should be closed. ------------------------------------------------------- Date: 2001-Jan-04 07:47 By: gvanrossum Comment: This is a reasonable idea. Jeremy, if you have a minute, can you review this? ------------------------------------------------------- Date: 2000-Nov-21 03:18 By: moshez Comment: It looks good, except for accepting tuples: that's, IMHO, unneeded featurism. If it is accepted, here are docs: (replace the current docs for urlencode by:) \begin{funcdesc}{urlencode}{data} Convert a list of 2-tuples or a dictionary (treated as a list of (key, value) 2-tuples) to a ``url-encoded'' string, suitable to pass to \function{urlopen()} above as the optional \var{data} argument. This is useful to pass a dictionary of form fields to a \code{POST} request. The resulting string is a series of \code{\var{key}=\var{value}} pairs separated by \character{\&} characters, where both \var{key} and \var{value} are quoted using \function{quote_plus()} above. \end{funcdesc} Assigning to Jeremy 'cause he seems the urllib guy ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102453&group_id=5470 From noreply@sourceforge.net Fri Feb 9 09:56:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Feb 2001 01:56:54 -0800 Subject: [Patches] [Patch #103695] fix path to ld_so_aix Message-ID: Patch #103695 has been updated. Project: python Category: Build Status: Closed Submitted by: bcollar Assigned to : lemburg Summary: fix path to ld_so_aix Follow-Ups: Date: 2001-Feb-09 01:56 By: lemburg Comment: Checked in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103695&group_id=5470 From noreply@sourceforge.net Fri Feb 9 09:56:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Feb 2001 01:56:48 -0800 Subject: [Patches] [Patch #103694] fix makexp_aix path in configure.in Message-ID: Patch #103694 has been updated. Project: python Category: Build Status: Closed Submitted by: bcollar Assigned to : lemburg Summary: fix makexp_aix path in configure.in Follow-Ups: Date: 2001-Feb-09 01:56 By: lemburg Comment: Checked in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103694&group_id=5470 From noreply@sourceforge.net Fri Feb 9 12:02:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Feb 2001 04:02:14 -0800 Subject: [Patches] [Patch #103685] Printing unicode Message-ID: Patch #103685 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nobody Assigned to : lemburg Summary: Printing unicode Follow-Ups: Date: 2001-Feb-09 04:02 By: nobody Comment: I hadnt seen that original discussion, and cant find it in the archives now :-( However, your summary matches exactly what this patch achieves for files have __str_before_write__=0 I think we have to require this extra flag to enable the new behaviour. For example, this prevents breakage of old code that prints to a StringIO instance. (Toby Dickenson, tdickenson@geminidataloggers.com) ------------------------------------------------------- Date: 2001-Feb-08 08:02 By: lemburg Comment: I don't remember the details, but there was a discussion about this problem on python-dev. The outcome was to let Unicode objects pass through as-is to the file object and then have it apply whatever conversion it takes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103685&group_id=5470 From noreply@sourceforge.net Fri Feb 9 12:26:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Feb 2001 04:26:45 -0800 Subject: [Patches] [Patch #103710] Change PyImport_ImportModule semantics to call __import__ Message-ID: Patch #103710 has been updated. Project: python Category: core (C code) Status: Open Submitted by: theller Assigned to : nobody Summary: Change PyImport_ImportModule semantics to call __import__ ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103710&group_id=5470 From noreply@sourceforge.net Fri Feb 9 12:54:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Feb 2001 04:54:21 -0800 Subject: [Patches] [Patch #103685] Printing unicode Message-ID: Patch #103685 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nobody Assigned to : lemburg Summary: Printing unicode Follow-Ups: Date: 2001-Feb-09 04:54 By: nobody Comment: waaah - without https I cant upload a new version of the patch. The original patch fails to clear the exception if getattr('__str__before_write__') fails... that inner part of PyFile_WriteObject needs to be: stringize = PyObject_GetAttrString(f, "__str_before_write__"); if(!stringize) PyErr_Clear(); if(!stringize || PyObject_IsTrue(stringize)) value = PyObject_Str(v); else { Py_INCREF(v); value = v; } my appologies for the extra trouble. ------------------------------------------------------- Date: 2001-Feb-09 04:02 By: nobody Comment: I hadnt seen that original discussion, and cant find it in the archives now :-( However, your summary matches exactly what this patch achieves for files have __str_before_write__=0 I think we have to require this extra flag to enable the new behaviour. For example, this prevents breakage of old code that prints to a StringIO instance. (Toby Dickenson, tdickenson@geminidataloggers.com) ------------------------------------------------------- Date: 2001-Feb-08 08:02 By: lemburg Comment: I don't remember the details, but there was a discussion about this problem on python-dev. The outcome was to let Unicode objects pass through as-is to the file object and then have it apply whatever conversion it takes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103685&group_id=5470 From noreply@sourceforge.net Fri Feb 9 13:23:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Feb 2001 05:23:07 -0800 Subject: [Patches] [Patch #103710] Change PyImport_ImportModule semantics to call __import__ Message-ID: Patch #103710 has been updated. Project: python Category: core (C code) Status: Open Submitted by: theller Assigned to : nobody Summary: Change PyImport_ImportModule semantics to call __import__ Follow-Ups: Date: 2001-Feb-09 05:23 By: theller Comment: There was a refcount bug in the first version of this patch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103710&group_id=5470 From noreply@sourceforge.net Fri Feb 9 13:45:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Feb 2001 05:45:08 -0800 Subject: [Patches] [Patch #103685] Printing unicode Message-ID: Patch #103685 has been updated. Project: python Category: core (C code) Status: Open Submitted by: nobody Assigned to : lemburg Summary: Printing unicode Follow-Ups: Date: 2001-Feb-09 05:45 By: lemburg Comment: I'd rather break some code here and then get this done right once and for all. I wouldn't want to carry along a special attribute which needs to be checked before every .write() operation. This costs performance and adds unnecessary convolution to the file API. Since Unicode is still very new, I doubt that the impact of this will cause people too much trouble. IMHO, the correct way to deal with this is to let the file object write methods deal with the problem in an application specific way. cStringIO.c (and all other file-like objects) should be fixed to use the s# parser markers instead of requiring a real string object. This will also enhance interoperability with other data storage types. ------------------------------------------------------- Date: 2001-Feb-09 04:54 By: nobody Comment: waaah - without https I cant upload a new version of the patch. The original patch fails to clear the exception if getattr('__str__before_write__') fails... that inner part of PyFile_WriteObject needs to be: stringize = PyObject_GetAttrString(f, "__str_before_write__"); if(!stringize) PyErr_Clear(); if(!stringize || PyObject_IsTrue(stringize)) value = PyObject_Str(v); else { Py_INCREF(v); value = v; } my appologies for the extra trouble. ------------------------------------------------------- Date: 2001-Feb-09 04:02 By: nobody Comment: I hadnt seen that original discussion, and cant find it in the archives now :-( However, your summary matches exactly what this patch achieves for files have __str_before_write__=0 I think we have to require this extra flag to enable the new behaviour. For example, this prevents breakage of old code that prints to a StringIO instance. (Toby Dickenson, tdickenson@geminidataloggers.com) ------------------------------------------------------- Date: 2001-Feb-08 08:02 By: lemburg Comment: I don't remember the details, but there was a discussion about this problem on python-dev. The outcome was to let Unicode objects pass through as-is to the file object and then have it apply whatever conversion it takes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103685&group_id=5470 From noreply@sourceforge.net Fri Feb 9 14:56:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Feb 2001 06:56:33 -0800 Subject: [Patches] [Patch #101647] adds SSL server socket support to socketmodule.c Message-ID: Patch #101647 has been updated. Project: python Category: Modules Status: Rejected Submitted by: drew_csillag Assigned to : gvanrossum Summary: adds SSL server socket support to socketmodule.c Follow-Ups: Date: 2001-Feb-09 06:56 By: gvanrossum Comment: Rejected. Drew agrees after re-educating himself about M2Crypto. ------------------------------------------------------- Date: 2001-Feb-08 08:33 By: akuchling Comment: Drew provided instructions for creating a test key and certificate, but I couldn't make them work. Given that: * this SSL support is undocumented * it seems difficult to make it work * OpenSSL is a big API, and only very basic support is in socketmodule.c * M2Crypto already exists, and offers more complete support. I'd suggest dropping SSL support from 2.1. Reassigning to GvR; I can't test this code if I can't even make a client connection work! ------------------------------------------------------- Date: 2001-Jan-24 19:04 By: akuchling Comment: newServerSSLObject() is a near-duplicate of newSSLobject(). Rather than just cut-and-paste the code into a new function, newSSLobject() should take a fourth argument, and perform either the client or server initialization. I've already modified the patch to do this. Before uploading the modified version, I'd like to test it, but can't figure out what it wants for the key and cert arguments. Drew, do you have a test program you used to test the code? Can you please e-mail it to me, or add it as a comment to this patch? ------------------------------------------------------- Date: 2001-Jan-24 12:05 By: gvanrossum Comment: OK, Andrew, it's all yours. (But I disagree with your last point: client-only SSL support is still a lot better than no SSL support! :-) ------------------------------------------------------- Date: 2001-Jan-24 11:24 By: akuchling Comment: Guido, want me to re-open this patch and take it over? IMHO, if the SSL support is left in, then this patch should be added; no point in having only half-working support. ------------------------------------------------------- Date: 2001-Jan-24 11:06 By: drew_csillag Comment: Sorry for the no-reply... Anyhoo, the ssl stuff currently in the socket module only allows ssl on client connections (i.e. where you connect to somebody else) as opposed to server connections (i.e. where somebody connects to you). For example, you have a cheesy SSL socket client: from socket import * s = socket(AF_INET, SOCK_STREAM) s.connect(('',9999)) ss = ssl(s,None,None) ss.write("foo!\n") The patch is required in order to be able to write the corresponding server, as such: from socket import * s = socket(AF_INET, SOCK_STREAM) s.bind(('',9999)) s.listen(5) f,a = s.accept() ss = sslserv(f, "keyfilename", "certfilename") print ss.read(5) If you try to just use the ssl function on both sides and it doesn't work. ------------------------------------------------------- Date: 2000-Sep-25 09:41 By: jhylton Comment: too late for 2.0 ------------------------------------------------------- Date: 2000-Sep-27 03:51 By: naris Comment: too late ? this patch solves world hunger and brings world peace! such a valuable patch, but i guess deadlines are deadlines :-( ------------------------------------------------------- Date: 2000-Oct-25 13:54 By: gvanrossum Comment: Drew, could you provide an example of how this is used? If I can't test it I can't add it. It doesn't have to be a test module (although a test module for all the SSL support is sorely needed) but I would like to see a little motivation for why this is useful. Also note that the SSL support in the socket module is controversial; there are some who believe that a different approach is needed, e.g. based on M2crypto. ------------------------------------------------------- Date: 2000-Nov-13 11:41 By: gvanrossum Comment: Still no reply. I'll reject the patch now, for lack of sufficient motivation. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101647&group_id=5470 From noreply@sourceforge.net Fri Feb 9 15:00:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Feb 2001 07:00:15 -0800 Subject: [Patches] [Patch #103589] Fix segfault related to nested scopes Message-ID: Patch #103589 has been updated. Project: python Category: Parser/Compiler Status: Open Submitted by: nickm Assigned to : jhylton Summary: Fix segfault related to nested scopes Follow-Ups: Date: 2001-Feb-09 07:00 By: gvanrossum Comment: Jeremy, please note that the addition to test_scope.py mixes tabs and spaces, which will make the test suite fail. Easy to fix of course... ------------------------------------------------------- Date: 2001-Feb-08 22:08 By: gvanrossum Comment: Thanks, that's much better. It seems to work for me, but I'll leave it open for Jeremy so he can proofread it! ------------------------------------------------------- Date: 2001-Feb-08 21:52 By: nickm Comment: My apologies; Guido is correct about the example and the patch. This patch should work against the latest CVS version. Again, it includes test cases for the cases it fixes. ------------------------------------------------------- Date: 2001-Feb-08 18:21 By: gvanrossum Comment: I agree with the poster, this is not fixed in CVS. Note that the example is wrong: it only fails if you actually *call* the inner function. To the poster: your diffs are malformed. Did you use cut-and-paste to upload the diff? It seems some lines are missing. Please save the diff to a file and use file upload (don't forget to click the "Upload Revised Patch" checkbox! ------------------------------------------------------- Date: 2001-Feb-06 06:14 By: nickm Comment: Just to clarify, if this problem is fixed, the fix isn't in CVS. I can still induce a segfault with: def outer(*args): def inner(): print args outer(1,2,3) This patch fixes this problem. ------------------------------------------------------- Date: 2001-Feb-06 04:34 By: moshez Comment: assigning to Jeremy -- I think he fixed the problems Jeremy, I think this patch is no longer relevant. ------------------------------------------------------- Date: 2001-Feb-04 09:38 By: nickm Comment: Oops! That wasn't a context diff. This should be. ------------------------------------------------------- Date: 2001-Feb-04 07:22 By: nickm Comment: Improved patch; original patch modified unreleated code. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103589&group_id=5470 From noreply@sourceforge.net Fri Feb 9 19:41:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Feb 2001 11:41:15 -0800 Subject: [Patches] [Patch #103710] Change PyImport_ImportModule semantics to call __import__ Message-ID: Patch #103710 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: theller Assigned to : lemburg Summary: Change PyImport_ImportModule semantics to call __import__ Follow-Ups: Date: 2001-Feb-09 11:41 By: lemburg Comment: Checked in a slightly modified version. ------------------------------------------------------- Date: 2001-Feb-09 05:23 By: theller Comment: There was a refcount bug in the first version of this patch. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103710&group_id=5470 From noreply@sourceforge.net Fri Feb 9 22:29:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Feb 2001 14:29:00 -0800 Subject: [Patches] [Patch #103717] can't make directories with included install-sh Message-ID: Patch #103717 has been updated. Project: python Category: Build Status: Open Submitted by: dmcooke Assigned to : nobody Summary: can't make directories with included install-sh ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103717&group_id=5470 From noreply@sourceforge.net Fri Feb 9 23:05:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Feb 2001 15:05:11 -0800 Subject: [Patches] [Patch #103589] Fix segfault related to nested scopes Message-ID: Patch #103589 has been updated. Project: python Category: Parser/Compiler Status: Closed Submitted by: nickm Assigned to : jhylton Summary: Fix segfault related to nested scopes Follow-Ups: Date: 2001-Feb-09 15:05 By: jhylton Comment: done ------------------------------------------------------- Date: 2001-Feb-09 07:00 By: gvanrossum Comment: Jeremy, please note that the addition to test_scope.py mixes tabs and spaces, which will make the test suite fail. Easy to fix of course... ------------------------------------------------------- Date: 2001-Feb-08 22:08 By: gvanrossum Comment: Thanks, that's much better. It seems to work for me, but I'll leave it open for Jeremy so he can proofread it! ------------------------------------------------------- Date: 2001-Feb-08 21:52 By: nickm Comment: My apologies; Guido is correct about the example and the patch. This patch should work against the latest CVS version. Again, it includes test cases for the cases it fixes. ------------------------------------------------------- Date: 2001-Feb-08 18:21 By: gvanrossum Comment: I agree with the poster, this is not fixed in CVS. Note that the example is wrong: it only fails if you actually *call* the inner function. To the poster: your diffs are malformed. Did you use cut-and-paste to upload the diff? It seems some lines are missing. Please save the diff to a file and use file upload (don't forget to click the "Upload Revised Patch" checkbox! ------------------------------------------------------- Date: 2001-Feb-06 06:14 By: nickm Comment: Just to clarify, if this problem is fixed, the fix isn't in CVS. I can still induce a segfault with: def outer(*args): def inner(): print args outer(1,2,3) This patch fixes this problem. ------------------------------------------------------- Date: 2001-Feb-06 04:34 By: moshez Comment: assigning to Jeremy -- I think he fixed the problems Jeremy, I think this patch is no longer relevant. ------------------------------------------------------- Date: 2001-Feb-04 09:38 By: nickm Comment: Oops! That wasn't a context diff. This should be. ------------------------------------------------------- Date: 2001-Feb-04 07:22 By: nickm Comment: Improved patch; original patch modified unreleated code. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103589&group_id=5470 From noreply@sourceforge.net Fri Feb 9 23:09:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Feb 2001 15:09:18 -0800 Subject: [Patches] [Patch #102453] Modified urlencode in urllib to accept more types Message-ID: Patch #102453 has been updated. Project: python Category: library Status: Closed Submitted by: nobody Assigned to : jhylton Summary: Modified urlencode in urllib to accept more types Follow-Ups: Date: 2001-Feb-09 15:09 By: jhylton Comment: you got it, bquinlan ------------------------------------------------------- Date: 2001-Feb-08 23:09 By: bquinlan Comment: This patch has been superceeded and should be closed. ------------------------------------------------------- Date: 2001-Jan-04 07:47 By: gvanrossum Comment: This is a reasonable idea. Jeremy, if you have a minute, can you review this? ------------------------------------------------------- Date: 2000-Nov-21 03:18 By: moshez Comment: It looks good, except for accepting tuples: that's, IMHO, unneeded featurism. If it is accepted, here are docs: (replace the current docs for urlencode by:) \begin{funcdesc}{urlencode}{data} Convert a list of 2-tuples or a dictionary (treated as a list of (key, value) 2-tuples) to a ``url-encoded'' string, suitable to pass to \function{urlopen()} above as the optional \var{data} argument. This is useful to pass a dictionary of form fields to a \code{POST} request. The resulting string is a series of \code{\var{key}=\var{value}} pairs separated by \character{\&} characters, where both \var{key} and \var{value} are quoted using \function{quote_plus()} above. \end{funcdesc} Assigning to Jeremy 'cause he seems the urllib guy ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102453&group_id=5470 From noreply@sourceforge.net Sat Feb 10 00:11:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Feb 2001 16:11:39 -0800 Subject: [Patches] [Patch #101394] lookdict optimizations Message-ID: Patch #101394 has been updated. Project: python Category: core (C code) Status: Open Submitted by: marangoz Assigned to : fdrake Summary: lookdict optimizations Follow-Ups: Date: 2001-Feb-09 16:11 By: jhylton Comment: Is this patch still revelant? ------------------------------------------------------- Date: 2000-Sep-03 21:09 By: marangoz Comment: Let's add a comment, although this has been raised on python-dev. This patch proposes a couple of ideas for optimizing & speeding dict lookups -- not all of them need to be applied though. - clear the eventual errors from Object_Compare only on need (this logic needs to be double-checked once again to see whether it really works) - defer variable initializations after the most common return cases - specialize string_compare() for lookdict_string. The test comparing the first char, before calling memcmp(), can be added too. - inline the first item probe in PyDict_GetItem. This saves a func call for the most common case (common to lookdict & lookdict_string). ------------------------------------------------------- Date: 2000-Sep-04 06:45 By: gvanrossum Comment: Quick comments: we should *always* call PyErr_Occurred() after PyObject_Compare() (and PyErr_Clear() if PyErr_Occurred() returned true). PyErr_Compare() really doesn't expect a pending exception coming in and so *not* clearing the error might break the *next* PyErr_Compare() call. (This doesn't happen typically but PyObject_Compare() can execute arbitrary code, some of which might call PyErr_Occurred() without calling PyErr_Clear() first.) ------------------------------------------------------- Date: 2000-Sep-05 06:05 By: nobody Comment: Correct! But then, aren't the current "else" if(cmp == 0) clauses risky after PyObject_Compare()? An exception may be set in external code while making Object_Compare() to return 0! Perhaps not in Python source, but in buggy extensions. lookdict() will then overlook this "hit". Patch updated, without "else" clauses and with the 1st char check in string_compare_equal(). ------------------------------------------------------- Date: 2000-Sep-05 06:08 By: marangoz Comment: Argh! These Web interfaces strike again - forgot to login. ------------------------------------------------------- Date: 2000-Sep-14 09:26 By: fdrake Comment: Revised patch: Instead of defining a function to do the fast string comparison, use a macro, but let it use the documented string object API (PyString_GET_SIZE(), PyString_AS_STRING()) instead of breaking the encapsulation in the code. This avoids all function calls to do the string compare, except memcmp() (which good compilers can inline anyway). Vladimir, take a look at this; if you're happy, I'm happy, and you can check it in. Thanks! ------------------------------------------------------- Date: 2000-Sep-14 13:51 By: fdrake Comment: Guido, please review (since Vladimir's away). ------------------------------------------------------- Date: 2000-Sep-15 11:18 By: gvanrossum Comment: Accepted. Assuming you've tested this, it looks fine to me. Can you time this a bit? There's one niggling issue: some people think that before you do memcmp() you should manually compare the first character. Others think that's unnecessary (since a good compiler can inline memcmp anyway). (It's also a bit scary if the size is zero.) So please ignore this but keep it in mind for timing experiments. :) ------------------------------------------------------- Date: 2000-Sep-25 14:38 By: twouters Comment: Shouldn't this patch be either postponed or checked in? ------------------------------------------------------- Date: 2000-Sep-25 18:52 By: fdrake Comment: It's postponed since I've not had time to run performance tests to measure the corner case it aims to improve. It turns out that generating the test data I need takes a long time (I need hash collisions of identifier-like strings). I just need to be able to let my generator run for a long time (it was generating more collisions than I'd expected, but I don't know how many off-hand). Another interesting metric would be to examine the .pyc files generated from the standard library and find out if there are any string hash collisions there -- if not, or if very few, it's not worth the added complexity. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101394&group_id=5470 From noreply@sourceforge.net Sat Feb 10 00:12:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Feb 2001 16:12:31 -0800 Subject: [Patches] [Patch #101264] Attribute Doc-Strings (PEP 224) Message-ID: Patch #101264 has been updated. Project: python Category: core (C code) Status: Postponed Submitted by: lemburg Assigned to : lemburg Summary: Attribute Doc-Strings (PEP 224) Follow-Ups: Date: 2001-Jan-04 11:43 By: lemburg Comment: Perhaps we should rediscuss the PEP on python-dev ? I really have a strong need to add documentation to attributes in a way which is compatible with the existing __doc__ string facilities, so I'd appreciate feedback. ------------------------------------------------------- Date: 2001-Jan-04 07:53 By: gvanrossum Comment: This is (poresumably) for PEP 224, which is marked as pie-in-the-sky and thus won't be considered for 2.1. Really, I should pronounce on that PEP (I don't like it very much but haven't found the right argument to reject it :-) so this patch can either go in be rejected. ------------------------------------------------------- Date: 2000-Aug-23 02:22 By: lemburg Comment: This patch implements the proposed addition of doc-strings for e.g. class attribute, module attributes, etc. See the upcoming PEP for details (the PEP was already submitted to the PEP editor for review). Here's a shot excerpt: class C: " class C doc-string " a = 1 " attribute C.a doc-string (1)" b = 2 " attribute C.b doc-string (2)" results in following new class attributes to be created: C.__doc__a__ == " attribute C.a doc-string (1)" C.__doc__b__ == " attribute C.b doc-string (2)" ------------------------------------------------------- Date: 2000-Aug-23 08:21 By: tim_one Comment: Postponed due to 2.0 feature freeze and assigned to the release manager for re-opening. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101264&group_id=5470 From noreply@sourceforge.net Sat Feb 10 00:13:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Feb 2001 16:13:06 -0800 Subject: [Patches] [Patch #103669] Allow jython to complete the test_unicode. Message-ID: Patch #103669 has been updated. Project: python Category: None Status: Open Submitted by: bckfnn Assigned to : lemburg Summary: Allow jython to complete the test_unicode. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103669&group_id=5470 From noreply@sourceforge.net Sat Feb 10 00:13:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Feb 2001 16:13:35 -0800 Subject: [Patches] [Patch #103693] tupleobject.c: implement tuple.index() and tuple.count() Message-ID: Patch #103693 has been updated. Project: python Category: core (C code) Status: Open Submitted by: mfx Assigned to : gvanrossum Summary: tupleobject.c: implement tuple.index() and tuple.count() Follow-Ups: Date: 2001-Feb-09 16:13 By: jhylton Comment: interested in adding this to 2.1? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103693&group_id=5470 From noreply@sourceforge.net Sat Feb 10 00:16:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Feb 2001 16:16:20 -0800 Subject: [Patches] [Patch #103655] configure changes for Solaris Message-ID: Patch #103655 has been updated. Project: python Category: Build Status: Open Submitted by: sgriggs Assigned to : loewis Summary: configure changes for Solaris ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103655&group_id=5470 From noreply@sourceforge.net Sat Feb 10 00:16:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Feb 2001 16:16:41 -0800 Subject: [Patches] [Patch #103656] configure.in changes for Solaris Message-ID: Patch #103656 has been updated. Project: python Category: Build Status: Open Submitted by: sgriggs Assigned to : loewis Summary: configure.in changes for Solaris ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103656&group_id=5470 From noreply@sourceforge.net Sat Feb 10 00:16:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Feb 2001 16:16:54 -0800 Subject: [Patches] [Patch #103657] make install on solaris dies duringing mkdir Message-ID: Patch #103657 has been updated. Project: python Category: Build Status: Open Submitted by: sgriggs Assigned to : loewis Summary: make install on solaris dies duringing mkdir Follow-Ups: Date: 2001-Feb-07 07:05 By: nascheme Comment: Why is INSTALL=cp and not install-sh? I don't think this patch is the correct solution. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103657&group_id=5470 From noreply@sourceforge.net Sat Feb 10 07:27:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Feb 2001 23:27:31 -0800 Subject: [Patches] [Patch #103717] can't make directories with included install-sh Message-ID: Patch #103717 has been updated. Project: python Category: Build Status: Open Submitted by: dmcooke Assigned to : nobody Summary: can't make directories with included install-sh Follow-Ups: Date: 2001-Feb-09 23:27 By: dmcooke Comment: Should've noticed that this fixes the same problem that Patch #103657 does. According to CVS, install-sh has had 2 changes since 1996, the last over 2 years ago. Might be due for an update :-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103717&group_id=5470 From noreply@sourceforge.net Sat Feb 10 07:30:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Feb 2001 23:30:14 -0800 Subject: [Patches] [Patch #103657] make install on solaris dies duringing mkdir Message-ID: Patch #103657 has been updated. Project: python Category: Build Status: Open Submitted by: sgriggs Assigned to : loewis Summary: make install on solaris dies duringing mkdir Follow-Ups: Date: 2001-Feb-09 23:30 By: dmcooke Comment: It's not INSTALL=cp -- it's probably INSTALL=./install-sh, and install-sh calls cp as cp -d. See my patch #103717 for a better fix. ------------------------------------------------------- Date: 2001-Feb-07 07:05 By: nascheme Comment: Why is INSTALL=cp and not install-sh? I don't think this patch is the correct solution. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103657&group_id=5470 From noreply@sourceforge.net Sat Feb 10 14:10:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 10 Feb 2001 06:10:02 -0800 Subject: [Patches] [Patch #103669] Allow jython to complete the test_unicode. Message-ID: Patch #103669 has been updated. Project: python Category: library Status: Closed Submitted by: bckfnn Assigned to : lemburg Summary: Allow jython to complete the test_unicode. Follow-Ups: Date: 2001-Feb-10 06:10 By: lemburg Comment: Checked in. Thanks Finn. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103669&group_id=5470 From noreply@sourceforge.net Sat Feb 10 14:23:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 10 Feb 2001 06:23:34 -0800 Subject: [Patches] [Patch #103685] Printing unicode Message-ID: Patch #103685 has been updated. Project: python Category: core (C code) Status: Postponed Submitted by: nobody Assigned to : lemburg Summary: Printing unicode Follow-Ups: Date: 2001-Feb-10 06:23 By: lemburg Comment: Postponed for discussion in Python 2.2 cycle as per request by Guido. ------------------------------------------------------- Date: 2001-Feb-09 05:45 By: lemburg Comment: I'd rather break some code here and then get this done right once and for all. I wouldn't want to carry along a special attribute which needs to be checked before every .write() operation. This costs performance and adds unnecessary convolution to the file API. Since Unicode is still very new, I doubt that the impact of this will cause people too much trouble. IMHO, the correct way to deal with this is to let the file object write methods deal with the problem in an application specific way. cStringIO.c (and all other file-like objects) should be fixed to use the s# parser markers instead of requiring a real string object. This will also enhance interoperability with other data storage types. ------------------------------------------------------- Date: 2001-Feb-09 04:54 By: nobody Comment: waaah - without https I cant upload a new version of the patch. The original patch fails to clear the exception if getattr('__str__before_write__') fails... that inner part of PyFile_WriteObject needs to be: stringize = PyObject_GetAttrString(f, "__str_before_write__"); if(!stringize) PyErr_Clear(); if(!stringize || PyObject_IsTrue(stringize)) value = PyObject_Str(v); else { Py_INCREF(v); value = v; } my appologies for the extra trouble. ------------------------------------------------------- Date: 2001-Feb-09 04:02 By: nobody Comment: I hadnt seen that original discussion, and cant find it in the archives now :-( However, your summary matches exactly what this patch achieves for files have __str_before_write__=0 I think we have to require this extra flag to enable the new behaviour. For example, this prevents breakage of old code that prints to a StringIO instance. (Toby Dickenson, tdickenson@geminidataloggers.com) ------------------------------------------------------- Date: 2001-Feb-08 08:02 By: lemburg Comment: I don't remember the details, but there was a discussion about this problem on python-dev. The outcome was to let Unicode objects pass through as-is to the file object and then have it apply whatever conversion it takes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103685&group_id=5470 From noreply@sourceforge.net Sat Feb 10 15:03:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 10 Feb 2001 07:03:14 -0800 Subject: [Patches] [Patch #101264] Attribute Doc-Strings (PEP 224) Message-ID: Patch #101264 has been updated. Project: python Category: core (C code) Status: Open Submitted by: lemburg Assigned to : gvanrossum Summary: Attribute Doc-Strings (PEP 224) Follow-Ups: Date: 2001-Feb-10 07:03 By: gvanrossum Comment: Reopened so I can think about how to respond. My gut still says not now. ------------------------------------------------------- Date: 2001-Jan-04 11:43 By: lemburg Comment: Perhaps we should rediscuss the PEP on python-dev ? I really have a strong need to add documentation to attributes in a way which is compatible with the existing __doc__ string facilities, so I'd appreciate feedback. ------------------------------------------------------- Date: 2001-Jan-04 07:53 By: gvanrossum Comment: This is (poresumably) for PEP 224, which is marked as pie-in-the-sky and thus won't be considered for 2.1. Really, I should pronounce on that PEP (I don't like it very much but haven't found the right argument to reject it :-) so this patch can either go in be rejected. ------------------------------------------------------- Date: 2000-Aug-23 02:22 By: lemburg Comment: This patch implements the proposed addition of doc-strings for e.g. class attribute, module attributes, etc. See the upcoming PEP for details (the PEP was already submitted to the PEP editor for review). Here's a shot excerpt: class C: " class C doc-string " a = 1 " attribute C.a doc-string (1)" b = 2 " attribute C.b doc-string (2)" results in following new class attributes to be created: C.__doc__a__ == " attribute C.a doc-string (1)" C.__doc__b__ == " attribute C.b doc-string (2)" ------------------------------------------------------- Date: 2000-Aug-23 08:21 By: tim_one Comment: Postponed due to 2.0 feature freeze and assigned to the release manager for re-opening. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101264&group_id=5470 From noreply@sourceforge.net Sat Feb 10 15:16:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 10 Feb 2001 07:16:59 -0800 Subject: [Patches] [Patch #103721] robotparser2.py and empty url path Message-ID: Patch #103721 has been updated. Project: python Category: Modules Status: Open Submitted by: calvin Assigned to : nobody Summary: robotparser2.py and empty url path ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103721&group_id=5470 From noreply@sourceforge.net Sat Feb 10 20:15:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 10 Feb 2001 12:15:47 -0800 Subject: [Patches] [Patch #103657] make install on solaris dies duringing mkdir Message-ID: Patch #103657 has been updated. Project: python Category: Build Status: Rejected Submitted by: sgriggs Assigned to : nobody Summary: make install on solaris dies duringing mkdir Follow-Ups: Date: 2001-Feb-10 12:15 By: nascheme Comment: David's patch (#103717) has been applied. That should address this problem. ------------------------------------------------------- Date: 2001-Feb-09 23:30 By: dmcooke Comment: It's not INSTALL=cp -- it's probably INSTALL=./install-sh, and install-sh calls cp as cp -d. See my patch #103717 for a better fix. ------------------------------------------------------- Date: 2001-Feb-07 07:05 By: nascheme Comment: Why is INSTALL=cp and not install-sh? I don't think this patch is the correct solution. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103657&group_id=5470 From noreply@sourceforge.net Sat Feb 10 20:17:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 10 Feb 2001 12:17:17 -0800 Subject: [Patches] [Patch #103717] can't make directories with included install-sh Message-ID: Patch #103717 has been updated. Project: python Category: Build Status: Closed Submitted by: dmcooke Assigned to : nobody Summary: can't make directories with included install-sh Follow-Ups: Date: 2001-Feb-10 12:17 By: nascheme Comment: Applied. Thanks David. ------------------------------------------------------- Date: 2001-Feb-09 23:27 By: dmcooke Comment: Should've noticed that this fixes the same problem that Patch #103657 does. According to CVS, install-sh has had 2 changes since 1996, the last over 2 years ago. Might be due for an update :-) ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103717&group_id=5470 From noreply@sourceforge.net Sun Feb 11 09:46:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 11 Feb 2001 01:46:18 -0800 Subject: [Patches] [Patch #103729] tutorial update for Unicode Message-ID: Patch #103729 has been updated. Project: python Category: documentation Status: Open Submitted by: ping Assigned to : nobody Summary: tutorial update for Unicode ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103729&group_id=5470 From noreply@sourceforge.net Sun Feb 11 09:46:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 11 Feb 2001 01:46:42 -0800 Subject: [Patches] [Patch #103729] tutorial update for Unicode Message-ID: Patch #103729 has been updated. Project: python Category: documentation Status: Open Submitted by: ping Assigned to : fdrake Summary: tutorial update for Unicode ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103729&group_id=5470 From noreply@sourceforge.net Mon Feb 12 09:03:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Feb 2001 01:03:52 -0800 Subject: [Patches] [Patch #103743] [windows] Correction to bug #131273 Message-ID: Patch #103743 has been updated. Project: python Category: Windows Status: Open Submitted by: cgouiran Assigned to : nobody Summary: [windows] Correction to bug #131273 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103743&group_id=5470 From noreply@sourceforge.net Mon Feb 12 14:44:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Feb 2001 06:44:29 -0800 Subject: [Patches] [Patch #103748] test_zlib join Message-ID: Patch #103748 has been updated. Project: python Category: None Status: Open Submitted by: htrd Assigned to : nobody Summary: test_zlib join ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103748&group_id=5470 From noreply@sourceforge.net Mon Feb 12 15:15:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Feb 2001 07:15:10 -0800 Subject: [Patches] [Patch #103749] fix for complex & default args segfault Message-ID: Patch #103749 has been updated. Project: python Category: Parser/Compiler Status: Open Submitted by: mwh Assigned to : nobody Summary: fix for complex & default args segfault ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103749&group_id=5470 From noreply@sourceforge.net Mon Feb 12 15:46:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Feb 2001 07:46:59 -0800 Subject: [Patches] [Patch #103752] [bug #132000] Allow robotparser to handle non-HTTP URLs Message-ID: Patch #103752 has been updated. Project: python Category: library Status: Open Submitted by: fdrake Assigned to : nobody Summary: [bug #132000] Allow robotparser to handle non-HTTP URLs ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103752&group_id=5470 From noreply@sourceforge.net Mon Feb 12 15:47:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Feb 2001 07:47:54 -0800 Subject: [Patches] [Patch #103752] [bug #132000] Allow robotparser to handle non-HTTP URLs Message-ID: Patch #103752 has been updated. Project: python Category: library Status: Open Submitted by: fdrake Assigned to : montanaro Summary: [bug #132000] Allow robotparser to handle non-HTTP URLs ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103752&group_id=5470 From noreply@sourceforge.net Mon Feb 12 15:47:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Feb 2001 07:47:55 -0800 Subject: [Patches] [Patch #103721] robotparser2.py and empty url path Message-ID: Patch #103721 has been updated. Project: python Category: Modules Status: Open Submitted by: calvin Assigned to : montanaro Summary: robotparser2.py and empty url path ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103721&group_id=5470 From noreply@sourceforge.net Mon Feb 12 15:48:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Feb 2001 07:48:16 -0800 Subject: [Patches] [Patch #103703] Fix for Tools\compiler\transformer.py and renaming Message-ID: Patch #103703 has been updated. Project: python Category: library Status: Open Submitted by: bquinlan Assigned to : jhylton Summary: Fix for Tools\compiler\transformer.py and renaming ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103703&group_id=5470 From noreply@sourceforge.net Mon Feb 12 16:07:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Feb 2001 08:07:07 -0800 Subject: [Patches] [Patch #103743] [windows] Correction to bug #131273 Message-ID: Patch #103743 has been updated. Project: python Category: Windows Status: Open Submitted by: cgouiran Assigned to : mhammond Summary: [windows] Correction to bug #131273 Follow-Ups: Date: 2001-Feb-12 08:07 By: fdrake Comment: Assigned to Mark Hammond since the original bug is already assigned to him. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103743&group_id=5470 From noreply@sourceforge.net Mon Feb 12 16:08:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Feb 2001 08:08:17 -0800 Subject: [Patches] [Patch #103749] fix for complex & default args segfault Message-ID: Patch #103749 has been updated. Project: python Category: Parser/Compiler Status: Open Submitted by: mwh Assigned to : jhylton Summary: fix for complex & default args segfault Follow-Ups: Date: 2001-Feb-12 08:08 By: fdrake Comment: Assigned to Mr. Compiler. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103749&group_id=5470 From noreply@sourceforge.net Mon Feb 12 16:10:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Feb 2001 08:10:52 -0800 Subject: [Patches] [Patch #103753] zlib decompress; uncontrollable memory usage Message-ID: Patch #103753 has been updated. Project: python Category: None Status: Open Submitted by: htrd Assigned to : nobody Summary: zlib decompress; uncontrollable memory usage ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103753&group_id=5470 From noreply@sourceforge.net Mon Feb 12 16:49:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Feb 2001 08:49:00 -0800 Subject: [Patches] [Patch #103547] Fix mpz.binary method to handle 64-bit systems Message-ID: Patch #103547 has been updated. Project: python Category: Modules Status: Closed Submitted by: rfish Assigned to : fdrake Summary: Fix mpz.binary method to handle 64-bit systems Follow-Ups: Date: 2001-Feb-12 08:49 By: fdrake Comment: Checked in as Modules/mpzmodule.c revision 2.36. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103547&group_id=5470 From scarpenter@innerx.net Mon Feb 12 17:27:14 2001 From: scarpenter@innerx.net (scarpenter@innerx.net) Date: Mon, 12 Feb 2001 12:27:14 -0500 Subject: [Patches] New Online Auction Site for Brand Name Tools, Hardware, Home Improvement Products Message-ID: --=200102121225= Content-Type: text/html;charset=US-ASCII http://www

http://www.hardwareusa.net

Stop paying outrageous retail prices for the products you need to keep your home beautiful.

Hardware USA, a leading home center, is excited to invite you to visit our new website and auction store. Visit us now and save big money on superior products from such trusted brand names as Black & Decker, DeWalt and Makita.

Never before has saving money on top quality power tools, hardware, electrical and plumbing supplies, lawn and garden equipment and automotive care products been easier or more fun!

Shop conveniently from your home or office and save big at the new Hardware USA website and auction store!

Be sure to check out our unbeatable selection of interior and exterior paint too!

100% CUSTOMER SATISFACTION GUARANTEED.

http://www.hardwareusa.net

 

--=200102121225=-- From noreply@sourceforge.net Mon Feb 12 17:43:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Feb 2001 09:43:15 -0800 Subject: [Patches] [Patch #103753] zlib decompress; uncontrollable memory usage Message-ID: Patch #103753 has been updated. Project: python Category: None Status: Open Submitted by: htrd Assigned to : akuchling Summary: zlib decompress; uncontrollable memory usage ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103753&group_id=5470 From noreply@sourceforge.net Mon Feb 12 17:43:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Feb 2001 09:43:15 -0800 Subject: [Patches] [Patch #103748] test_zlib join Message-ID: Patch #103748 has been updated. Project: python Category: None Status: Open Submitted by: htrd Assigned to : akuchling Summary: test_zlib join ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103748&group_id=5470 From noreply@sourceforge.net Mon Feb 12 18:08:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Feb 2001 10:08:16 -0800 Subject: [Patches] [Patch #103752] [bug #132000] Allow robotparser to handle non-HTTP URLs Message-ID: Patch #103752 has been updated. Project: python Category: library Status: Rejected Submitted by: fdrake Assigned to : montanaro Summary: [bug #132000] Allow robotparser to handle non-HTTP URLs Follow-Ups: Date: 2001-Feb-12 10:08 By: montanaro Comment: Bastian, I've already implemented this in a different fashion (always using urllib). Fred has a copy to test. I'll close this patch and shoot you a copy. S ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103752&group_id=5470 From noreply@sourceforge.net Mon Feb 12 18:09:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Feb 2001 10:09:35 -0800 Subject: [Patches] [Patch #103721] robotparser2.py and empty url path Message-ID: Patch #103721 has been updated. Project: python Category: library Status: Closed Submitted by: calvin Assigned to : montanaro Summary: robotparser2.py and empty url path Follow-Ups: Date: 2001-Feb-12 10:09 By: montanaro Comment: thanks, accepted and closed ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103721&group_id=5470 From noreply@sourceforge.net Mon Feb 12 18:13:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Feb 2001 10:13:38 -0800 Subject: [Patches] [Patch #103729] tutorial update for Unicode Message-ID: Patch #103729 has been updated. Project: python Category: documentation Status: Open Submitted by: ping Assigned to : ping Summary: tutorial update for Unicode Follow-Ups: Date: 2001-Feb-12 10:13 By: fdrake Comment: The second sentence of the second affected paragraph still doesn't seem right (not affected by the patch). Since ASCII is the default encoding, Latin-1 chars are not particularly easy to encode without an explicit call to the decoder (unicode('latin-1 stuff...', 'iso-8859-1')), which is too much typing to say that it's easy to encode. Otherwise it looks fine to me. If you can adjust that sentence, please go ahead and check it in. Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103729&group_id=5470 From noreply@sourceforge.net Mon Feb 12 20:42:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Feb 2001 12:42:52 -0800 Subject: [Patches] [Patch #103729] tutorial update for Unicode Message-ID: Patch #103729 has been updated. Project: python Category: documentation Status: Closed Submitted by: ping Assigned to : ping Summary: tutorial update for Unicode Follow-Ups: Date: 2001-Feb-12 12:42 By: ping Comment: Oh, that sentence was in MAL's original text. I think what he meant was that Python will accept a literal u'Oui, André est là.' in place of unicode('Oui, André est là.', 'latin-1'), or in other words, if you already have Latin-1 strings in your source code, you only have to stick a 'u' in front of them. I'm checking in this less-Western-biased explanation: Other characters are interpreted by using their respective ordinal values directly as Unicode ordinals. If you have literal strings in the standard Latin-1 encoding that is used in many Western countries, you will find it convenient that the lower 256 characters of Unicode are the same as the 256 characters of Latin-1. Hope that's okay with you. ------------------------------------------------------- Date: 2001-Feb-12 10:13 By: fdrake Comment: The second sentence of the second affected paragraph still doesn't seem right (not affected by the patch). Since ASCII is the default encoding, Latin-1 chars are not particularly easy to encode without an explicit call to the decoder (unicode('latin-1 stuff...', 'iso-8859-1')), which is too much typing to say that it's easy to encode. Otherwise it looks fine to me. If you can adjust that sentence, please go ahead and check it in. Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103729&group_id=5470 From noreply@sourceforge.net Mon Feb 12 20:47:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Feb 2001 12:47:17 -0800 Subject: [Patches] [Patch #103729] tutorial update for Unicode Message-ID: Patch #103729 has been updated. Project: python Category: documentation Status: Closed Submitted by: ping Assigned to : ping Summary: tutorial update for Unicode Follow-Ups: Date: 2001-Feb-12 12:47 By: ping Comment: Argh. I can't check it in. SourceForge is denying me CVS access for some reason. I've placed the tut.tex file at http://www.lfw.org/python/tut.tex -- if you have a moment to grab it and check it in. Thanks. ------------------------------------------------------- Date: 2001-Feb-12 12:42 By: ping Comment: Oh, that sentence was in MAL's original text. I think what he meant was that Python will accept a literal u'Oui, André est là.' in place of unicode('Oui, André est là.', 'latin-1'), or in other words, if you already have Latin-1 strings in your source code, you only have to stick a 'u' in front of them. I'm checking in this less-Western-biased explanation: Other characters are interpreted by using their respective ordinal values directly as Unicode ordinals. If you have literal strings in the standard Latin-1 encoding that is used in many Western countries, you will find it convenient that the lower 256 characters of Unicode are the same as the 256 characters of Latin-1. Hope that's okay with you. ------------------------------------------------------- Date: 2001-Feb-12 10:13 By: fdrake Comment: The second sentence of the second affected paragraph still doesn't seem right (not affected by the patch). Since ASCII is the default encoding, Latin-1 chars are not particularly easy to encode without an explicit call to the decoder (unicode('latin-1 stuff...', 'iso-8859-1')), which is too much typing to say that it's easy to encode. Otherwise it looks fine to me. If you can adjust that sentence, please go ahead and check it in. Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103729&group_id=5470 From noreply@sourceforge.net Mon Feb 12 22:57:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 12 Feb 2001 14:57:16 -0800 Subject: [Patches] [Patch #103757] catch server recursion in urrlib Message-ID: Patch #103757 has been updated. Project: python Category: library Status: Open Submitted by: montanaro Assigned to : nobody Summary: catch server recursion in urrlib ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103757&group_id=5470 From noreply@sourceforge.net Tue Feb 13 22:21:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 13 Feb 2001 14:21:19 -0800 Subject: [Patches] [Patch #103729] tutorial update for Unicode Message-ID: Patch #103729 has been updated. Project: python Category: documentation Status: Closed Submitted by: ping Assigned to : ping Summary: tutorial update for Unicode Follow-Ups: Date: 2001-Feb-13 14:21 By: ping Comment: SourceForce unwedged itself today. My access is back. I checked in the change. ------------------------------------------------------- Date: 2001-Feb-12 10:13 By: fdrake Comment: The second sentence of the second affected paragraph still doesn't seem right (not affected by the patch). Since ASCII is the default encoding, Latin-1 chars are not particularly easy to encode without an explicit call to the decoder (unicode('latin-1 stuff...', 'iso-8859-1')), which is too much typing to say that it's easy to encode. Otherwise it looks fine to me. If you can adjust that sentence, please go ahead and check it in. Thanks! ------------------------------------------------------- Date: 2001-Feb-12 12:47 By: ping Comment: Argh. I can't check it in. SourceForge is denying me CVS access for some reason. I've placed the tut.tex file at http://www.lfw.org/python/tut.tex -- if you have a moment to grab it and check it in. Thanks. ------------------------------------------------------- Date: 2001-Feb-12 12:42 By: ping Comment: Oh, that sentence was in MAL's original text. I think what he meant was that Python will accept a literal u'Oui, André est là.' in place of unicode('Oui, André est là.', 'latin-1'), or in other words, if you already have Latin-1 strings in your source code, you only have to stick a 'u' in front of them. I'm checking in this less-Western-biased explanation: Other characters are interpreted by using their respective ordinal values directly as Unicode ordinals. If you have literal strings in the standard Latin-1 encoding that is used in many Western countries, you will find it convenient that the lower 256 characters of Unicode are the same as the 256 characters of Latin-1. Hope that's okay with you. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103729&group_id=5470 From noreply@sourceforge.net Tue Feb 13 23:08:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 13 Feb 2001 15:08:02 -0800 Subject: [Patches] [Patch #103777] Cannot build Python-2.1a2 on Windows 2000 Message-ID: Patch #103777 has been updated. Project: python Category: Build Status: Open Submitted by: dkuhlman2 Assigned to : nobody Summary: Cannot build Python-2.1a2 on Windows 2000 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103777&group_id=5470 From noreply@sourceforge.net Wed Feb 14 04:33:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 13 Feb 2001 20:33:50 -0800 Subject: [Patches] [Patch #103782] Clarify "altinstall" Installation Instructions Message-ID: Patch #103782 has been updated. Project: python Category: Build Status: Open Submitted by: kbk Assigned to : nobody Summary: Clarify "altinstall" Installation Instructions ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103782&group_id=5470 From noreply@sourceforge.net Wed Feb 14 07:15:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 13 Feb 2001 23:15:29 -0800 Subject: [Patches] [Patch #103777] Cannot build Python-2.1a2 on Windows 2000 Message-ID: Patch #103777 has been updated. Project: python Category: Build Status: Open Submitted by: dkuhlman2 Assigned to : bwarsaw Summary: Cannot build Python-2.1a2 on Windows 2000 Follow-Ups: Date: 2001-Feb-13 23:15 By: tim_one Comment: Assigned to Barry not because he can fix it, but because I don't understand what CVS does here. Is there some flag I have to set on these things to make sure they retain the Windows line-ends when somebody else checks them out? I see that the three files mentioned here don't have a "-kb" thingie in my local CVS/Entries file, while the other .dsp files do. That's almost certainly because all 3 were created recently, and I just did "cvs add ... cvs commit" on them. They've definitely got Windows line-ends on my box. I figure the "b" in "kb" stands for "Bass player", so I'm asking you for a riff. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103777&group_id=5470 From chris@collegewafer.com Wed Feb 14 09:03:51 2001 From: chris@collegewafer.com (Chris Baker) Date: Wed, 14 Feb 2001 04:03:51 -0500 Subject: [Patches] Hi, Need 6"-8" Wafer Special! Si, SOI, ZnO, MEMS & More! Message-ID: <200102140904.DAA12664@ionet.net> Hi, Let CollegeWafer.com take care of your wafer needs! Save time and $$$ It= 's a=20 FREE service to you! Visit http://www.collegewafer.com or call 800-713-9375, Fax 888-832-0340 = or email=20 chris@collegewafer.com We have AIN, Fused Silica, Pyrex, GaN, SiC, ZnO of course Si, SOI, Ultra-= Thin=20 Si, Ge, InP, ZnSe, ZnO, ZnS, GaP, Infrared and so much more, including: Custom orders for Prime wafers, Test wafers, or Coin Roll wafers.=20 5" N<100> 5-10 ohm-cm. 24-25.9mils 5" N <100> 10-20 ohm-cm. 24-26mils=20 5" P<100> 5-10 ohm-cm. 24-25.9mils=20 5" P<100> 10-20 ohm-cm. 24-25.9mils 6" N<100> 1-5 ohm-cm. 25-27.9mils=20 6" N<100> 10-20 ohm-cm. 585-725=B5m =20 6" N<100> 10-20 ohm-cm. >650=B5m =20 6" N<100> 20-30 ohm-cm. 625-725=B5m 6" N<100> 20-30 ohm-cm. 25-27.5mils 6" P<100> 1-10 ohm-cm. 625-725=B5m=20 6" P<100> 10-20 ohm-cm. 625-725=B5m=20 6" P<100> 2-15 ohm-cm. 625-725=B5m=20 6" P<100> >30 ohm-cm. 25-27.5mils=20 8" P<100> 1-10 ohm-cm. 675-775=B5m=20 8" P<100> 10-20 ohm-cm. 675-775=B5m=20 8" P<100> 10-20 ohm-cm. 700-750=B5m=20 8" P<100> 10-20 ohm-cm. 700-750=B5m=20 12" P <100> 1-100 ohm-cm.750-800=B5m=20 Polishing and Reclaim: We can polish test and prime wafers at better than SEMI standard spe= cifications. Need Wafer inspection services? Test your wafers for type, resistivity, thickness, TI= R, STIR,=20 TTV, FPD and cleanliness analysis. How about: Cleaning, Lapping, Etching, Edge round, graphic printouts (2D &= 3D),=20 Certificate of Conformance, Certificate of Analysis, Polishing, = Reclaim=20 Services, Laser-cutting and Oxide Services=20 Ask about In-House Oxide Services:=20 Thermally grown oxide for 2"-8" wafers ranging in thickness from 500-100,= 000=20 Angstroms. http://www.collegewafer.com/contact_us/Remove/remove.html 11ada22 From noreply@sourceforge.net Wed Feb 14 09:48:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Feb 2001 01:48:01 -0800 Subject: [Patches] [Patch #103777] Cannot build Python-2.1a2 on Windows 2000 Message-ID: Patch #103777 has been updated. Project: python Category: Build Status: Closed Submitted by: dkuhlman2 Assigned to : bwarsaw Summary: Cannot build Python-2.1a2 on Windows 2000 Follow-Ups: Date: 2001-Feb-14 01:48 By: twouters Comment: The -kb flag stands for 'keep [it] binary' :) I added the -kb flag to the three .dsp's in question and it should be fixed now: they end up on my UNIX boxen as DOS files, in any case. Please test, though! (You add -kb flags to existing files using 'cvs admin -kb '. There's probably some dropdown menu under Windows to do it from ;) ------------------------------------------------------- Date: 2001-Feb-13 23:15 By: tim_one Comment: Assigned to Barry not because he can fix it, but because I don't understand what CVS does here. Is there some flag I have to set on these things to make sure they retain the Windows line-ends when somebody else checks them out? I see that the three files mentioned here don't have a "-kb" thingie in my local CVS/Entries file, while the other .dsp files do. That's almost certainly because all 3 were created recently, and I just did "cvs add ... cvs commit" on them. They've definitely got Windows line-ends on my box. I figure the "b" in "kb" stands for "Bass player", so I'm asking you for a riff. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103777&group_id=5470 From noreply@sourceforge.net Wed Feb 14 12:58:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Feb 2001 04:58:12 -0800 Subject: [Patches] [Patch #103789] Add support to zipfile for passing file-like objects Message-ID: Patch #103789 has been updated. Project: python Category: Modules Status: Open Submitted by: itamar Assigned to : nobody Summary: Add support to zipfile for passing file-like objects ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103789&group_id=5470 From noreply@sourceforge.net Wed Feb 14 13:27:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Feb 2001 05:27:00 -0800 Subject: [Patches] [Patch #103789] Add support to zipfile for passing file-like objects Message-ID: Patch #103789 has been updated. Project: python Category: Modules Status: Open Submitted by: itamar Assigned to : nobody Summary: Add support to zipfile for passing file-like objects Follow-Ups: Date: 2001-Feb-14 05:26 By: itamar Comment: Right now I detect file-like objects by doing hasattr(file, "read"). Doing hasattr(file, "write") might be better though, since for mode="w" ZipFiles, all you need are write() and tell() methods on the file-like object. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103789&group_id=5470 From noreply@sourceforge.net Wed Feb 14 17:16:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Feb 2001 09:16:25 -0800 Subject: [Patches] [Patch #103782] Clarify "altinstall" Installation Instructions Message-ID: Patch #103782 has been updated. Project: python Category: Build Status: Open Submitted by: kbk Assigned to : nobody Summary: Clarify "altinstall" Installation Instructions ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103782&group_id=5470 From noreply@sourceforge.net Wed Feb 14 17:20:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Feb 2001 09:20:29 -0800 Subject: [Patches] [Patch #103782] Clarify "altinstall" Installation Instructions Message-ID: Patch #103782 has been updated. Project: python Category: Build Status: Open Submitted by: kbk Assigned to : nobody Summary: Clarify "altinstall" Installation Instructions Follow-Ups: Date: 2001-Feb-14 09:20 By: kbk Comment: Added comment to README regarding installing beta versions without overwriting the previous one. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103782&group_id=5470 From noreply@sourceforge.net Wed Feb 14 17:46:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Feb 2001 09:46:27 -0800 Subject: [Patches] [Patch #103748] test_zlib join Message-ID: Patch #103748 has been updated. Project: python Category: None Status: Closed Submitted by: htrd Assigned to : akuchling Summary: test_zlib join Follow-Ups: Date: 2001-Feb-14 09:46 By: akuchling Comment: Accepted; thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103748&group_id=5470 From noreply@sourceforge.net Wed Feb 14 17:48:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Feb 2001 09:48:46 -0800 Subject: [Patches] [Patch #103277] Enables a package to have more than one source dir Message-ID: Patch #103277 has been updated. Project: python Category: distutils Status: Postponed Submitted by: nobody Assigned to : gward Summary: Enables a package to have more than one source dir Follow-Ups: Date: 2001-Feb-14 09:48 By: akuchling Comment: Marking as postponed; Greg can worry about it at some future date. For now the feature is of doubtful enough usefulness that I won't pronounce on it. ------------------------------------------------------- Date: 2001-Feb-06 15:21 By: houmang Comment: There are various reasons. For instance numpy has several parts of the code organized as separate directories that constitute one Python package. Some of it is for historical reasons. Some of it is to control "optionality". i.e. you could build a "lite" version or a "heavy" version and whatever you choose gets merged into the installed package. Others might spread out code just for source maintenance and control reasons. ------------------------------------------------------- Date: 2001-Jan-28 10:19 By: akuchling Comment: I'm doubtful of the usefulness of this patch; can you please explain the motivation? Why do you want to have multiple directories containing the Python files for a single package? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103277&group_id=5470 From noreply@sourceforge.net Wed Feb 14 17:52:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Feb 2001 09:52:56 -0800 Subject: [Patches] [Patch #103687] Several improvements for bdist_wininst Message-ID: Patch #103687 has been updated. Project: python Category: distutils Status: Accepted Submitted by: theller Assigned to : theller Summary: Several improvements for bdist_wininst Follow-Ups: Date: 2001-Feb-14 09:52 By: akuchling Comment: Finally got around to looking at this patch, though I can only assess the Python code. One small thing to fix: the "Writing bitmap at offset %x" message is always printed. Probably self.announce() should be used instead (or is it a debugging message?) Anyway, go ahead and check it in! ------------------------------------------------------- Date: 2001-Feb-08 08:51 By: theller Comment: Assigned to Andrew because he wanted to review this. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103687&group_id=5470 From noreply@sourceforge.net Wed Feb 14 22:13:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Feb 2001 14:13:15 -0800 Subject: [Patches] [Patch #103804] fixes setup.py to look for xmlparse.h in the correct place Message-ID: Patch #103804 has been updated. Project: python Category: Build Status: Open Submitted by: ajseward Assigned to : nobody Summary: fixes setup.py to look for xmlparse.h in the correct place ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103804&group_id=5470 From noreply@sourceforge.net Thu Feb 15 01:23:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Feb 2001 17:23:24 -0800 Subject: [Patches] [Patch #103804] fixes setup.py to look for xmlparse.h in the correct place Message-ID: Patch #103804 has been updated. Project: python Category: Build Status: Open Submitted by: ajseward Assigned to : nobody Summary: fixes setup.py to look for xmlparse.h in the correct place Follow-Ups: Date: 2001-Feb-14 17:23 By: ajseward Comment: Sorry, this was caused by another patch that I had not looked at closely enough. There is no problem in the CVS source. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103804&group_id=5470 From noreply@sourceforge.net Thu Feb 15 06:33:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Feb 2001 22:33:54 -0800 Subject: [Patches] [Patch #103808] doctest.py docs Message-ID: Patch #103808 has been updated. Project: python Category: documentation Status: Open Submitted by: tim_one Assigned to : nobody Summary: doctest.py docs ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103808&group_id=5470 From noreply@sourceforge.net Thu Feb 15 06:34:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Feb 2001 22:34:14 -0800 Subject: [Patches] [Patch #103808] doctest.py docs Message-ID: Patch #103808 has been updated. Project: python Category: documentation Status: Open Submitted by: tim_one Assigned to : fdrake Summary: doctest.py docs ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103808&group_id=5470 From noreply@sourceforge.net Thu Feb 15 12:12:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 04:12:47 -0800 Subject: [Patches] [Patch #103808] doctest.py docs Message-ID: Patch #103808 has been updated. Project: python Category: documentation Status: Open Submitted by: tim_one Assigned to : moshez Summary: doctest.py docs Follow-Ups: Date: 2001-Feb-15 04:12 By: fdrake Comment: Moshe, do you have time to LaTeXify this? Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103808&group_id=5470 From noreply@sourceforge.net Thu Feb 15 13:24:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 05:24:32 -0800 Subject: [Patches] [Patch #103668] Allow jython to make temporary test modules Message-ID: Patch #103668 has been updated. Project: python Category: None Status: Open Submitted by: bckfnn Assigned to : bwarsaw Summary: Allow jython to make temporary test modules ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103668&group_id=5470 From noreply@sourceforge.net Thu Feb 15 13:24:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 05:24:32 -0800 Subject: [Patches] [Patch #103666] Allow jython to use test_new Message-ID: Patch #103666 has been updated. Project: python Category: None Status: Open Submitted by: bckfnn Assigned to : bwarsaw Summary: Allow jython to use test_new ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103666&group_id=5470 From noreply@sourceforge.net Thu Feb 15 13:24:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 05:24:33 -0800 Subject: [Patches] [Patch #103671] Allow jython to complete the test_class test Message-ID: Patch #103671 has been updated. Project: python Category: None Status: Open Submitted by: bckfnn Assigned to : bwarsaw Summary: Allow jython to complete the test_class test ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103671&group_id=5470 From noreply@sourceforge.net Thu Feb 15 13:24:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 05:24:32 -0800 Subject: [Patches] [Patch #103667] Allow jython to work with test_socket. Message-ID: Patch #103667 has been updated. Project: python Category: None Status: Open Submitted by: bckfnn Assigned to : bwarsaw Summary: Allow jython to work with test_socket. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103667&group_id=5470 From noreply@sourceforge.net Thu Feb 15 13:25:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 05:25:02 -0800 Subject: [Patches] [Patch #103679] AIX and BeOS build quirk revisions Message-ID: Patch #103679 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : gvanrossum Summary: AIX and BeOS build quirk revisions ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103679&group_id=5470 From noreply@sourceforge.net Thu Feb 15 13:25:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 05:25:03 -0800 Subject: [Patches] [Patch #103680] small change to ld_so_beos (apply after 103679) Message-ID: Patch #103680 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : gvanrossum Summary: small change to ld_so_beos (apply after 103679) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103680&group_id=5470 From noreply@sourceforge.net Thu Feb 15 13:25:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 05:25:03 -0800 Subject: [Patches] [Patch #103681] Remove grammar rule from Makefile Message-ID: Patch #103681 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : gvanrossum Summary: Remove grammar rule from Makefile ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103681&group_id=5470 From noreply@sourceforge.net Thu Feb 15 13:25:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 05:25:02 -0800 Subject: [Patches] [Patch #103642] BeOS dislikes import tempfile in _execvpe() Message-ID: Patch #103642 has been updated. Project: python Category: None Status: Open Submitted by: donnc Assigned to : gvanrossum Summary: BeOS dislikes import tempfile in _execvpe() ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103642&group_id=5470 From noreply@sourceforge.net Thu Feb 15 13:25:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 05:25:12 -0800 Subject: [Patches] [Patch #103516] zipfile.py: use hex constants for magic numbers Message-ID: Patch #103516 has been updated. Project: python Category: library Status: Open Submitted by: mfx Assigned to : fdrake Summary: zipfile.py: use hex constants for magic numbers ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103516&group_id=5470 From noreply@sourceforge.net Thu Feb 15 13:25:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 05:25:33 -0800 Subject: [Patches] [Patch #103517] ftplib.py: provide a default blocksize arg in storbinary Message-ID: Patch #103517 has been updated. Project: python Category: library Status: Open Submitted by: mfx Assigned to : gvanrossum Summary: ftplib.py: provide a default blocksize arg in storbinary ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103517&group_id=5470 From noreply@sourceforge.net Thu Feb 15 13:25:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 05:25:34 -0800 Subject: [Patches] [Patch #103640] incomplete proxy handling in URLLIB Message-ID: Patch #103640 has been updated. Project: python Category: library Status: Open Submitted by: nobody Assigned to : gvanrossum Summary: incomplete proxy handling in URLLIB ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103640&group_id=5470 From noreply@sourceforge.net Thu Feb 15 13:25:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 05:25:35 -0800 Subject: [Patches] [Patch #103757] catch server recursion in urrlib Message-ID: Patch #103757 has been updated. Project: python Category: library Status: Open Submitted by: montanaro Assigned to : gvanrossum Summary: catch server recursion in urrlib ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103757&group_id=5470 From noreply@sourceforge.net Thu Feb 15 13:25:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 05:25:46 -0800 Subject: [Patches] [Patch #103782] Clarify "altinstall" Installation Instructions Message-ID: Patch #103782 has been updated. Project: python Category: Build Status: Open Submitted by: kbk Assigned to : nascheme Summary: Clarify "altinstall" Installation Instructions Follow-Ups: Date: 2001-Feb-14 09:20 By: kbk Comment: Added comment to README regarding installing beta versions without overwriting the previous one. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103782&group_id=5470 From noreply@sourceforge.net Thu Feb 15 13:25:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 05:25:56 -0800 Subject: [Patches] [Patch #103789] Add support to zipfile for passing file-like objects Message-ID: Patch #103789 has been updated. Project: python Category: Modules Status: Open Submitted by: itamar Assigned to : fdrake Summary: Add support to zipfile for passing file-like objects Follow-Ups: Date: 2001-Feb-14 05:26 By: itamar Comment: Right now I detect file-like objects by doing hasattr(file, "read"). Doing hasattr(file, "write") might be better though, since for mode="w" ZipFiles, all you need are write() and tell() methods on the file-like object. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103789&group_id=5470 From noreply@sourceforge.net Thu Feb 15 13:26:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 05:26:36 -0800 Subject: [Patches] [Patch #103804] fixes setup.py to look for xmlparse.h in the correct place Message-ID: Patch #103804 has been updated. Project: python Category: Build Status: Open Submitted by: ajseward Assigned to : akuchling Summary: fixes setup.py to look for xmlparse.h in the correct place Follow-Ups: Date: 2001-Feb-14 17:23 By: ajseward Comment: Sorry, this was caused by another patch that I had not looked at closely enough. There is no problem in the CVS source. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103804&group_id=5470 From noreply@sourceforge.net Thu Feb 15 13:42:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 05:42:11 -0800 Subject: [Patches] [Patch #103154] Cygwin Check Import Case Patch Message-ID: Patch #103154 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: jlt63 Assigned to : gvanrossum Summary: Cygwin Check Import Case Patch Follow-Ups: Date: 2001-Feb-15 05:42 By: gvanrossum Comment: Closed again; Tim is on this issue, see python-dev. ------------------------------------------------------- Date: 2001-Jan-21 19:00 By: jlt63 Comment: My intentions when I asked you to reopen this patch were to determine whether consensus was reached on how to resolve this issue, not to provoke you in any way. If I did, then I apologize. From your previous comments, it was not clear that you opposed this patch. Now that I know, I will desist with this approach. I'm willing to do as you suggest, but I have the following concerns: 1. At least two more modules that will need this conversion too (i.e., FCNTL and SOCKET). Are there more? 2. Unless there is some (enforceable) policy that module names cannot differ only in case, then Cygwin Python will behave differently than other UNIX versions in this regard. Can you allay my concerns before I set out on this endeavor. BTW, when is 2.1a2 scheduled so I know how much time that I have? ------------------------------------------------------- Date: 2001-Jan-20 11:33 By: gvanrossum Comment: Indeed, it's too late for 2.1a1 (now planned for Monday 1/22), but not for 2.1a2. It would be much more productive if you spent your time on adding the termios constants to that module, than lobbying for a hack that I oppose. ------------------------------------------------------- Date: 2001-Jan-20 11:07 By: jlt63 Comment: Skip Montanaro and yourself (at least initially) suggested that this problem should be solved by renaming the modules in question (e.g., TERMIOS) so that they are unique regardless of case. As a following up, you suggested that "An even better solution is to get rid of those generated headers and incorporate the desired symbols directly in the C extension modules." If neither of the two solutions will make it into 2.1a, then I will lobby for the acceptance of my (albeit hacky) patch. It will only affect Cygwin Python and makes it behave identical to other UNIX versions. When a better solution is finally implemented, then the Cygwin cruft can be ripped out. ------------------------------------------------------- Date: 2001-Jan-20 08:47 By: gvanrossum Comment: Reopened at request. But I won't *do* anything about this until I've heard the arguments one more time. ------------------------------------------------------- Date: 2001-Jan-19 22:59 By: jlt63 Comment: Please reopen so that this issue is not accidentally overlooked. At least, until the case sensitive import problem is resolved. I still have a pending patch submitted for consideration. Sorry, to be a pest... ------------------------------------------------------- Date: 2001-Jan-12 11:48 By: tim_one Comment: Ah, I see. There's a difference between Windows filesystems and filesystems used on Windows . Older Novell network fileservers for Windows do indeed destroy the case of file names, and newer ones are often configured in a compatability mode to keep on doing that. At my last employer, more than half the LAN servers were set up that way. Use of PYTHONCASEOK was universal as a result. We were also screwed in that one of the popular Windows source-control systems *also* destroyed case (I didn't use that, and have forgotten the name): check in OhNo.py, check out OHNO.PY. Brrrrrrrrr. ------------------------------------------------------- Date: 2001-Jan-12 10:52 By: gvanrossum Comment: Maybe things are different now. But I definitely remember that when I introduced this test, Mark Hammond told me that there was a popular networking filesystem that didn't preserve case. This was either for Windows NT or Windows 95, so it's not a Windows 3.1 thing (although it's possible that the fileserver in question was a bad port from DOS or Windows 3.1 of course). ------------------------------------------------------- Date: 2001-Jan-12 10:47 By: jlt63 Comment: I know. I was just confused by the following On 2001-Jan-11 06:47, gvanrossum wrote: > Note that I believe that "import termios, TERMIOS" *should fail* -- not all > filesystems used on Windows are case preserving. ------------------------------------------------------- Date: 2001-Jan-12 10:26 By: tim_one Comment: The filesystems do preserve the case of names. But all platform file *lookup* APIs are case-insensitive. ------------------------------------------------------- Date: 2001-Jan-12 09:50 By: jlt63 Comment: Oops... Use the following procedure to patch: $ cd Python $ # save case.patch to current directory $ patch * acconfig.h: Add CHECK_IMPORT_CASE #undef. * configure.in: Add --with-check-import-case section. * Python/import.c: Enable case checking code for Cygwin too. Include sys/cygwin.h, if appropriate. (check_case): Add munging of module path from POSIX to Win32 so FindFirstFile() can cope, if appropriate. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103154&group_id=5470 From noreply@sourceforge.net Thu Feb 15 13:43:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 05:43:10 -0800 Subject: [Patches] [Patch #103681] Remove grammar rule from Makefile Message-ID: Patch #103681 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : nascheme Summary: Remove grammar rule from Makefile ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103681&group_id=5470 From noreply@sourceforge.net Thu Feb 15 13:45:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 05:45:54 -0800 Subject: [Patches] [Patch #103757] catch server recursion in urrlib Message-ID: Patch #103757 has been updated. Project: python Category: library Status: Accepted Submitted by: montanaro Assigned to : montanaro Summary: catch server recursion in urrlib Follow-Ups: Date: 2001-Feb-15 05:45 By: gvanrossum Comment: Looks good to me. Check it in! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103757&group_id=5470 From noreply@sourceforge.net Thu Feb 15 13:48:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 05:48:08 -0800 Subject: [Patches] [Patch #101970] Generate more modern file:///C:/foo/bar syntax Message-ID: Patch #101970 has been updated. Project: python Category: library Status: Accepted Submitted by: prescod Assigned to : prescod Summary: Generate more modern file:///C:/foo/bar syntax Follow-Ups: Date: 2001-Feb-15 05:48 By: gvanrossum Comment: Looks good now. Please check it in! ------------------------------------------------------- Date: 2001-Jan-24 22:54 By: prescod Comment: Sorry. I must have been drunk when I submitted the first time. :( This patch is better and has an updated docstring. Here's the intent: Newer Windows browsers use the colon to represent the colon instead of the pipe symbol. Therefore, the colon replacement character is an optional argument. If you care about the colon replacement then you should specify it explicitly because the default may change in the future. --- Teaching urllib to accept various forms of Windows file URLs for conversion to (instead of from) pathnames is a whole other science project...but being able to generate URLs suitable for a browser is a good first step. (I'll be on vacation after sending this so discussion will have to wait until I return) ------------------------------------------------------- Date: 2001-Jan-19 14:59 By: gvanrossum Comment: Paul, if you're not interested in this any more, I'll just reject it, OK? ------------------------------------------------------- Date: 2001-Jan-04 07:46 By: gvanrossum Comment: This patch should be rejected based on form. Paul, you can do better than sending in a diff without context! Also, the subject makes no sense. If you still want this, please fix the subject and submit a new patch and we'll lookj at it again. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101970&group_id=5470 From noreply@sourceforge.net Thu Feb 15 13:49:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 05:49:36 -0800 Subject: [Patches] [Patch #103693] tupleobject.c: implement tuple.index() and tuple.count() Message-ID: Patch #103693 has been updated. Project: python Category: core (C code) Status: Closed Submitted by: mfx Assigned to : gvanrossum Summary: tupleobject.c: implement tuple.index() and tuple.count() Follow-Ups: Date: 2001-Feb-15 05:49 By: gvanrossum Comment: Why bother? I like the fact that when you want to do list-ish things you have to use lists. Use list(t).count(x) if you really want this for a tuple. I'm rejecting this in the name of all those users who want Python to be small. ------------------------------------------------------- Date: 2001-Feb-09 16:13 By: jhylton Comment: interested in adding this to 2.1? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103693&group_id=5470 From noreply@sourceforge.net Thu Feb 15 13:51:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 05:51:16 -0800 Subject: [Patches] [Patch #103517] ftplib.py: provide a default blocksize arg in storbinary Message-ID: Patch #103517 has been updated. Project: python Category: library Status: Closed Submitted by: mfx Assigned to : gvanrossum Summary: ftplib.py: provide a default blocksize arg in storbinary Follow-Ups: Date: 2001-Feb-15 05:51 By: gvanrossum Comment: Good idea! Done. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103517&group_id=5470 From noreply@sourceforge.net Thu Feb 15 13:55:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 05:55:29 -0800 Subject: [Patches] [Patch #103679] AIX and BeOS build quirk revisions Message-ID: Patch #103679 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : nascheme Summary: AIX and BeOS build quirk revisions ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103679&group_id=5470 From noreply@sourceforge.net Thu Feb 15 13:56:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 05:56:20 -0800 Subject: [Patches] [Patch #103680] small change to ld_so_beos (apply after 103679) Message-ID: Patch #103680 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : nascheme Summary: small change to ld_so_beos (apply after 103679) ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103680&group_id=5470 From noreply@sourceforge.net Thu Feb 15 16:57:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 08:57:22 -0800 Subject: [Patches] [Patch #103757] catch server recursion in urrlib Message-ID: Patch #103757 has been updated. Project: python Category: library Status: Closed Submitted by: montanaro Assigned to : montanaro Summary: catch server recursion in urrlib Follow-Ups: Date: 2001-Feb-15 08:57 By: montanaro Comment: checked in (v. 1.117) ------------------------------------------------------- Date: 2001-Feb-15 05:45 By: gvanrossum Comment: Looks good to me. Check it in! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103757&group_id=5470 From noreply@sourceforge.net Thu Feb 15 17:00:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 09:00:03 -0800 Subject: [Patches] [Patch #103511] robotparser.py: fix for top-level web names Message-ID: Patch #103511 has been updated. Project: python Category: library Status: Closed Submitted by: dcohen Assigned to : montanaro Summary: robotparser.py: fix for top-level web names Follow-Ups: Date: 2001-Feb-15 09:00 By: montanaro Comment: fixed by a similar change to the new version of the robotparser module. ------------------------------------------------------- Date: 2001-Jan-30 22:39 By: montanaro Comment: Assigned to me. Looks pretty straightforward (so he says)... ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103511&group_id=5470 From noreply@sourceforge.net Thu Feb 15 17:13:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 09:13:47 -0800 Subject: [Patches] [Patch #103808] doctest.py docs Message-ID: Patch #103808 has been updated. Project: python Category: documentation Status: Open Submitted by: tim_one Assigned to : fdrake Summary: doctest.py docs Follow-Ups: Date: 2001-Feb-15 09:13 By: moshez Comment: Fred, the LaTeX compiled and looked OK in the .dvi version. Haven't tried compiling HTML -- no time for setting up the support :( Assigning to you for cleanup. ------------------------------------------------------- Date: 2001-Feb-15 04:12 By: fdrake Comment: Moshe, do you have time to LaTeXify this? Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103808&group_id=5470 From noreply@sourceforge.net Thu Feb 15 18:24:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 10:24:48 -0800 Subject: [Patches] [Patch #103679] AIX and BeOS build quirk revisions Message-ID: Patch #103679 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : nascheme Summary: AIX and BeOS build quirk revisions Follow-Ups: Date: 2001-Feb-15 10:24 By: donnc Comment: An alert reader brought to my attention, I appear to have converted to CRLF line endings when I pasted this patch in, so it applies better after a tr -d '\015' or similar. Will be happy to resubmit better copies of this and the other couple of patches I botched the same way, if it's a problem at all. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103679&group_id=5470 From noreply@sourceforge.net Fri Feb 16 03:25:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 19:25:33 -0800 Subject: [Patches] [Patch #103679] AIX and BeOS build quirk revisions Message-ID: Patch #103679 has been updated. Project: python Category: Build Status: Closed Submitted by: donnc Assigned to : nobody Summary: AIX and BeOS build quirk revisions Follow-Ups: Date: 2001-Feb-15 10:24 By: donnc Comment: An alert reader brought to my attention, I appear to have converted to CRLF line endings when I pasted this patch in, so it applies better after a tr -d '\015' or similar. Will be happy to resubmit better copies of this and the other couple of patches I botched the same way, if it's a problem at all. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103679&group_id=5470 From noreply@sourceforge.net Fri Feb 16 03:28:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 19:28:00 -0800 Subject: [Patches] [Patch #103680] small change to ld_so_beos (apply after 103679) Message-ID: Patch #103680 has been updated. Project: python Category: Build Status: Closed Submitted by: donnc Assigned to : nobody Summary: small change to ld_so_beos (apply after 103679) Follow-Ups: Date: 2001-Feb-15 19:28 By: nascheme Comment: Applied. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103680&group_id=5470 From noreply@sourceforge.net Fri Feb 16 04:14:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 20:14:42 -0800 Subject: [Patches] [Patch #103681] Remove grammar rule from Makefile Message-ID: Patch #103681 has been updated. Project: python Category: Build Status: Rejected Submitted by: donnc Assigned to : nobody Summary: Remove grammar rule from Makefile Follow-Ups: Date: 2001-Feb-15 20:14 By: nascheme Comment: I've checked in, IMHO, a better solution. The grammar source files are now generated in the build directory. If this doesn't work for a read-only source dir please let me know. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103681&group_id=5470 From noreply@sourceforge.net Fri Feb 16 04:22:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 20:22:05 -0800 Subject: [Patches] [Patch #103782] Clarify "altinstall" Installation Instructions Message-ID: Patch #103782 has been updated. Project: python Category: Build Status: Closed Submitted by: kbk Assigned to : nobody Summary: Clarify "altinstall" Installation Instructions Follow-Ups: Date: 2001-Feb-15 20:22 By: nascheme Comment: Applied. ------------------------------------------------------- Date: 2001-Feb-14 09:20 By: kbk Comment: Added comment to README regarding installing beta versions without overwriting the previous one. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103782&group_id=5470 From noreply@sourceforge.net Fri Feb 16 06:41:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Feb 2001 22:41:58 -0800 Subject: [Patches] [Patch #103808] doctest.py docs Message-ID: Patch #103808 has been updated. Project: python Category: documentation Status: Open Submitted by: tim_one Assigned to : fdrake Summary: doctest.py docs Follow-Ups: Date: 2001-Feb-15 22:41 By: tim_one Comment: Thank you, Moshe! I don't think I'll ever grasp the difference between the appropriate use of "code" and "var" markups (e.g., \var{(f, t)}?). The "I" in "I/2.**J" got dropped on the floor. Probably needs "added in 2.1" markup. Will look it over more carefully after it's in HTML form I can actually read . ------------------------------------------------------- Date: 2001-Feb-15 09:13 By: moshez Comment: Fred, the LaTeX compiled and looked OK in the .dvi version. Haven't tried compiling HTML -- no time for setting up the support :( Assigning to you for cleanup. ------------------------------------------------------- Date: 2001-Feb-15 04:12 By: fdrake Comment: Moshe, do you have time to LaTeXify this? Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103808&group_id=5470 From noreply@sourceforge.net Fri Feb 16 08:21:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Feb 2001 00:21:38 -0800 Subject: [Patches] [Patch #103693] tupleobject.c: implement tuple.index() and tuple.count() Message-ID: Patch #103693 has been updated. Project: python Category: core (C code) Status: Rejected Submitted by: mfx Assigned to : nobody Summary: tupleobject.c: implement tuple.index() and tuple.count() Follow-Ups: Date: 2001-Feb-16 00:21 By: tim_one Comment: Changed Status from Closed to Rejected, and assigned to None, in accord with rejection procedure. ------------------------------------------------------- Date: 2001-Feb-15 05:49 By: gvanrossum Comment: Why bother? I like the fact that when you want to do list-ish things you have to use lists. Use list(t).count(x) if you really want this for a tuple. I'm rejecting this in the name of all those users who want Python to be small. ------------------------------------------------------- Date: 2001-Feb-09 16:13 By: jhylton Comment: interested in adding this to 2.1? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103693&group_id=5470 From noreply@sourceforge.net Fri Feb 16 15:14:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Feb 2001 07:14:33 -0800 Subject: [Patches] [Patch #103839] sgmllib: Allow ';' in attributes Message-ID: Patch #103839 has been updated. Project: python Category: library Status: Open Submitted by: dougfort Assigned to : nobody Summary: sgmllib: Allow ';' in attributes ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103839&group_id=5470 From noreply@sourceforge.net Sat Feb 17 04:36:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Feb 2001 20:36:13 -0800 Subject: [Patches] [Patch #103854] Check Node class in minidom Message-ID: Patch #103854 has been updated. Project: python Category: XML Status: Open Submitted by: akuchling Assigned to : nobody Summary: Check Node class in minidom ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103854&group_id=5470 From noreply@sourceforge.net Sat Feb 17 04:37:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Feb 2001 20:37:33 -0800 Subject: [Patches] [Patch #103854] Check Node class in minidom Message-ID: Patch #103854 has been updated. Project: python Category: XML Status: Open Submitted by: akuchling Assigned to : loewis Summary: Check Node class in minidom ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103854&group_id=5470 From noreply@sourceforge.net Sat Feb 17 05:10:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Feb 2001 21:10:07 -0800 Subject: [Patches] [Patch #103373] zlib sync-flush fix Message-ID: Patch #103373 has been updated. Project: python Category: Modules Status: Open Submitted by: abo Assigned to : akuchling Summary: zlib sync-flush fix Follow-Ups: Date: 2001-Feb-16 21:10 By: akuchling Comment: Can you provide a test program that will demonstrate some of the bugs this patch fixes? I'd like to be able to do a before-and-after comparison. ------------------------------------------------------- Date: 2001-Jan-23 08:26 By: nobody Comment: Argh... my line by line fix list got munged. You'll have to apply imaginary comments to delimit each fix. The bug this fixes is 124981 "zlib decompress of sync-flushed data fails" A lot of the patch changes are simply whitespace changes to clean up the formating. The patch can probably be edited to only include the changes to the PyZlib_objdecompress routine to fix the most important bug, but this would leave the code even more inconsistant than it is. Most of the rest of the fixes are to make the other routines cleaner, though they do also fix the minor bugs mentioned. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103373&group_id=5470 From noreply@sourceforge.net Sat Feb 17 05:24:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Feb 2001 21:24:17 -0800 Subject: [Patches] [Patch #103808] doctest.py docs Message-ID: Patch #103808 has been updated. Project: python Category: documentation Status: Accepted Submitted by: tim_one Assigned to : moshez Summary: doctest.py docs Follow-Ups: Date: 2001-Feb-16 21:24 By: fdrake Comment: Program options (such as -v in this context) should be marked with \programopt. Names of global variables (such as __test__) should be marked with \code. I'm sure there are other items I should mention, but I'll go through it in much more detail after you check it in. Oh, you should go ahead and check it in as Doc/lib/libdoctest.tex. Thanks! ------------------------------------------------------- Date: 2001-Feb-15 22:41 By: tim_one Comment: Thank you, Moshe! I don't think I'll ever grasp the difference between the appropriate use of "code" and "var" markups (e.g., \var{(f, t)}?). The "I" in "I/2.**J" got dropped on the floor. Probably needs "added in 2.1" markup. Will look it over more carefully after it's in HTML form I can actually read . ------------------------------------------------------- Date: 2001-Feb-15 09:13 By: moshez Comment: Fred, the LaTeX compiled and looked OK in the .dvi version. Haven't tried compiling HTML -- no time for setting up the support :( Assigning to you for cleanup. ------------------------------------------------------- Date: 2001-Feb-15 04:12 By: fdrake Comment: Moshe, do you have time to LaTeXify this? Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103808&group_id=5470 From noreply@sourceforge.net Sat Feb 17 05:41:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Feb 2001 21:41:33 -0800 Subject: [Patches] [Patch #103495] case sensitive import for case insensitive FileSystem Message-ID: Patch #103495 has been updated. Project: python Category: core (C code) Status: Open Submitted by: sdm7g Assigned to : bwarsaw Summary: case sensitive import for case insensitive FileSystem Follow-Ups: Date: 2001-Feb-16 21:41 By: tim_one Comment: Reassigning to Barry since he marked it Accepted, and changing it to Open because I *think* it's already been applied. Barry, if you did apply it, mark it as Closed. ------------------------------------------------------- Date: 2001-Feb-02 11:09 By: bwarsaw Comment: Whoops! Marking as accepted. ------------------------------------------------------- Date: 2001-Feb-02 11:08 By: bwarsaw Comment: Here's a version of the patch that applies cleanly to the 2.1a2 source, conforms to C coding styles, and builds on Linux RH 6.1. It passes regrtest and "import getpass" (termios/TERMIOS). I cannot test it on any other platform. I'm marking this as accepted and commiting it to the 2.1a2 tree. Once other platforms have verified that it works for them, we can close the patch. ------------------------------------------------------- Date: 2001-Feb-01 06:47 By: jlt63 Comment: Scratch the comment about the bug -- I've too much C++ on the head to think in straight C anymore. ------------------------------------------------------- Date: 2001-Jan-31 18:20 By: jlt63 Comment: Guido, Do you find the style of this patch more acceptable than mine (103154)? If so, would you consider including a cleaned up version into 2.1a2? Note that I have found one bug (MatchFilename() does not handle a NULL pathname correctly) and the code should probably be enabled on something more specific than HAVE_DIRENT_H (e.g., platform #defs, UNIX_STYLE_CHECK_IMPORT_CASE, etc). ------------------------------------------------------- Date: 2001-Jan-29 20:30 By: sdm7g Comment: Oops! The previous patch crashes if the path is empty, which is the case for the current directory. Added a line to check for that and use "." instead on diropen. -- Steve M. ------------------------------------------------------- Date: 2001-Jan-29 20:27 By: sdm7g Comment: Oops! The previous patch crashes if the path is empty, which is the case for the current directory. Added a line to check for that and use "." instead on diropen. -- Steve M. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103495&group_id=5470 From noreply@sourceforge.net Sat Feb 17 05:59:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Feb 2001 21:59:07 -0800 Subject: [Patches] [Patch #103808] doctest.py docs Message-ID: Patch #103808 has been updated. Project: python Category: documentation Status: Closed Submitted by: tim_one Assigned to : moshez Summary: doctest.py docs Follow-Ups: Date: 2001-Feb-16 21:59 By: tim_one Comment: Checked in, marked Closed. ------------------------------------------------------- Date: 2001-Feb-16 21:24 By: fdrake Comment: Program options (such as -v in this context) should be marked with \programopt. Names of global variables (such as __test__) should be marked with \code. I'm sure there are other items I should mention, but I'll go through it in much more detail after you check it in. Oh, you should go ahead and check it in as Doc/lib/libdoctest.tex. Thanks! ------------------------------------------------------- Date: 2001-Feb-15 22:41 By: tim_one Comment: Thank you, Moshe! I don't think I'll ever grasp the difference between the appropriate use of "code" and "var" markups (e.g., \var{(f, t)}?). The "I" in "I/2.**J" got dropped on the floor. Probably needs "added in 2.1" markup. Will look it over more carefully after it's in HTML form I can actually read . ------------------------------------------------------- Date: 2001-Feb-15 09:13 By: moshez Comment: Fred, the LaTeX compiled and looked OK in the .dvi version. Haven't tried compiling HTML -- no time for setting up the support :( Assigning to you for cleanup. ------------------------------------------------------- Date: 2001-Feb-15 04:12 By: fdrake Comment: Moshe, do you have time to LaTeXify this? Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103808&group_id=5470 From noreply@sourceforge.net Sat Feb 17 09:55:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 17 Feb 2001 01:55:20 -0800 Subject: [Patches] [Patch #103373] zlib sync-flush fix Message-ID: Patch #103373 has been updated. Project: python Category: Modules Status: Open Submitted by: abo Assigned to : akuchling Summary: zlib sync-flush fix Follow-Ups: Date: 2001-Feb-17 01:55 By: abo Comment: There is an example program that triggers the main "sync-flush" bug attached to the bug report (I forget the id, but its fairly clearly labled in bug-tracking). As for the others, it's quite hard to actualy trigger some of these, and some of them are violations of the zlib interface that may or may not actualy cause problems with the current version of zlib. I'll go through them in detail now; Avoid repeat calls to (in|de)flateEnd: possably causes no problems with current version of zlib, but might in future releases. I haven't tested it, but if you really want I could whip something up that tests it. Raises exception when allocating unused_data fails, fixes memory leak when allocating unused_data fails, raises exception when allocating decompress data failes; These are all only tiggerable when memory allocation fails. Removes vistigial code from decompress flush; the fix to the main "sync-flush" bug ensures that decompress always returns all available data. This means that the decompress flush() can be simplified. tidies code etc; these are just code cleanups... ------------------------------------------------------- Date: 2001-Feb-16 21:10 By: akuchling Comment: Can you provide a test program that will demonstrate some of the bugs this patch fixes? I'd like to be able to do a before-and-after comparison. ------------------------------------------------------- Date: 2001-Jan-23 08:26 By: nobody Comment: Argh... my line by line fix list got munged. You'll have to apply imaginary comments to delimit each fix. The bug this fixes is 124981 "zlib decompress of sync-flushed data fails" A lot of the patch changes are simply whitespace changes to clean up the formating. The patch can probably be edited to only include the changes to the PyZlib_objdecompress routine to fix the most important bug, but this would leave the code even more inconsistant than it is. Most of the rest of the fixes are to make the other routines cleaner, though they do also fix the minor bugs mentioned. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103373&group_id=5470 From noreply@sourceforge.net Sun Feb 18 00:35:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 17 Feb 2001 16:35:29 -0800 Subject: [Patches] [Patch #103864] 2.1a2 has minor bug in "make clean" target: BugID 132879 Message-ID: Patch #103864 has been updated. Project: python Category: Build Status: Open Submitted by: mfavas Assigned to : nobody Summary: 2.1a2 has minor bug in "make clean" target: BugID 132879 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103864&group_id=5470 From noreply@sourceforge.net Sun Feb 18 00:48:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 17 Feb 2001 16:48:24 -0800 Subject: [Patches] [Patch #103865] BugID 132783 - alllow extensions to build under Solaris8/gcc Message-ID: Patch #103865 has been updated. Project: python Category: Build Status: Open Submitted by: mfavas Assigned to : nobody Summary: BugID 132783 - alllow extensions to build under Solaris8/gcc ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103865&group_id=5470 From noreply@sourceforge.net Sun Feb 18 21:58:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Feb 2001 13:58:53 -0800 Subject: [Patches] [Patch #103868] Add better default compiler support Message-ID: Patch #103868 has been updated. Project: python Category: distutils Status: Open Submitted by: lemburg Assigned to : nobody Summary: Add better default compiler support ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103868&group_id=5470 From noreply@sourceforge.net Sun Feb 18 22:00:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Feb 2001 14:00:44 -0800 Subject: [Patches] [Patch #103868] Add better default compiler support Message-ID: Patch #103868 has been updated. Project: python Category: distutils Status: Open Submitted by: lemburg Assigned to : nobody Summary: Add better default compiler support Follow-Ups: Date: 2001-Feb-18 14:00 By: lemburg Comment: Assigning to Andrew for review. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103868&group_id=5470 From noreply@sourceforge.net Sun Feb 18 22:01:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Feb 2001 14:01:33 -0800 Subject: [Patches] [Patch #103868] Add better default compiler support Message-ID: Patch #103868 has been updated. Project: python Category: distutils Status: Open Submitted by: lemburg Assigned to : akuchling Summary: Add better default compiler support Follow-Ups: Date: 2001-Feb-18 14:01 By: lemburg Comment: Assigned to Andrew for review. ------------------------------------------------------- Date: 2001-Feb-18 14:00 By: lemburg Comment: Assigning to Andrew for review. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103868&group_id=5470 From noreply@sourceforge.net Sun Feb 18 22:22:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Feb 2001 14:22:50 -0800 Subject: [Patches] [Patch #103868] Add better default compiler support Message-ID: Patch #103868 has been updated. Project: python Category: distutils Status: Open Submitted by: lemburg Assigned to : akuchling Summary: Add better default compiler support Follow-Ups: Date: 2001-Feb-18 14:22 By: akuchling Comment: Can you convince me why a regular expression match is required, instead of just normalizing sys.platform ('cygwin/1.14' -> 'cygwin') and continuing to use a dictionary? (Does sys.platform actually include a version number on Cygwin? Wonder if that's a good idea?) ------------------------------------------------------- Date: 2001-Feb-18 14:01 By: lemburg Comment: Assigned to Andrew for review. ------------------------------------------------------- Date: 2001-Feb-18 14:00 By: lemburg Comment: Assigning to Andrew for review. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103868&group_id=5470 From noreply@sourceforge.net Sun Feb 18 22:26:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Feb 2001 14:26:16 -0800 Subject: [Patches] [Patch #103804] fixes setup.py to look for xmlparse.h in the correct place Message-ID: Patch #103804 has been updated. Project: python Category: Build Status: Closed Submitted by: ajseward Assigned to : akuchling Summary: fixes setup.py to look for xmlparse.h in the correct place Follow-Ups: Date: 2001-Feb-18 14:26 By: akuchling Comment: Marking as closed. ------------------------------------------------------- Date: 2001-Feb-14 17:23 By: ajseward Comment: Sorry, this was caused by another patch that I had not looked at closely enough. There is no problem in the CVS source. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103804&group_id=5470 From noreply@sourceforge.net Sun Feb 18 22:28:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Feb 2001 14:28:23 -0800 Subject: [Patches] [Patch #103868] Add better default compiler support Message-ID: Patch #103868 has been updated. Project: python Category: distutils Status: Open Submitted by: lemburg Assigned to : akuchling Summary: Add better default compiler support Follow-Ups: Date: 2001-Feb-18 14:28 By: lemburg Comment: The RE-match will provide the best forward compatibility and yes, cygwin's sys.platform does include the OS-type and cygwin version: cygwin_nt-5.01, cygwin_98-4.101 Since distutils is an installer and in no way performance sensitive, I think that flexibility is more important than dictionary lookup speed. ------------------------------------------------------- Date: 2001-Feb-18 14:22 By: akuchling Comment: Can you convince me why a regular expression match is required, instead of just normalizing sys.platform ('cygwin/1.14' -> 'cygwin') and continuing to use a dictionary? (Does sys.platform actually include a version number on Cygwin? Wonder if that's a good idea?) ------------------------------------------------------- Date: 2001-Feb-18 14:01 By: lemburg Comment: Assigned to Andrew for review. ------------------------------------------------------- Date: 2001-Feb-18 14:00 By: lemburg Comment: Assigning to Andrew for review. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103868&group_id=5470 From noreply@sourceforge.net Sun Feb 18 22:47:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Feb 2001 14:47:46 -0800 Subject: [Patches] [Patch #103868] Add better default compiler support Message-ID: Patch #103868 has been updated. Project: python Category: distutils Status: Accepted Submitted by: lemburg Assigned to : akuchling Summary: Add better default compiler support Follow-Ups: Date: 2001-Feb-18 14:47 By: akuchling Comment: OK; approved, then. I'd suggest turning the dictionary into a list of 2-tuples, then. ------------------------------------------------------- Date: 2001-Feb-18 14:28 By: lemburg Comment: The RE-match will provide the best forward compatibility and yes, cygwin's sys.platform does include the OS-type and cygwin version: cygwin_nt-5.01, cygwin_98-4.101 Since distutils is an installer and in no way performance sensitive, I think that flexibility is more important than dictionary lookup speed. ------------------------------------------------------- Date: 2001-Feb-18 14:22 By: akuchling Comment: Can you convince me why a regular expression match is required, instead of just normalizing sys.platform ('cygwin/1.14' -> 'cygwin') and continuing to use a dictionary? (Does sys.platform actually include a version number on Cygwin? Wonder if that's a good idea?) ------------------------------------------------------- Date: 2001-Feb-18 14:01 By: lemburg Comment: Assigned to Andrew for review. ------------------------------------------------------- Date: 2001-Feb-18 14:00 By: lemburg Comment: Assigning to Andrew for review. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103868&group_id=5470 From noreply@sourceforge.net Mon Feb 19 04:01:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Feb 2001 20:01:50 -0800 Subject: [Patches] [Patch #103871] self.fp not defined in class ZipFile for non-existing file Message-ID: Patch #103871 has been updated. Project: python Category: None Status: Open Submitted by: dkuhlman2 Assigned to : nobody Summary: self.fp not defined in class ZipFile for non-existing file ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103871&group_id=5470 From noreply@sourceforge.net Mon Feb 19 04:41:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Feb 2001 20:41:24 -0800 Subject: [Patches] [Patch #103864] 2.1a2 has minor bug in "make clean" target: BugID 132879 Message-ID: Patch #103864 has been updated. Project: python Category: Build Status: Closed Submitted by: mfavas Assigned to : nobody Summary: 2.1a2 has minor bug in "make clean" target: BugID 132879 Follow-Ups: Date: 2001-Feb-18 20:41 By: nascheme Comment: Checked in a different solution (r1.21 of Makefile.pre.in). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103864&group_id=5470 From noreply@sourceforge.net Mon Feb 19 04:47:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Feb 2001 20:47:58 -0800 Subject: [Patches] [Patch #103655] configure changes for Solaris Message-ID: Patch #103655 has been updated. Project: python Category: Build Status: Closed Submitted by: sgriggs Assigned to : nobody Summary: configure changes for Solaris Follow-Ups: Date: 2001-Feb-18 20:47 By: nascheme Comment: Checked in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103655&group_id=5470 From noreply@sourceforge.net Mon Feb 19 04:49:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Feb 2001 20:49:49 -0800 Subject: [Patches] [Patch #103656] configure.in changes for Solaris Message-ID: Patch #103656 has been updated. Project: python Category: Build Status: Closed Submitted by: sgriggs Assigned to : nobody Summary: configure.in changes for Solaris Follow-Ups: Date: 2001-Feb-18 20:49 By: nascheme Comment: Checked in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103656&group_id=5470 From noreply@sourceforge.net Mon Feb 19 04:53:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 18 Feb 2001 20:53:02 -0800 Subject: [Patches] [Patch #103865] BugID 132783 - alllow extensions to build under Solaris8/gcc Message-ID: Patch #103865 has been updated. Project: python Category: Build Status: Closed Submitted by: mfavas Assigned to : nobody Summary: BugID 132783 - alllow extensions to build under Solaris8/gcc Follow-Ups: Date: 2001-Feb-18 20:53 By: nascheme Comment: Checked in. I pretty sure that -fPIC should always be used instead of -fpic. On some platforms it doesn't matter though. I'm leaving things alone until someone on those platforms complains. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103865&group_id=5470 From noreply@sourceforge.net Mon Feb 19 09:20:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Feb 2001 01:20:19 -0800 Subject: [Patches] [Patch #103868] Add better default compiler support Message-ID: Patch #103868 has been updated. Project: python Category: distutils Status: Closed Submitted by: lemburg Assigned to : akuchling Summary: Add better default compiler support Follow-Ups: Date: 2001-Feb-19 01:20 By: lemburg Comment: Checked in a slightly modified patch which uses tuples instead of a dictionary. Also made the global a module-private variable by prepending an underscore. ------------------------------------------------------- Date: 2001-Feb-18 14:47 By: akuchling Comment: OK; approved, then. I'd suggest turning the dictionary into a list of 2-tuples, then. ------------------------------------------------------- Date: 2001-Feb-18 14:28 By: lemburg Comment: The RE-match will provide the best forward compatibility and yes, cygwin's sys.platform does include the OS-type and cygwin version: cygwin_nt-5.01, cygwin_98-4.101 Since distutils is an installer and in no way performance sensitive, I think that flexibility is more important than dictionary lookup speed. ------------------------------------------------------- Date: 2001-Feb-18 14:22 By: akuchling Comment: Can you convince me why a regular expression match is required, instead of just normalizing sys.platform ('cygwin/1.14' -> 'cygwin') and continuing to use a dictionary? (Does sys.platform actually include a version number on Cygwin? Wonder if that's a good idea?) ------------------------------------------------------- Date: 2001-Feb-18 14:01 By: lemburg Comment: Assigned to Andrew for review. ------------------------------------------------------- Date: 2001-Feb-18 14:00 By: lemburg Comment: Assigning to Andrew for review. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103868&group_id=5470 From noreply@sourceforge.net Mon Feb 19 09:27:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Feb 2001 01:27:54 -0800 Subject: [Patches] [Patch #103687] Several improvements for bdist_wininst Message-ID: Patch #103687 has been updated. Project: python Category: distutils Status: Closed Submitted by: theller Assigned to : theller Summary: Several improvements for bdist_wininst Follow-Ups: Date: 2001-Feb-19 01:27 By: theller Comment: Closed, because I've checked it in with slight changes. ------------------------------------------------------- Date: 2001-Feb-14 09:52 By: akuchling Comment: Finally got around to looking at this patch, though I can only assess the Python code. One small thing to fix: the "Writing bitmap at offset %x" message is always printed. Probably self.announce() should be used instead (or is it a debugging message?) Anyway, go ahead and check it in! ------------------------------------------------------- Date: 2001-Feb-08 08:51 By: theller Comment: Assigned to Andrew because he wanted to review this. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103687&group_id=5470 From noreply@sourceforge.net Mon Feb 19 17:09:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Feb 2001 09:09:35 -0800 Subject: [Patches] [Patch #103854] Check Node class in minidom Message-ID: Patch #103854 has been updated. Project: python Category: XML Status: Accepted Submitted by: akuchling Assigned to : akuchling Summary: Check Node class in minidom Follow-Ups: Date: 2001-Feb-19 09:09 By: loewis Comment: The patch looks good; it should be changed to raise HierarchyRequestErr before committing. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103854&group_id=5470 From noreply@sourceforge.net Mon Feb 19 17:56:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Feb 2001 09:56:24 -0800 Subject: [Patches] [Patch #103655] configure changes for Solaris Message-ID: Patch #103655 has been updated. Project: python Category: Build Status: Closed Submitted by: sgriggs Assigned to : nobody Summary: configure changes for Solaris Follow-Ups: Date: 2001-Feb-19 09:56 By: loewis Comment: Why was this patch approved? Why does the -shared option not work on Solaris? -shared does the following things: - invoke the linker with -G -dy -z text (the latter only if -mimpure-text was not given) - drop crt1.o from the list of objects being linked - drop -lc from the list of libraries being linked OTOH, -G is just passed through to the linker. The things that -shared does are necessary: crt1.o defines _start, and requires main, so it should not be present in a shared library. Likewise, -z text should be used to detect position-dependent code at compile time. Unless some explicit rationale can be given, I think this patch should be reversed. ------------------------------------------------------- Date: 2001-Feb-18 20:47 By: nascheme Comment: Checked in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103655&group_id=5470 From noreply@sourceforge.net Mon Feb 19 18:24:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Feb 2001 10:24:23 -0800 Subject: [Patches] [Patch #103655] configure changes for Solaris Message-ID: Patch #103655 has been updated. Project: python Category: Build Status: Open Submitted by: sgriggs Assigned to : loewis Summary: configure changes for Solaris Follow-Ups: Date: 2001-Feb-19 10:24 By: nascheme Comment: Okay, I've reverted the patch. Sorry Martin. ------------------------------------------------------- Date: 2001-Feb-19 09:56 By: loewis Comment: Why was this patch approved? Why does the -shared option not work on Solaris? -shared does the following things: - invoke the linker with -G -dy -z text (the latter only if -mimpure-text was not given) - drop crt1.o from the list of objects being linked - drop -lc from the list of libraries being linked OTOH, -G is just passed through to the linker. The things that -shared does are necessary: crt1.o defines _start, and requires main, so it should not be present in a shared library. Likewise, -z text should be used to detect position-dependent code at compile time. Unless some explicit rationale can be given, I think this patch should be reversed. ------------------------------------------------------- Date: 2001-Feb-18 20:47 By: nascheme Comment: Checked in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103655&group_id=5470 From noreply@sourceforge.net Mon Feb 19 18:25:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Feb 2001 10:25:16 -0800 Subject: [Patches] [Patch #103656] configure.in changes for Solaris Message-ID: Patch #103656 has been updated. Project: python Category: Build Status: Open Submitted by: sgriggs Assigned to : loewis Summary: configure.in changes for Solaris Follow-Ups: Date: 2001-Feb-19 10:25 By: nascheme Comment: Reverted checkin. ------------------------------------------------------- Date: 2001-Feb-18 20:49 By: nascheme Comment: Checked in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103656&group_id=5470 From noreply@sourceforge.net Mon Feb 19 18:39:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Feb 2001 10:39:58 -0800 Subject: [Patches] [Patch #103839] sgmllib: Allow ';' in attributes Message-ID: Patch #103839 has been updated. Project: python Category: library Status: Closed Submitted by: dougfort Assigned to : gvanrossum Summary: sgmllib: Allow ';' in attributes Follow-Ups: Date: 2001-Feb-19 10:39 By: gvanrossum Comment: Thanks -- I've checked this in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103839&group_id=5470 From noreply@sourceforge.net Mon Feb 19 18:40:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Feb 2001 10:40:38 -0800 Subject: [Patches] [Patch #103871] self.fp not defined in class ZipFile for non-existing file Message-ID: Patch #103871 has been updated. Project: python Category: None Status: Open Submitted by: dkuhlman2 Assigned to : fdrake Summary: self.fp not defined in class ZipFile for non-existing file ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103871&group_id=5470 From noreply@sourceforge.net Mon Feb 19 19:46:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Feb 2001 11:46:11 -0800 Subject: [Patches] [Patch #103789] Add support to zipfile for passing file-like objects Message-ID: Patch #103789 has been updated. Project: python Category: Modules Status: Rejected Submitted by: itamar Assigned to : fdrake Summary: Add support to zipfile for passing file-like objects Follow-Ups: Date: 2001-Feb-19 11:46 By: fdrake Comment: Please provide test cases for this. The tests should be added to Lib/test/test_zipfile.py. File-ness should probably be determined by checking if the object is a string or not (remember to test for a Unicode string as well!). Instead of catching an exception from checking for file.name, you can instead fetch the name using getattr(file, 'name', None) and not worry about exceptions; only the AttributeError you were actually trying to catch will be caught, and everything else will "do the right thing" instead of getting masked, as the current code does. I'll re-evaluate the patch when it gets updated at SF. (I think the idea is right -- there's no need to require a built-in file object.) ------------------------------------------------------- Date: 2001-Feb-14 05:26 By: itamar Comment: Right now I detect file-like objects by doing hasattr(file, "read"). Doing hasattr(file, "write") might be better though, since for mode="w" ZipFiles, all you need are write() and tell() methods on the file-like object. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103789&group_id=5470 From noreply@sourceforge.net Mon Feb 19 21:07:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Feb 2001 13:07:59 -0800 Subject: [Patches] [Patch #103445] Fixed DB_RECNO support in bsddb module Message-ID: Patch #103445 has been updated. Project: python Category: Modules Status: Open Submitted by: niemeyer Assigned to : fdrake Summary: Fixed DB_RECNO support in bsddb module Follow-Ups: Date: 2001-Feb-19 13:07 By: fdrake Comment: I'm inclined to apply this, but am having problems with the bsddb module in general. I would like to see some tests that work with RECNO databases. With or without this patch, this snippet: >>> import bsddb >>> db = bsddb.rnopen('foo.db') (where foo.db does not exist) is causing a core dump somewhere in the exception handling code (Mandrake Linux 7.1, stock libraries). What platform did you test this patch on? What versions of the libraries? ------------------------------------------------------- Date: 2001-Jan-27 23:11 By: fdrake Comment: Re-assigned to me; Skip only worked on the build process for this, not the module code. ------------------------------------------------------- Date: 2001-Jan-26 22:06 By: fdrake Comment: I think this is fine from a quick eyeballing of the code, but would add the di_type declaration before the WITH_THREAD conditional section so that the optional part is at the end. Assigned to Skip since he's dealt a lot with this module recently. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103445&group_id=5470 From noreply@sourceforge.net Mon Feb 19 21:19:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Feb 2001 13:19:28 -0800 Subject: [Patches] [Patch #101394] lookdict optimizations Message-ID: Patch #101394 has been updated. Project: python Category: core (C code) Status: Open Submitted by: marangoz Assigned to : fdrake Summary: lookdict optimizations Follow-Ups: Date: 2001-Feb-19 13:19 By: fdrake Comment: This patch optimizes what appears to be a small corner case (string keys in a string-only dict that have hash collisions), but the cause can indeed come up. I need to spend a little time instrumenting the code to determine how often this corner case occurs, and haven't had time to do that yet. ------------------------------------------------------- Date: 2001-Feb-09 16:11 By: jhylton Comment: Is this patch still revelant? ------------------------------------------------------- Date: 2000-Sep-03 21:09 By: marangoz Comment: Let's add a comment, although this has been raised on python-dev. This patch proposes a couple of ideas for optimizing & speeding dict lookups -- not all of them need to be applied though. - clear the eventual errors from Object_Compare only on need (this logic needs to be double-checked once again to see whether it really works) - defer variable initializations after the most common return cases - specialize string_compare() for lookdict_string. The test comparing the first char, before calling memcmp(), can be added too. - inline the first item probe in PyDict_GetItem. This saves a func call for the most common case (common to lookdict & lookdict_string). ------------------------------------------------------- Date: 2000-Sep-04 06:45 By: gvanrossum Comment: Quick comments: we should *always* call PyErr_Occurred() after PyObject_Compare() (and PyErr_Clear() if PyErr_Occurred() returned true). PyErr_Compare() really doesn't expect a pending exception coming in and so *not* clearing the error might break the *next* PyErr_Compare() call. (This doesn't happen typically but PyObject_Compare() can execute arbitrary code, some of which might call PyErr_Occurred() without calling PyErr_Clear() first.) ------------------------------------------------------- Date: 2000-Sep-05 06:05 By: nobody Comment: Correct! But then, aren't the current "else" if(cmp == 0) clauses risky after PyObject_Compare()? An exception may be set in external code while making Object_Compare() to return 0! Perhaps not in Python source, but in buggy extensions. lookdict() will then overlook this "hit". Patch updated, without "else" clauses and with the 1st char check in string_compare_equal(). ------------------------------------------------------- Date: 2000-Sep-05 06:08 By: marangoz Comment: Argh! These Web interfaces strike again - forgot to login. ------------------------------------------------------- Date: 2000-Sep-14 09:26 By: fdrake Comment: Revised patch: Instead of defining a function to do the fast string comparison, use a macro, but let it use the documented string object API (PyString_GET_SIZE(), PyString_AS_STRING()) instead of breaking the encapsulation in the code. This avoids all function calls to do the string compare, except memcmp() (which good compilers can inline anyway). Vladimir, take a look at this; if you're happy, I'm happy, and you can check it in. Thanks! ------------------------------------------------------- Date: 2000-Sep-14 13:51 By: fdrake Comment: Guido, please review (since Vladimir's away). ------------------------------------------------------- Date: 2000-Sep-15 11:18 By: gvanrossum Comment: Accepted. Assuming you've tested this, it looks fine to me. Can you time this a bit? There's one niggling issue: some people think that before you do memcmp() you should manually compare the first character. Others think that's unnecessary (since a good compiler can inline memcmp anyway). (It's also a bit scary if the size is zero.) So please ignore this but keep it in mind for timing experiments. :) ------------------------------------------------------- Date: 2000-Sep-25 14:38 By: twouters Comment: Shouldn't this patch be either postponed or checked in? ------------------------------------------------------- Date: 2000-Sep-25 18:52 By: fdrake Comment: It's postponed since I've not had time to run performance tests to measure the corner case it aims to improve. It turns out that generating the test data I need takes a long time (I need hash collisions of identifier-like strings). I just need to be able to let my generator run for a long time (it was generating more collisions than I'd expected, but I don't know how many off-hand). Another interesting metric would be to examine the .pyc files generated from the standard library and find out if there are any string hash collisions there -- if not, or if very few, it's not worth the added complexity. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101394&group_id=5470 From noreply@sourceforge.net Mon Feb 19 22:21:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Feb 2001 14:21:52 -0800 Subject: [Patches] [Patch #103884] Dynamic registration and lookup of DOM implementations Message-ID: Patch #103884 has been updated. Project: python Category: XML Status: Open Submitted by: nobody Assigned to : nobody Summary: Dynamic registration and lookup of DOM implementations ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103884&group_id=5470 From noreply@sourceforge.net Mon Feb 19 22:25:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Feb 2001 14:25:49 -0800 Subject: [Patches] [Patch #103884] Dynamic registration and lookup of DOM implementations Message-ID: Patch #103884 has been updated. Project: python Category: XML Status: Deleted Submitted by: nobody Assigned to : nobody Summary: Dynamic registration and lookup of DOM implementations Follow-Ups: Date: 2001-Feb-19 14:25 By: loewis Comment: Resubmit, with proper "Submitted By:" field ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103884&group_id=5470 From noreply@sourceforge.net Mon Feb 19 22:27:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Feb 2001 14:27:02 -0800 Subject: [Patches] [Patch #103885] Dynamic registration and lookup of DOM implementations Message-ID: Patch #103885 has been updated. Project: python Category: XML Status: Open Submitted by: loewis Assigned to : fdrake Summary: Dynamic registration and lookup of DOM implementations ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103885&group_id=5470 From noreply@sourceforge.net Mon Feb 19 22:26:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Feb 2001 14:26:20 -0800 Subject: [Patches] [Patch #103885] Dynamic registration and lookup of DOM implementations Message-ID: Patch #103885 has been updated. Project: python Category: XML Status: Open Submitted by: loewis Assigned to : nobody Summary: Dynamic registration and lookup of DOM implementations ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103885&group_id=5470 From noreply@sourceforge.net Mon Feb 19 22:50:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Feb 2001 14:50:20 -0800 Subject: [Patches] [Patch #103885] Dynamic registration and lookup of DOM implementations Message-ID: Patch #103885 has been updated. Project: python Category: XML Status: Open Submitted by: loewis Assigned to : loewis Summary: Dynamic registration and lookup of DOM implementations Follow-Ups: Date: 2001-Feb-19 14:50 By: fdrake Comment: Just about, I think. xml.dom.minidom should define getDOMImplementaion() this way: def getDOMImplementation(): return Document.implementation (There's no need to create new instances of a data-less object.) The search loop at the end of domreg.getDOMImplementation() should only do the _good_enough()/return test in an "else" clause of the try/except, otherwise it can test the same implementation objects more than once. The documentation should indicate that each DOM implementation should provide a getDOMImplementation() that returns the same object each time wherever possible. Which points out the need for documentation, but I can convert the docstrings myself for this one. Assign back to me for review after making changes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103885&group_id=5470 From noreply@sourceforge.net Mon Feb 19 23:05:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Feb 2001 15:05:47 -0800 Subject: [Patches] [Patch #103886] Building bsddb module with/without "-ldb" - BugID 132600 Message-ID: Patch #103886 has been updated. Project: python Category: Build Status: Open Submitted by: mfavas Assigned to : nobody Summary: Building bsddb module with/without "-ldb" - BugID 132600 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103886&group_id=5470 From noreply@sourceforge.net Mon Feb 19 23:54:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Feb 2001 15:54:32 -0800 Subject: [Patches] [Patch #103749] fix for complex & default args segfault Message-ID: Patch #103749 has been updated. Project: python Category: Parser/Compiler Status: Closed Submitted by: mwh Assigned to : jhylton Summary: fix for complex & default args segfault Follow-Ups: Date: 2001-Feb-19 15:54 By: jhylton Comment: Fixed in rev. 2.168 of compile.c ------------------------------------------------------- Date: 2001-Feb-12 08:08 By: fdrake Comment: Assigned to Mr. Compiler. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103749&group_id=5470 From noreply@sourceforge.net Tue Feb 20 06:19:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Feb 2001 22:19:08 -0800 Subject: [Patches] [Patch #103892] a small optimization for threading.py Message-ID: Patch #103892 has been updated. Project: python Category: library Status: Open Submitted by: nobody Assigned to : nobody Summary: a small optimization for threading.py ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103892&group_id=5470 From noreply@sourceforge.net Tue Feb 20 12:46:25 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Feb 2001 04:46:25 -0800 Subject: [Patches] [Patch #103789] Add support to zipfile for passing file-like objects Message-ID: Patch #103789 has been updated. Project: python Category: Modules Status: Rejected Submitted by: itamar Assigned to : fdrake Summary: Add support to zipfile for passing file-like objects Follow-Ups: Date: 2001-Feb-20 04:46 By: itamar Comment: OK, here are some tests (I submitted the whole file, not a patch, since I basically rewrote it.). And I fixed zipfile.py based on your comments. ------------------------------------------------------- Date: 2001-Feb-19 11:46 By: fdrake Comment: Please provide test cases for this. The tests should be added to Lib/test/test_zipfile.py. File-ness should probably be determined by checking if the object is a string or not (remember to test for a Unicode string as well!). Instead of catching an exception from checking for file.name, you can instead fetch the name using getattr(file, 'name', None) and not worry about exceptions; only the AttributeError you were actually trying to catch will be caught, and everything else will "do the right thing" instead of getting masked, as the current code does. I'll re-evaluate the patch when it gets updated at SF. (I think the idea is right -- there's no need to require a built-in file object.) ------------------------------------------------------- Date: 2001-Feb-14 05:26 By: itamar Comment: Right now I detect file-like objects by doing hasattr(file, "read"). Doing hasattr(file, "write") might be better though, since for mode="w" ZipFiles, all you need are write() and tell() methods on the file-like object. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103789&group_id=5470 From noreply@sourceforge.net Tue Feb 20 13:14:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Feb 2001 05:14:37 -0800 Subject: [Patches] [Patch #103789] Add support to zipfile for passing file-like objects Message-ID: Patch #103789 has been updated. Project: python Category: Modules Status: Rejected Submitted by: itamar Assigned to : fdrake Summary: Add support to zipfile for passing file-like objects Follow-Ups: Date: 2001-Feb-20 05:14 By: itamar Comment: As per Yhg1s's suggestion (he won't give me his real name - thomas?), I resubmitted everything as a patch. ------------------------------------------------------- Date: 2001-Feb-20 04:46 By: itamar Comment: OK, here are some tests (I submitted the whole file, not a patch, since I basically rewrote it.). And I fixed zipfile.py based on your comments. ------------------------------------------------------- Date: 2001-Feb-19 11:46 By: fdrake Comment: Please provide test cases for this. The tests should be added to Lib/test/test_zipfile.py. File-ness should probably be determined by checking if the object is a string or not (remember to test for a Unicode string as well!). Instead of catching an exception from checking for file.name, you can instead fetch the name using getattr(file, 'name', None) and not worry about exceptions; only the AttributeError you were actually trying to catch will be caught, and everything else will "do the right thing" instead of getting masked, as the current code does. I'll re-evaluate the patch when it gets updated at SF. (I think the idea is right -- there's no need to require a built-in file object.) ------------------------------------------------------- Date: 2001-Feb-14 05:26 By: itamar Comment: Right now I detect file-like objects by doing hasattr(file, "read"). Doing hasattr(file, "write") might be better though, since for mode="w" ZipFiles, all you need are write() and tell() methods on the file-like object. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103789&group_id=5470 From thomas@xs4all.net Tue Feb 20 13:40:31 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 20 Feb 2001 14:40:31 +0100 Subject: [Patches] [Patch #103789] Add support to zipfile for passing file-like objects In-Reply-To: ; from noreply@sourceforge.net on Tue, Feb 20, 2001 at 05:14:37AM -0800 References: Message-ID: <20010220144031.D13911@xs4all.nl> On Tue, Feb 20, 2001 at 05:14:37AM -0800, noreply@sourceforge.net wrote: > Patch #103789 has been updated. > > Project: python > Category: Modules > Status: Rejected > Submitted by: itamar > Assigned to : fdrake > Summary: Add support to zipfile for passing file-like objects > > Follow-Ups: > > Date: 2001-Feb-20 05:14 > By: itamar > > Comment: > As per Yhg1s's suggestion (he won't give me his real name - thomas?), I > resubmitted everything as a patch. That would be me :-) Yhg1s is my IRC nick. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From noreply@sourceforge.net Tue Feb 20 15:17:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Feb 2001 07:17:11 -0800 Subject: [Patches] [Patch #102313] shar output support Message-ID: Patch #102313 has been updated. Project: python Category: distutils Status: Open Submitted by: gward Assigned to : akuchling Summary: shar output support ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102313&group_id=5470 From noreply@sourceforge.net Tue Feb 20 15:17:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Feb 2001 07:17:00 -0800 Subject: [Patches] [Patch #101904] Better SWIG with C++ support Message-ID: Patch #101904 has been updated. Project: python Category: distutils Status: Open Submitted by: jgbauman Assigned to : akuchling Summary: Better SWIG with C++ support Follow-Ups: Date: 2000-Oct-13 23:07 By: jgbauman Comment: I had troubles with distutils 1.0 and the way I use SWIG. I couldn't find any support for the -shadow option and no way to pass an extra include dir to swig (like it´s possible for the c compiler) Therefore I wrote a patch. It adds an extra_swig_args (list of string) option to Extension. All the strings are passed to swig without modification, but if extra_swig_args contains "-c++" or "-shadow" there is some special action: "-c++": behaves like build_ext --swig-cpp "-shadow": Normally swig generates a file: foo.c -> foo.so In this case SWIG generates two files: foo.py (python shadow classes, imports fooc) fooc.c -> fooc.so With this patch build_ext can handle this und generates for foo.i (foo.py, fooc.c) compiles them and installs them. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101904&group_id=5470 From noreply@sourceforge.net Tue Feb 20 15:29:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Feb 2001 07:29:50 -0800 Subject: [Patches] [Patch #103899] Add module-specific switches to setup.py Message-ID: Patch #103899 has been updated. Project: python Category: distutils Status: Open Submitted by: akuchling Assigned to : nobody Summary: Add module-specific switches to setup.py ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103899&group_id=5470 From noreply@sourceforge.net Tue Feb 20 15:32:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Feb 2001 07:32:54 -0800 Subject: [Patches] [Patch #103892] a small optimization for threading.py Message-ID: Patch #103892 has been updated. Project: python Category: library Status: Open Submitted by: nobody Assigned to : tim_one Summary: a small optimization for threading.py ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103892&group_id=5470 From noreply@sourceforge.net Tue Feb 20 15:35:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Feb 2001 07:35:07 -0800 Subject: [Patches] [Patch #103899] Add module-specific switches to setup.py Message-ID: Patch #103899 has been updated. Project: python Category: distutils Status: Open Submitted by: akuchling Assigned to : gward Summary: Add module-specific switches to setup.py Follow-Ups: Date: 2001-Feb-20 07:34 By: akuchling Comment: Greg, can you please take a look at this in the next day or two? If you can't, let me know and I'll reassign it to someone else. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103899&group_id=5470 From noreply@sourceforge.net Tue Feb 20 15:39:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Feb 2001 07:39:52 -0800 Subject: [Patches] [Patch #103886] Building bsddb module with/without "-ldb" - BugID 132600 Message-ID: Patch #103886 has been updated. Project: python Category: Build Status: Open Submitted by: mfavas Assigned to : akuchling Summary: Building bsddb module with/without "-ldb" - BugID 132600 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103886&group_id=5470 From noreply@sourceforge.net Tue Feb 20 16:49:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Feb 2001 08:49:28 -0800 Subject: [Patches] [Patch #103445] Fixed DB_RECNO support in bsddb module Message-ID: Patch #103445 has been updated. Project: python Category: Modules Status: Open Submitted by: niemeyer Assigned to : fdrake Summary: Fixed DB_RECNO support in bsddb module Follow-Ups: Date: 2001-Feb-20 08:49 By: niemeyer Comment: Ok. This bug is happening due to a libdb bug. Between other things, it's closing the input fd (0). I've done a little hack to avoid this bug, so, I'm sending an updated patch. Thanks! ------------------------------------------------------- Date: 2001-Feb-19 13:07 By: fdrake Comment: I'm inclined to apply this, but am having problems with the bsddb module in general. I would like to see some tests that work with RECNO databases. With or without this patch, this snippet: >>> import bsddb >>> db = bsddb.rnopen('foo.db') (where foo.db does not exist) is causing a core dump somewhere in the exception handling code (Mandrake Linux 7.1, stock libraries). What platform did you test this patch on? What versions of the libraries? ------------------------------------------------------- Date: 2001-Jan-27 23:11 By: fdrake Comment: Re-assigned to me; Skip only worked on the build process for this, not the module code. ------------------------------------------------------- Date: 2001-Jan-26 22:06 By: fdrake Comment: I think this is fine from a quick eyeballing of the code, but would add the di_type declaration before the WITH_THREAD conditional section so that the optional part is at the end. Assigned to Skip since he's dealt a lot with this module recently. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103445&group_id=5470 From noreply@sourceforge.net Tue Feb 20 17:20:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Feb 2001 09:20:39 -0800 Subject: [Patches] [Patch #103901] Minor regen fix to be consistent with Makefile Message-ID: Patch #103901 has been updated. Project: python Category: Build Status: Open Submitted by: jlt63 Assigned to : nobody Summary: Minor regen fix to be consistent with Makefile ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103901&group_id=5470 From noreply@sourceforge.net Tue Feb 20 17:58:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Feb 2001 09:58:18 -0800 Subject: [Patches] [Patch #103885] Dynamic registration and lookup of DOM implementations Message-ID: Patch #103885 has been updated. Project: python Category: XML Status: Open Submitted by: loewis Assigned to : fdrake Summary: Dynamic registration and lookup of DOM implementations Follow-Ups: Date: 2001-Feb-20 09:58 By: loewis Comment: Updated the patch to address Fred's comments. Returning the same implementation object every time is not a strict requirement, as discussion on xml-sig concluded: there are cases where returning a fresh object every time is desirable. E.g. it might be desirable to switch off event propagation for an implementation if the application does not use that feature. Then, only the specific implementation instance should be affected. ------------------------------------------------------- Date: 2001-Feb-19 14:50 By: fdrake Comment: Just about, I think. xml.dom.minidom should define getDOMImplementaion() this way: def getDOMImplementation(): return Document.implementation (There's no need to create new instances of a data-less object.) The search loop at the end of domreg.getDOMImplementation() should only do the _good_enough()/return test in an "else" clause of the try/except, otherwise it can test the same implementation objects more than once. The documentation should indicate that each DOM implementation should provide a getDOMImplementation() that returns the same object each time wherever possible. Which points out the need for documentation, but I can convert the docstrings myself for this one. Assign back to me for review after making changes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103885&group_id=5470 From noreply@sourceforge.net Tue Feb 20 18:12:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Feb 2001 10:12:54 -0800 Subject: [Patches] [Patch #103885] Dynamic registration and lookup of DOM implementations Message-ID: Patch #103885 has been updated. Project: python Category: XML Status: Accepted Submitted by: loewis Assigned to : loewis Summary: Dynamic registration and lookup of DOM implementations Follow-Ups: Date: 2001-Feb-20 10:12 By: fdrake Comment: Let's go with it. ------------------------------------------------------- Date: 2001-Feb-20 09:58 By: loewis Comment: Updated the patch to address Fred's comments. Returning the same implementation object every time is not a strict requirement, as discussion on xml-sig concluded: there are cases where returning a fresh object every time is desirable. E.g. it might be desirable to switch off event propagation for an implementation if the application does not use that feature. Then, only the specific implementation instance should be affected. ------------------------------------------------------- Date: 2001-Feb-19 14:50 By: fdrake Comment: Just about, I think. xml.dom.minidom should define getDOMImplementaion() this way: def getDOMImplementation(): return Document.implementation (There's no need to create new instances of a data-less object.) The search loop at the end of domreg.getDOMImplementation() should only do the _good_enough()/return test in an "else" clause of the try/except, otherwise it can test the same implementation objects more than once. The documentation should indicate that each DOM implementation should provide a getDOMImplementation() that returns the same object each time wherever possible. Which points out the need for documentation, but I can convert the docstrings myself for this one. Assign back to me for review after making changes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103885&group_id=5470 From noreply@sourceforge.net Tue Feb 20 18:15:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Feb 2001 10:15:54 -0800 Subject: [Patches] [Patch #103516] zipfile.py: use hex constants for magic numbers Message-ID: Patch #103516 has been updated. Project: python Category: library Status: Accepted Submitted by: mfx Assigned to : jhylton Summary: zipfile.py: use hex constants for magic numbers Follow-Ups: Date: 2001-Feb-20 10:15 By: fdrake Comment: This is fine. Jeremy, my development box is down right now; can you check this is? Thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103516&group_id=5470 From noreply@sourceforge.net Tue Feb 20 18:55:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Feb 2001 10:55:46 -0800 Subject: [Patches] [Patch #103901] Minor regen fix to be consistent with Makefile Message-ID: Patch #103901 has been updated. Project: python Category: Build Status: Postponed Submitted by: jlt63 Assigned to : nascheme Summary: Minor regen fix to be consistent with Makefile Follow-Ups: Date: 2001-Feb-20 10:55 By: nascheme Comment: In retrospect I think changing EXE in the Makefile to EXEEXT was unnecessary. I'm going to create a patch to change it back to EXE and get someone else's option. Stay tuned. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103901&group_id=5470 From noreply@sourceforge.net Tue Feb 20 19:10:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Feb 2001 11:10:03 -0800 Subject: [Patches] [Patch #103903] Change EXEEXT back to EXE in the makefile Message-ID: Patch #103903 has been updated. Project: python Category: Build Status: Open Submitted by: nascheme Assigned to : nobody Summary: Change EXEEXT back to EXE in the makefile ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103903&group_id=5470 From noreply@sourceforge.net Tue Feb 20 19:11:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Feb 2001 11:11:02 -0800 Subject: [Patches] [Patch #103903] Change EXEEXT back to EXE in the makefile Message-ID: Patch #103903 has been updated. Project: python Category: Build Status: Open Submitted by: nascheme Assigned to : lemburg Summary: Change EXEEXT back to EXE in the makefile Follow-Ups: Date: 2001-Feb-20 11:11 By: nascheme Comment: Assigned to Marc mostly at random. Please review or assign to someone else. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103903&group_id=5470 From noreply@sourceforge.net Tue Feb 20 22:11:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Feb 2001 14:11:40 -0800 Subject: [Patches] [Patch #103473] Cookie.py: Allow values containing '=' Message-ID: Patch #103473 has been updated. Project: python Category: library Status: Closed Submitted by: dougfort Assigned to : akuchling Summary: Cookie.py: Allow values containing '=' Follow-Ups: Date: 2001-Feb-20 14:11 By: akuchling Comment: Checked into revision 1.7 of Cookie.py ------------------------------------------------------- Date: 2001-Feb-06 14:43 By: akuchling Comment: This seems non-compliant with RFC2109, the only relevant standard, but practically no one implements 2109 to the letter anyway. Practicality beats purity, so I think it should be applied. ------------------------------------------------------- Date: 2001-Jan-29 15:53 By: gvanrossum Comment: Andrew, can you check this? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103473&group_id=5470 From noreply@sourceforge.net Tue Feb 20 22:19:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Feb 2001 14:19:36 -0800 Subject: [Patches] [Patch #103681] Remove grammar rule from Makefile Message-ID: Patch #103681 has been updated. Project: python Category: Build Status: Rejected Submitted by: donnc Assigned to : nobody Summary: Remove grammar rule from Makefile Follow-Ups: Date: 2001-Feb-20 14:19 By: donnc Comment: Actually this is only a more complicated way to do the same thing - now you generate the files, but you still don't use them. Not graminit.h, anyway. Here's what happens if I remove graminit.h from the source directory: cc -c -g -O2 -Wall -Wstrict-prototypes -I. -I/tulsa/src/python-2.1a2b/Include -DHAVE_CONFIG_H -o Python/compile.o /tulsa/src/python-2.1a2b/Python/compile.c /tulsa/src/python-2.1a2b/Python/compile.c:17: graminit.h: No such file or directory You would have to add -IInclude to CFLAGS, along with -I$(srcdir)/Include; otherwise --srcdir build with modified grammar is broken (whether srcdir is read only or read/write.) ------------------------------------------------------- Date: 2001-Feb-15 20:14 By: nascheme Comment: I've checked in, IMHO, a better solution. The grammar source files are now generated in the build directory. If this doesn't work for a read-only source dir please let me know. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103681&group_id=5470 From noreply@sourceforge.net Wed Feb 21 01:22:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Feb 2001 17:22:34 -0800 Subject: [Patches] [Patch #103892] a small optimization for threading.py Message-ID: Patch #103892 has been updated. Project: python Category: library Status: Open Submitted by: nobody Assigned to : tim_one Summary: a small optimization for threading.py Follow-Ups: Date: 2001-Feb-20 17:22 By: tim_one Comment: n==1 may or may not be the most common case, but the new code is subject to races so can't be accepted anyway; e.g., thread T1 does a timed .wait(), thread T2 does .notify() and loses its timeslice right before the new self.__waiters[0].release(), T1 gets back just in time for its timed wait to expire, and executes its self.__waiters.remove(waiter), T2 then blows up with an IndexError trying to index into a list that's now empty. There's a reason .remove() is used everywhere: self.__waiters is subject to almost arbitrary mutation while .notify() is executing, so you can't safely assume anything about its state is invariant from one line to the next. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103892&group_id=5470 From noreply@sourceforge.net Wed Feb 21 01:31:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Feb 2001 17:31:08 -0800 Subject: [Patches] [Patch #103854] Check Node class in minidom Message-ID: Patch #103854 has been updated. Project: python Category: XML Status: Closed Submitted by: akuchling Assigned to : akuchling Summary: Check Node class in minidom Follow-Ups: Date: 2001-Feb-20 17:31 By: akuchling Comment: Checked in. ------------------------------------------------------- Date: 2001-Feb-19 09:09 By: loewis Comment: The patch looks good; it should be changed to raise HierarchyRequestErr before committing. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103854&group_id=5470 From noreply@sourceforge.net Wed Feb 21 02:18:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Feb 2001 18:18:50 -0800 Subject: [Patches] [Patch #103373] zlib sync-flush fix Message-ID: Patch #103373 has been updated. Project: python Category: Modules Status: Closed Submitted by: abo Assigned to : akuchling Summary: zlib sync-flush fix Follow-Ups: Date: 2001-Feb-20 18:18 By: akuchling Comment: Checked in to revision 2.39 of zlibmodule.c (at long last); thanks! ------------------------------------------------------- Date: 2001-Feb-17 01:55 By: abo Comment: There is an example program that triggers the main "sync-flush" bug attached to the bug report (I forget the id, but its fairly clearly labled in bug-tracking). As for the others, it's quite hard to actualy trigger some of these, and some of them are violations of the zlib interface that may or may not actualy cause problems with the current version of zlib. I'll go through them in detail now; Avoid repeat calls to (in|de)flateEnd: possably causes no problems with current version of zlib, but might in future releases. I haven't tested it, but if you really want I could whip something up that tests it. Raises exception when allocating unused_data fails, fixes memory leak when allocating unused_data fails, raises exception when allocating decompress data failes; These are all only tiggerable when memory allocation fails. Removes vistigial code from decompress flush; the fix to the main "sync-flush" bug ensures that decompress always returns all available data. This means that the decompress flush() can be simplified. tidies code etc; these are just code cleanups... ------------------------------------------------------- Date: 2001-Feb-16 21:10 By: akuchling Comment: Can you provide a test program that will demonstrate some of the bugs this patch fixes? I'd like to be able to do a before-and-after comparison. ------------------------------------------------------- Date: 2001-Jan-23 08:26 By: nobody Comment: Argh... my line by line fix list got munged. You'll have to apply imaginary comments to delimit each fix. The bug this fixes is 124981 "zlib decompress of sync-flushed data fails" A lot of the patch changes are simply whitespace changes to clean up the formating. The patch can probably be edited to only include the changes to the PyZlib_objdecompress routine to fix the most important bug, but this would leave the code even more inconsistant than it is. Most of the rest of the fixes are to make the other routines cleaner, though they do also fix the minor bugs mentioned. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103373&group_id=5470 From noreply@sourceforge.net Wed Feb 21 02:40:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Feb 2001 18:40:20 -0800 Subject: [Patches] [Patch #103544] Minor cleanup and support for NIS and bsddb on BSD systems Message-ID: Patch #103544 has been updated. Project: python Category: Build Status: Closed Submitted by: nobody Assigned to : akuchling Summary: Minor cleanup and support for NIS and bsddb on BSD systems Follow-Ups: Date: 2001-Feb-20 18:40 By: akuchling Comment: I've checked in the nis portion of this patch, and also the dl change (what the heck). Thanks! The bsddb detection code needs to be rewritten as noted in several other bug reports, so the remainder of this patch will probably be outdated by that change. We'll see how it breaks on BSD after that change; for now I'll close this patch. ------------------------------------------------------- Date: 2001-Feb-06 14:31 By: akuchling Comment: I've applied the portion of this patch that applies to the BSDDB module, and removing the extra comment. I'm not sure of enabling the dl module, and have asked python-dev for an opinion. I'm also not sure of always trying to compile the nis module; does almost everyone have it in libc these days? A configure test for some appropriate symbol would probably be better, though then it's difficult to check that in setup.py. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103544&group_id=5470 From noreply@sourceforge.net Wed Feb 21 02:48:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Feb 2001 18:48:53 -0800 Subject: [Patches] [Patch #103753] zlib decompress; uncontrollable memory usage Message-ID: Patch #103753 has been updated. Project: python Category: Modules Status: Open Submitted by: htrd Assigned to : akuchling Summary: zlib decompress; uncontrollable memory usage Follow-Ups: Date: 2001-Feb-20 18:48 By: akuchling Comment: Rather than introducing a new method, why not just add an optional maxlen argument to .decompress(). I think the changes would be: * add 'int maxlen=-1;' * add "...|i" ... ,&maxlen to the argument parsing * if maxlen != -1, length = maxlen else length = DEFAULTALLOC; * Add '&& maxlen==-1' to the while loop. (Use the current CVS; I just checked in a patch rearranging the zlib module a bit.) Do you want to make those changes and resubmit the patch? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103753&group_id=5470 From maildsb@glbgrp.com Wed Feb 21 07:14:49 2001 From: maildsb@glbgrp.com (=?ISO-2022-JP?B?GyRCOXFGYjpHQmc1aSEiOkdEY05BNmIkTiVhITwla0dbPy4lNSE8JVMlORsoQg==?=) Date: Wed, 21 Feb 2001 16:14:49 +0900 Subject: [Patches] =?ISO-2022-JP?B?GyRCOXFGYjpHQmc1aSEiOkdEY05BNmIkTiVhGyhC?= =?ISO-2022-JP?B?GyRCITwla0dbPy4lNSE8JVMlOSROJDQwRkZiGyhC?= Message-ID: <0221101161449.1225@WEBS> $B9qFb:GBg5i!":GDcNA6b$N%a!<%kG[?.%5!<%S%9$N$40FFb(B $B%[!<%`%Z!<%8$N@kEA!"$*E9$N@kEA!"?7>&IJ$N9pCN!"5a?MJg=8!"D4::!"9TJ}ITL@pJs%a%G%#%";v6HIt$H?=$7$^$9!#(B $B#U#R#L!'(B http://www.glbgrp.com$BFb(B $BEvpJsDs6!%5!<%S%9!Y!X>pJs4IM}Ds6!%7%9%F%`$N9=C[!YEy!">pJs$K4X$9(B $B$kA4HL$N%5!<%S%9$rDs6!$9$k2q&IJ$N9pCN(B D:$B5a?MJg=8!J9-HO0O$KJg=8$,=PMh$^$9!K(B E:$BD4::!J%"%s%1!<%HD4::!"Ey!K"(C"$7JLES2C9)NA6b$,$+$+$j$^$9!#(B F:$B9TJ}ITL@l9g$O(B $B!!(B $B#1#0!$#0#0#01_!\>CHq@G!\?69~)G[?.%G!<%?NL!'#1#6#6(BKbyt$B!JE:IU%U%!%$%k$=$NB>4^$`!K(B $B"($3$l$O$"$/$^$G?d>)$G$9$,!"$"$^$jBg$-$$$H%a!<%kpJs!J9-9p!"J8=q(B $BEy!K$rDj$a$i(B $B$l$?6b3[$GG[?.$9$k%5!<%S%9$G$9!#(B $B$*pJs$NFbMF$O!"HH:a$K4X78$9$k$b$N!"Hpkn!&Cf=}!&7y$,$i$;!"5u56!&(B $B%o%$%;%DJ8(B $B=q!&%o%$%;%D9-9p!"K=F0!"Ey$rM6H/$9$k2DG=@-!#Kt$O0cK!@-$,$"$k$HH=CG$5$l$k$b$N(B $B$O$*$9$k>l9g!K(B $BJV?.!&2sEz$5$l$?$b$N$O!"8D?M$rFCDj$G$-$k>pJs!J%"%I%l%9!&;aL>!&Ey!K$r=|$$$?(B $B%G!<%?$r%F%-%9%H(BCSV$BEy$GA4$F$*EO$7$$$?$7$^$9!#(B $BKt2sEz%G!<%?$O#17o#5#01_$NZ=PMh$+$M$^$9$N$G$4N;>5$/$@$5$$!#(B $BA\:w4j$$Ey$N2sEz!&O"Mm%a!<%k$OL5NA$G%G!<%?$r$*EO$7$7$^$9!#(B $B!!!JKtG[?.NA6b$b!"(B1$B%a!<%k%"%I%l%9C10L#11_$K$5$;$F$$$?$@$-$^$9!#!K(B $BLd$$9g$o$;!'(Bmaildsb@g-con.com $B!!(B $B!|$3$N%a!<%k$,ITMW$N>l$O!"$*l9g$,$4$6$$$^$9!#(B $B!!!!!!$"$7$+$i$:!"$4N;>5$/$@$5$$!#(B $B!!!!!!!!!!!!!!!!(B $B!!!!!!!!!!!!!!H/9T!'%0%m!<%V%$%s%U%)3t<02ql9g!"G[?.%a!<%k$N3NG'$,=PMh$?$b$N$H$_$J$7$^$9!#(B $B-'G[?.;XDjF|$K%a!<%k$NG[?.(B $B!!!!$=$N;~$K0MMjl9g!"F10l?MJ*$KF1$8%a!<%k$,G[?.$5$l$k2DG=@-$,$"$k(B $B$3$H$r$4N;>5$/$@$5$$!#(B $B!t!t!t!t!t!t!t!t!t!t!t!t!t!t!t!t!t!t!t!t!t!t!t!t!t!t!t!t!t!t(B From noreply@sourceforge.net Wed Feb 21 09:59:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Feb 2001 01:59:26 -0800 Subject: [Patches] [Patch #103926] 2.1a2 CVS - stop compiler warnings Message-ID: Patch #103926 has been updated. Project: python Category: Build Status: Open Submitted by: mfavas Assigned to : nobody Summary: 2.1a2 CVS - stop compiler warnings ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103926&group_id=5470 From noreply@sourceforge.net Wed Feb 21 11:10:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Feb 2001 03:10:37 -0800 Subject: [Patches] [Patch #103928] Correct zlib freeze settings for Win32 Message-ID: Patch #103928 has been updated. Project: python Category: demos and tools Status: Open Submitted by: lhudson Assigned to : nobody Summary: Correct zlib freeze settings for Win32 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103928&group_id=5470 From noreply@sourceforge.net Wed Feb 21 13:38:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Feb 2001 05:38:36 -0800 Subject: [Patches] [Patch #103930] Ignore error making grammar src if srcdir is readonly Message-ID: Patch #103930 has been updated. Project: python Category: Build Status: Open Submitted by: nascheme Assigned to : nobody Summary: Ignore error making grammar src if srcdir is readonly ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103930&group_id=5470 From noreply@sourceforge.net Wed Feb 21 13:43:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Feb 2001 05:43:32 -0800 Subject: [Patches] [Patch #103930] Ignore error making grammar src if srcdir is readonly Message-ID: Patch #103930 has been updated. Project: python Category: Build Status: Open Submitted by: nascheme Assigned to : twouters Summary: Ignore error making grammar src if srcdir is readonly Follow-Ups: Date: 2001-Feb-21 05:43 By: nascheme Comment: Does this make sense? My last change making graminit.h and graminit.c in the build directory was wrong. The compiler does not understand VPATH so the include file could not be found. The new idea is to continue the build even if the grammar sources cannot be regenerated (maybe the source directory is readonly). I don't want to remove the target completely since someone may change the grammar and forget to generate the source. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103930&group_id=5470 From noreply@sourceforge.net Wed Feb 21 13:47:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Feb 2001 05:47:34 -0800 Subject: [Patches] [Patch #103681] Remove grammar rule from Makefile Message-ID: Patch #103681 has been updated. Project: python Category: Build Status: Rejected Submitted by: donnc Assigned to : nobody Summary: Remove grammar rule from Makefile Follow-Ups: Date: 2001-Feb-21 05:47 By: nascheme Comment: D'oh, your right. Can you look at patch #103930? I don't want to omit the rule. Prevous versions of Python did omit it but that caused some surprises when people started hacking on the grammar. ------------------------------------------------------- Date: 2001-Feb-20 14:19 By: donnc Comment: Actually this is only a more complicated way to do the same thing - now you generate the files, but you still don't use them. Not graminit.h, anyway. Here's what happens if I remove graminit.h from the source directory: cc -c -g -O2 -Wall -Wstrict-prototypes -I. -I/tulsa/src/python-2.1a2b/Include -DHAVE_CONFIG_H -o Python/compile.o /tulsa/src/python-2.1a2b/Python/compile.c /tulsa/src/python-2.1a2b/Python/compile.c:17: graminit.h: No such file or directory You would have to add -IInclude to CFLAGS, along with -I$(srcdir)/Include; otherwise --srcdir build with modified grammar is broken (whether srcdir is read only or read/write.) ------------------------------------------------------- Date: 2001-Feb-15 20:14 By: nascheme Comment: I've checked in, IMHO, a better solution. The grammar source files are now generated in the build directory. If this doesn't work for a read-only source dir please let me know. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103681&group_id=5470 From noreply@sourceforge.net Wed Feb 21 14:00:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Feb 2001 06:00:30 -0800 Subject: [Patches] [Patch #103753] zlib decompress; uncontrollable memory usage Message-ID: Patch #103753 has been updated. Project: python Category: Modules Status: Open Submitted by: htrd Assigned to : akuchling Summary: zlib decompress; uncontrollable memory usage Follow-Ups: Date: 2001-Feb-21 06:00 By: htrd Comment: I did consider that.... An extra change that you didnt mention is the need for a different return value. Currently .decompress() always returns a string. The new method in my patch returns a tuple containing the same string, and an integer specifying how many bytes were consumed from the input. Overloading return values based on an optional parameter seems a little hairy to me, but I would be happy to change the patch if that is your preferred option. I also considered (and rejected) the possibility of adding an optional max-size argument to .decompress() as you suggest, but raising an exception if this limit is exceeded. This avoids the need for an extra return value, but looses out on flexibility. ------------------------------------------------------- Date: 2001-Feb-20 18:48 By: akuchling Comment: Rather than introducing a new method, why not just add an optional maxlen argument to .decompress(). I think the changes would be: * add 'int maxlen=-1;' * add "...|i" ... ,&maxlen to the argument parsing * if maxlen != -1, length = maxlen else length = DEFAULTALLOC; * Add '&& maxlen==-1' to the while loop. (Use the current CVS; I just checked in a patch rearranging the zlib module a bit.) Do you want to make those changes and resubmit the patch? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103753&group_id=5470 From noreply@sourceforge.net Wed Feb 21 15:41:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Feb 2001 07:41:35 -0800 Subject: [Patches] [Patch #103901] Minor regen fix to be consistent with Makefile Message-ID: Patch #103901 has been updated. Project: python Category: Build Status: Postponed Submitted by: jlt63 Assigned to : nascheme Summary: Minor regen fix to be consistent with Makefile Follow-Ups: Date: 2001-Feb-21 07:41 By: jlt63 Comment: OK. My guess is that EXE was changed to EXEEXT in Makefile.pre.in to be consistent with configure.in when configure.in was changed to use AC_EXEEXT. ------------------------------------------------------- Date: 2001-Feb-20 10:55 By: nascheme Comment: In retrospect I think changing EXE in the Makefile to EXEEXT was unnecessary. I'm going to create a patch to change it back to EXE and get someone else's option. Stay tuned. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103901&group_id=5470 From noreply@sourceforge.net Wed Feb 21 19:06:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Feb 2001 11:06:56 -0800 Subject: [Patches] [Patch #103901] Minor regen fix to be consistent with Makefile Message-ID: Patch #103901 has been updated. Project: python Category: Build Status: Postponed Submitted by: jlt63 Assigned to : nascheme Summary: Minor regen fix to be consistent with Makefile Follow-Ups: Date: 2001-Feb-21 11:06 By: nascheme Comment: Yes, see patch 103903. ------------------------------------------------------- Date: 2001-Feb-21 07:41 By: jlt63 Comment: OK. My guess is that EXE was changed to EXEEXT in Makefile.pre.in to be consistent with configure.in when configure.in was changed to use AC_EXEEXT. ------------------------------------------------------- Date: 2001-Feb-20 10:55 By: nascheme Comment: In retrospect I think changing EXE in the Makefile to EXEEXT was unnecessary. I'm going to create a patch to change it back to EXE and get someone else's option. Stay tuned. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103901&group_id=5470 From noreply@sourceforge.net Wed Feb 21 19:32:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Feb 2001 11:32:03 -0800 Subject: [Patches] [Patch #103753] zlib decompress; uncontrollable memory usage Message-ID: Patch #103753 has been updated. Project: python Category: Modules Status: Open Submitted by: htrd Assigned to : akuchling Summary: zlib decompress; uncontrollable memory usage Follow-Ups: Date: 2001-Feb-21 11:32 By: akuchling Comment: Doesn't .unused_data serve much the same purpose, though? So that even with a maximum size, .decompress() always returns a string, and .unused_data would contain the unprocessed data. ------------------------------------------------------- Date: 2001-Feb-21 06:00 By: htrd Comment: I did consider that.... An extra change that you didnt mention is the need for a different return value. Currently .decompress() always returns a string. The new method in my patch returns a tuple containing the same string, and an integer specifying how many bytes were consumed from the input. Overloading return values based on an optional parameter seems a little hairy to me, but I would be happy to change the patch if that is your preferred option. I also considered (and rejected) the possibility of adding an optional max-size argument to .decompress() as you suggest, but raising an exception if this limit is exceeded. This avoids the need for an extra return value, but looses out on flexibility. ------------------------------------------------------- Date: 2001-Feb-20 18:48 By: akuchling Comment: Rather than introducing a new method, why not just add an optional maxlen argument to .decompress(). I think the changes would be: * add 'int maxlen=-1;' * add "...|i" ... ,&maxlen to the argument parsing * if maxlen != -1, length = maxlen else length = DEFAULTALLOC; * Add '&& maxlen==-1' to the while loop. (Use the current CVS; I just checked in a patch rearranging the zlib module a bit.) Do you want to make those changes and resubmit the patch? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103753&group_id=5470 From noreply@sourceforge.net Wed Feb 21 19:37:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Feb 2001 11:37:33 -0800 Subject: [Patches] [Patch #103903] Change EXEEXT back to EXE in the makefile Message-ID: Patch #103903 has been updated. Project: python Category: Build Status: Open Submitted by: nascheme Assigned to : lemburg Summary: Change EXEEXT back to EXE in the makefile Follow-Ups: Date: 2001-Feb-21 11:37 By: jlt63 Comment: Note that Marc has informed me that he will be offline for the next two weeks so may be this should be assigned to someone else... ------------------------------------------------------- Date: 2001-Feb-20 11:11 By: nascheme Comment: Assigned to Marc mostly at random. Please review or assign to someone else. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103903&group_id=5470 From noreply@sourceforge.net Wed Feb 21 19:40:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Feb 2001 11:40:10 -0800 Subject: [Patches] [Patch #103899] Add module-specific switches to setup.py Message-ID: Patch #103899 has been updated. Project: python Category: distutils Status: Open Submitted by: akuchling Assigned to : theller Summary: Add module-specific switches to setup.py Follow-Ups: Date: 2001-Feb-21 11:40 By: akuchling Comment: Reassigning to Thomas Heller (since he's done a fair bit of Distutil hacking) for a sanity check. ------------------------------------------------------- Date: 2001-Feb-20 07:34 By: akuchling Comment: Greg, can you please take a look at this in the next day or two? If you can't, let me know and I'll reassign it to someone else. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103899&group_id=5470 From noreply@sourceforge.net Wed Feb 21 19:47:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Feb 2001 11:47:42 -0800 Subject: [Patches] [Patch #103899] Add module-specific switches to setup.py Message-ID: Patch #103899 has been updated. Project: python Category: distutils Status: Open Submitted by: akuchling Assigned to : theller Summary: Add module-specific switches to setup.py Follow-Ups: Date: 2001-Feb-21 11:47 By: akuchling Comment: New version of the patch, this time as a context diff. ------------------------------------------------------- Date: 2001-Feb-21 11:40 By: akuchling Comment: Reassigning to Thomas Heller (since he's done a fair bit of Distutil hacking) for a sanity check. ------------------------------------------------------- Date: 2001-Feb-20 07:34 By: akuchling Comment: Greg, can you please take a look at this in the next day or two? If you can't, let me know and I'll reassign it to someone else. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103899&group_id=5470 From noreply@sourceforge.net Wed Feb 21 19:50:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Feb 2001 11:50:47 -0800 Subject: [Patches] [Patch #103903] Change EXEEXT back to EXE in the makefile Message-ID: Patch #103903 has been updated. Project: python Category: Build Status: Open Submitted by: nascheme Assigned to : fdrake Summary: Change EXEEXT back to EXE in the makefile Follow-Ups: Date: 2001-Feb-21 11:37 By: jlt63 Comment: Note that Marc has informed me that he will be offline for the next two weeks so may be this should be assigned to someone else... ------------------------------------------------------- Date: 2001-Feb-20 11:11 By: nascheme Comment: Assigned to Marc mostly at random. Please review or assign to someone else. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103903&group_id=5470 From noreply@sourceforge.net Wed Feb 21 20:13:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Feb 2001 12:13:06 -0800 Subject: [Patches] [Patch #103899] Add module-specific switches to setup.py Message-ID: Patch #103899 has been updated. Project: python Category: distutils Status: Open Submitted by: akuchling Assigned to : theller Summary: Add module-specific switches to setup.py Follow-Ups: Date: 2001-Feb-21 12:13 By: nobody Comment: Looks as if it could work, but I only can say this from reading the patch. But: Why is it neccessary? Why aren't the include-directories defined in the Extension instances? Would anyone sane give them from the command line? ------------------------------------------------------- Date: 2001-Feb-21 11:47 By: akuchling Comment: New version of the patch, this time as a context diff. ------------------------------------------------------- Date: 2001-Feb-21 11:40 By: akuchling Comment: Reassigning to Thomas Heller (since he's done a fair bit of Distutil hacking) for a sanity check. ------------------------------------------------------- Date: 2001-Feb-20 07:34 By: akuchling Comment: Greg, can you please take a look at this in the next day or two? If you can't, let me know and I'll reassign it to someone else. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103899&group_id=5470 From noreply@sourceforge.net Wed Feb 21 20:15:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Feb 2001 12:15:54 -0800 Subject: [Patches] [Patch #103899] Add module-specific switches to setup.py Message-ID: Patch #103899 has been updated. Project: python Category: distutils Status: Open Submitted by: akuchling Assigned to : theller Summary: Add module-specific switches to setup.py Follow-Ups: Date: 2001-Feb-21 12:15 By: theller Comment: The previous one was my comment, but I wasn't logged in. sorry. ------------------------------------------------------- Date: 2001-Feb-21 12:13 By: nobody Comment: Looks as if it could work, but I only can say this from reading the patch. But: Why is it neccessary? Why aren't the include-directories defined in the Extension instances? Would anyone sane give them from the command line? ------------------------------------------------------- Date: 2001-Feb-21 11:47 By: akuchling Comment: New version of the patch, this time as a context diff. ------------------------------------------------------- Date: 2001-Feb-21 11:40 By: akuchling Comment: Reassigning to Thomas Heller (since he's done a fair bit of Distutil hacking) for a sanity check. ------------------------------------------------------- Date: 2001-Feb-20 07:34 By: akuchling Comment: Greg, can you please take a look at this in the next day or two? If you can't, let me know and I'll reassign it to someone else. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103899&group_id=5470 From noreply@sourceforge.net Wed Feb 21 20:18:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Feb 2001 12:18:22 -0800 Subject: [Patches] [Patch #103899] Add module-specific switches to setup.py Message-ID: Patch #103899 has been updated. Project: python Category: distutils Status: Open Submitted by: akuchling Assigned to : theller Summary: Add module-specific switches to setup.py Follow-Ups: Date: 2001-Feb-21 12:18 By: akuchling Comment: It's needed to handle special-cases; what if GDBM is installed in /depot/gnu/ instead of either OTOH, maybe this fixes the wrong problem. If the setup.py script parsed Modules/Setup and ignored any modules turned on in that file, that might be much easier that having a bunch of switches. Hm... ------------------------------------------------------- Date: 2001-Feb-21 12:15 By: theller Comment: The previous one was my comment, but I wasn't logged in. sorry. ------------------------------------------------------- Date: 2001-Feb-21 12:13 By: nobody Comment: Looks as if it could work, but I only can say this from reading the patch. But: Why is it neccessary? Why aren't the include-directories defined in the Extension instances? Would anyone sane give them from the command line? ------------------------------------------------------- Date: 2001-Feb-21 11:47 By: akuchling Comment: New version of the patch, this time as a context diff. ------------------------------------------------------- Date: 2001-Feb-21 11:40 By: akuchling Comment: Reassigning to Thomas Heller (since he's done a fair bit of Distutil hacking) for a sanity check. ------------------------------------------------------- Date: 2001-Feb-20 07:34 By: akuchling Comment: Greg, can you please take a look at this in the next day or two? If you can't, let me know and I'll reassign it to someone else. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103899&group_id=5470 From noreply@sourceforge.net Wed Feb 21 20:21:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Feb 2001 12:21:53 -0800 Subject: [Patches] [Patch #103899] Add module-specific switches to setup.py Message-ID: Patch #103899 has been updated. Project: python Category: distutils Status: Open Submitted by: akuchling Assigned to : theller Summary: Add module-specific switches to setup.py Follow-Ups: Date: 2001-Feb-21 12:21 By: theller Comment: Shouldn't Modules/Setup be hacked or recreated from Setup.in in this case (although I'm not at all familiar with this stuff) ------------------------------------------------------- Date: 2001-Feb-21 12:18 By: akuchling Comment: It's needed to handle special-cases; what if GDBM is installed in /depot/gnu/ instead of either OTOH, maybe this fixes the wrong problem. If the setup.py script parsed Modules/Setup and ignored any modules turned on in that file, that might be much easier that having a bunch of switches. Hm... ------------------------------------------------------- Date: 2001-Feb-21 12:15 By: theller Comment: The previous one was my comment, but I wasn't logged in. sorry. ------------------------------------------------------- Date: 2001-Feb-21 12:13 By: nobody Comment: Looks as if it could work, but I only can say this from reading the patch. But: Why is it neccessary? Why aren't the include-directories defined in the Extension instances? Would anyone sane give them from the command line? ------------------------------------------------------- Date: 2001-Feb-21 11:47 By: akuchling Comment: New version of the patch, this time as a context diff. ------------------------------------------------------- Date: 2001-Feb-21 11:40 By: akuchling Comment: Reassigning to Thomas Heller (since he's done a fair bit of Distutil hacking) for a sanity check. ------------------------------------------------------- Date: 2001-Feb-20 07:34 By: akuchling Comment: Greg, can you please take a look at this in the next day or two? If you can't, let me know and I'll reassign it to someone else. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103899&group_id=5470 From noreply@sourceforge.net Wed Feb 21 20:24:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Feb 2001 12:24:39 -0800 Subject: [Patches] [Patch #103899] Add module-specific switches to setup.py Message-ID: Patch #103899 has been updated. Project: python Category: distutils Status: Open Submitted by: akuchling Assigned to : theller Summary: Add module-specific switches to setup.py Follow-Ups: Date: 2001-Feb-21 12:24 By: akuchling Comment: Setup.dist, you're thinking of, but yes, you've got the right idea. ------------------------------------------------------- Date: 2001-Feb-21 12:21 By: theller Comment: Shouldn't Modules/Setup be hacked or recreated from Setup.in in this case (although I'm not at all familiar with this stuff) ------------------------------------------------------- Date: 2001-Feb-21 12:18 By: akuchling Comment: It's needed to handle special-cases; what if GDBM is installed in /depot/gnu/ instead of either OTOH, maybe this fixes the wrong problem. If the setup.py script parsed Modules/Setup and ignored any modules turned on in that file, that might be much easier that having a bunch of switches. Hm... ------------------------------------------------------- Date: 2001-Feb-21 12:15 By: theller Comment: The previous one was my comment, but I wasn't logged in. sorry. ------------------------------------------------------- Date: 2001-Feb-21 12:13 By: nobody Comment: Looks as if it could work, but I only can say this from reading the patch. But: Why is it neccessary? Why aren't the include-directories defined in the Extension instances? Would anyone sane give them from the command line? ------------------------------------------------------- Date: 2001-Feb-21 11:47 By: akuchling Comment: New version of the patch, this time as a context diff. ------------------------------------------------------- Date: 2001-Feb-21 11:40 By: akuchling Comment: Reassigning to Thomas Heller (since he's done a fair bit of Distutil hacking) for a sanity check. ------------------------------------------------------- Date: 2001-Feb-20 07:34 By: akuchling Comment: Greg, can you please take a look at this in the next day or two? If you can't, let me know and I'll reassign it to someone else. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103899&group_id=5470 From noreply@sourceforge.net Wed Feb 21 20:52:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Feb 2001 12:52:48 -0800 Subject: [Patches] [Patch #103933] sys.path not set correctly when embedded Message-ID: Patch #103933 has been updated. Project: python Category: core (C code) Status: Open Submitted by: theller Assigned to : nobody Summary: sys.path not set correctly when embedded ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103933&group_id=5470 From noreply@sourceforge.net Wed Feb 21 21:07:51 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Feb 2001 13:07:51 -0800 Subject: [Patches] [Patch #103933] sys.path not set correctly when embedded Message-ID: Patch #103933 has been updated. Project: python Category: Windows Status: Open Submitted by: theller Assigned to : tim_one Summary: sys.path not set correctly when embedded Follow-Ups: Date: 2001-Feb-21 13:07 By: theller Comment: Assigned to Tim, one of the windows guys:-) This is urgent. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103933&group_id=5470 From noreply@sourceforge.net Thu Feb 22 01:55:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Feb 2001 17:55:39 -0800 Subject: [Patches] [Patch #103933] sys.path not set correctly when embedded Message-ID: Patch #103933 has been updated. Project: python Category: Windows Status: Open Submitted by: theller Assigned to : mhammond Summary: sys.path not set correctly when embedded Follow-Ups: Date: 2001-Feb-21 17:55 By: tim_one Comment: Assigned to Mark, as it's his code and I don't understand it offhand. Mark, this is a very simple (one-liner) patch. theller, I don't understand your comment. What semicolon are you talking about? The preceding loop incremented dataSize by the lengths of all items, + one more for each item to hold a semicolon after it. And that's all the semicolons there are. It appears to me that the second loop is *incorrect*, in that it adds a semicolon whenever index>0, regardless of whether ppPaths[index] is or isn't NULL, and so may end up inserting arbitrarily more semicolons than the preceding loop saved space for. But if that's what's going on, your patch doesn't fix it in general, it would just cover up the simplest failing case. ------------------------------------------------------- Date: 2001-Feb-21 13:07 By: theller Comment: Assigned to Tim, one of the windows guys:-) This is urgent. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103933&group_id=5470 From noreply@sourceforge.net Thu Feb 22 04:08:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Feb 2001 20:08:45 -0800 Subject: [Patches] [Patch #103899] Remove modules configured in Setup Message-ID: Patch #103899 has been updated. Project: python Category: distutils Status: Open Submitted by: akuchling Assigned to : theller Summary: Remove modules configured in Setup Follow-Ups: Date: 2001-Feb-21 20:08 By: akuchling Comment: This takes a much simpler approach; if a module is in Modules/Setup, don't compile it. Then you can set flags to yours heart's content in Setup, and you can sing and jump and dance about and the little goat-footed balloon man will... sorry. ------------------------------------------------------- Date: 2001-Feb-21 12:24 By: akuchling Comment: Setup.dist, you're thinking of, but yes, you've got the right idea. ------------------------------------------------------- Date: 2001-Feb-21 12:21 By: theller Comment: Shouldn't Modules/Setup be hacked or recreated from Setup.in in this case (although I'm not at all familiar with this stuff) ------------------------------------------------------- Date: 2001-Feb-21 12:18 By: akuchling Comment: It's needed to handle special-cases; what if GDBM is installed in /depot/gnu/ instead of either OTOH, maybe this fixes the wrong problem. If the setup.py script parsed Modules/Setup and ignored any modules turned on in that file, that might be much easier that having a bunch of switches. Hm... ------------------------------------------------------- Date: 2001-Feb-21 12:15 By: theller Comment: The previous one was my comment, but I wasn't logged in. sorry. ------------------------------------------------------- Date: 2001-Feb-21 12:13 By: nobody Comment: Looks as if it could work, but I only can say this from reading the patch. But: Why is it neccessary? Why aren't the include-directories defined in the Extension instances? Would anyone sane give them from the command line? ------------------------------------------------------- Date: 2001-Feb-21 11:47 By: akuchling Comment: New version of the patch, this time as a context diff. ------------------------------------------------------- Date: 2001-Feb-21 11:40 By: akuchling Comment: Reassigning to Thomas Heller (since he's done a fair bit of Distutil hacking) for a sanity check. ------------------------------------------------------- Date: 2001-Feb-20 07:34 By: akuchling Comment: Greg, can you please take a look at this in the next day or two? If you can't, let me know and I'll reassign it to someone else. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103899&group_id=5470 From noreply@sourceforge.net Thu Feb 22 04:10:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Feb 2001 20:10:03 -0800 Subject: [Patches] [Patch #103937] Attempt at BSDDB fix Message-ID: Patch #103937 has been updated. Project: python Category: Build Status: Open Submitted by: akuchling Assigned to : nobody Summary: Attempt at BSDDB fix ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103937&group_id=5470 From noreply@sourceforge.net Thu Feb 22 04:10:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Feb 2001 20:10:37 -0800 Subject: [Patches] [Patch #103937] Attempt at BSDDB fix Message-ID: Patch #103937 has been updated. Project: python Category: Build Status: Open Submitted by: akuchling Assigned to : twouters Summary: Attempt at BSDDB fix ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103937&group_id=5470 From noreply@sourceforge.net Thu Feb 22 04:10:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Feb 2001 20:10:53 -0800 Subject: [Patches] [Patch #103926] 2.1a2 CVS - stop compiler warnings Message-ID: Patch #103926 has been updated. Project: python Category: Build Status: Open Submitted by: mfavas Assigned to : akuchling Summary: 2.1a2 CVS - stop compiler warnings ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103926&group_id=5470 From noreply@sourceforge.net Thu Feb 22 11:40:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Feb 2001 03:40:36 -0800 Subject: [Patches] [Patch #103753] zlib decompress; uncontrollable memory usage Message-ID: Patch #103753 has been updated. Project: python Category: Modules Status: Open Submitted by: htrd Assigned to : akuchling Summary: zlib decompress; uncontrollable memory usage Follow-Ups: Date: 2001-Feb-22 03:40 By: htrd Comment: We can reuse .unused_data without introducing an ambiguity. I will prepare a patch that uses a new attribute .unconsumed_tail ------------------------------------------------------- Date: 2001-Feb-21 11:32 By: akuchling Comment: Doesn't .unused_data serve much the same purpose, though? So that even with a maximum size, .decompress() always returns a string, and .unused_data would contain the unprocessed data. ------------------------------------------------------- Date: 2001-Feb-21 06:00 By: htrd Comment: I did consider that.... An extra change that you didnt mention is the need for a different return value. Currently .decompress() always returns a string. The new method in my patch returns a tuple containing the same string, and an integer specifying how many bytes were consumed from the input. Overloading return values based on an optional parameter seems a little hairy to me, but I would be happy to change the patch if that is your preferred option. I also considered (and rejected) the possibility of adding an optional max-size argument to .decompress() as you suggest, but raising an exception if this limit is exceeded. This avoids the need for an extra return value, but looses out on flexibility. ------------------------------------------------------- Date: 2001-Feb-20 18:48 By: akuchling Comment: Rather than introducing a new method, why not just add an optional maxlen argument to .decompress(). I think the changes would be: * add 'int maxlen=-1;' * add "...|i" ... ,&maxlen to the argument parsing * if maxlen != -1, length = maxlen else length = DEFAULTALLOC; * Add '&& maxlen==-1' to the while loop. (Use the current CVS; I just checked in a patch rearranging the zlib module a bit.) Do you want to make those changes and resubmit the patch? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103753&group_id=5470 From noreply@sourceforge.net Thu Feb 22 11:42:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Feb 2001 03:42:57 -0800 Subject: [Patches] [Patch #103753] zlib decompress; uncontrollable memory usage Message-ID: Patch #103753 has been updated. Project: python Category: Modules Status: Open Submitted by: htrd Assigned to : akuchling Summary: zlib decompress; uncontrollable memory usage Follow-Ups: Date: 2001-Feb-22 03:42 By: htrd Comment: Waaah - that last comment should be 'cant' not 'can' ------------------------------------------------------- Date: 2001-Feb-22 03:40 By: htrd Comment: We can reuse .unused_data without introducing an ambiguity. I will prepare a patch that uses a new attribute .unconsumed_tail ------------------------------------------------------- Date: 2001-Feb-21 11:32 By: akuchling Comment: Doesn't .unused_data serve much the same purpose, though? So that even with a maximum size, .decompress() always returns a string, and .unused_data would contain the unprocessed data. ------------------------------------------------------- Date: 2001-Feb-21 06:00 By: htrd Comment: I did consider that.... An extra change that you didnt mention is the need for a different return value. Currently .decompress() always returns a string. The new method in my patch returns a tuple containing the same string, and an integer specifying how many bytes were consumed from the input. Overloading return values based on an optional parameter seems a little hairy to me, but I would be happy to change the patch if that is your preferred option. I also considered (and rejected) the possibility of adding an optional max-size argument to .decompress() as you suggest, but raising an exception if this limit is exceeded. This avoids the need for an extra return value, but looses out on flexibility. ------------------------------------------------------- Date: 2001-Feb-20 18:48 By: akuchling Comment: Rather than introducing a new method, why not just add an optional maxlen argument to .decompress(). I think the changes would be: * add 'int maxlen=-1;' * add "...|i" ... ,&maxlen to the argument parsing * if maxlen != -1, length = maxlen else length = DEFAULTALLOC; * Add '&& maxlen==-1' to the while loop. (Use the current CVS; I just checked in a patch rearranging the zlib module a bit.) Do you want to make those changes and resubmit the patch? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103753&group_id=5470 From noreply@sourceforge.net Thu Feb 22 12:50:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Feb 2001 04:50:46 -0800 Subject: [Patches] [Patch #103753] zlib decompress; uncontrollable memory usage Message-ID: Patch #103753 has been updated. Project: python Category: Modules Status: Open Submitted by: htrd Assigned to : akuchling Summary: zlib decompress; uncontrollable memory usage Follow-Ups: Date: 2001-Feb-22 04:50 By: htrd Comment: New patch implementing a new optional parameter to .decompress, and a new attribute .unconsumed_tail ------------------------------------------------------- Date: 2001-Feb-22 03:42 By: htrd Comment: Waaah - that last comment should be 'cant' not 'can' ------------------------------------------------------- Date: 2001-Feb-22 03:40 By: htrd Comment: We can reuse .unused_data without introducing an ambiguity. I will prepare a patch that uses a new attribute .unconsumed_tail ------------------------------------------------------- Date: 2001-Feb-21 11:32 By: akuchling Comment: Doesn't .unused_data serve much the same purpose, though? So that even with a maximum size, .decompress() always returns a string, and .unused_data would contain the unprocessed data. ------------------------------------------------------- Date: 2001-Feb-21 06:00 By: htrd Comment: I did consider that.... An extra change that you didnt mention is the need for a different return value. Currently .decompress() always returns a string. The new method in my patch returns a tuple containing the same string, and an integer specifying how many bytes were consumed from the input. Overloading return values based on an optional parameter seems a little hairy to me, but I would be happy to change the patch if that is your preferred option. I also considered (and rejected) the possibility of adding an optional max-size argument to .decompress() as you suggest, but raising an exception if this limit is exceeded. This avoids the need for an extra return value, but looses out on flexibility. ------------------------------------------------------- Date: 2001-Feb-20 18:48 By: akuchling Comment: Rather than introducing a new method, why not just add an optional maxlen argument to .decompress(). I think the changes would be: * add 'int maxlen=-1;' * add "...|i" ... ,&maxlen to the argument parsing * if maxlen != -1, length = maxlen else length = DEFAULTALLOC; * Add '&& maxlen==-1' to the while loop. (Use the current CVS; I just checked in a patch rearranging the zlib module a bit.) Do you want to make those changes and resubmit the patch? ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103753&group_id=5470 From noreply@sourceforge.net Thu Feb 22 14:06:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Feb 2001 06:06:29 -0800 Subject: [Patches] [Patch #103885] Dynamic registration and lookup of DOM implementations Message-ID: Patch #103885 has been updated. Project: python Category: XML Status: Closed Submitted by: loewis Assigned to : nobody Summary: Dynamic registration and lookup of DOM implementations Follow-Ups: Date: 2001-Feb-22 06:06 By: loewis Comment: Committed as minidom 1.27, __init__ 1.9, domreg 1.1 and xmldom.tex 1.10. ------------------------------------------------------- Date: 2001-Feb-20 10:12 By: fdrake Comment: Let's go with it. ------------------------------------------------------- Date: 2001-Feb-20 09:58 By: loewis Comment: Updated the patch to address Fred's comments. Returning the same implementation object every time is not a strict requirement, as discussion on xml-sig concluded: there are cases where returning a fresh object every time is desirable. E.g. it might be desirable to switch off event propagation for an implementation if the application does not use that feature. Then, only the specific implementation instance should be affected. ------------------------------------------------------- Date: 2001-Feb-19 14:50 By: fdrake Comment: Just about, I think. xml.dom.minidom should define getDOMImplementaion() this way: def getDOMImplementation(): return Document.implementation (There's no need to create new instances of a data-less object.) The search loop at the end of domreg.getDOMImplementation() should only do the _good_enough()/return test in an "else" clause of the try/except, otherwise it can test the same implementation objects more than once. The documentation should indicate that each DOM implementation should provide a getDOMImplementation() that returns the same object each time wherever possible. Which points out the need for documentation, but I can convert the docstrings myself for this one. Assign back to me for review after making changes. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103885&group_id=5470 From noreply@sourceforge.net Thu Feb 22 15:53:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Feb 2001 07:53:59 -0800 Subject: [Patches] [Patch #103926] 2.1a2 CVS - stop compiler warnings Message-ID: Patch #103926 has been updated. Project: python Category: Build Status: Closed Submitted by: mfavas Assigned to : akuchling Summary: 2.1a2 CVS - stop compiler warnings Follow-Ups: Date: 2001-Feb-22 07:53 By: akuchling Comment: Checked in; thanks! ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103926&group_id=5470 From noreply@sourceforge.net Thu Feb 22 15:54:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Feb 2001 07:54:50 -0800 Subject: [Patches] [Patch #103947] For Cygwin built Python use Cygwin like an UNIX C compiler Message-ID: Patch #103947 has been updated. Project: python Category: distutils Status: Open Submitted by: rliebscher Assigned to : nobody Summary: For Cygwin built Python use Cygwin like an UNIX C compiler ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103947&group_id=5470 From noreply@sourceforge.net Thu Feb 22 16:03:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Feb 2001 08:03:46 -0800 Subject: [Patches] [Patch #103937] Attempt at BSDDB fix Message-ID: Patch #103937 has been updated. Project: python Category: Build Status: Open Submitted by: akuchling Assigned to : twouters Summary: Attempt at BSDDB fix Follow-Ups: Date: 2001-Feb-22 08:03 By: akuchling Comment: Slightly revised version, taking out an "if ... and 0" that I forgot to take out. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103937&group_id=5470 From noreply@sourceforge.net Thu Feb 22 16:04:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Feb 2001 08:04:21 -0800 Subject: [Patches] [Patch #103937] Attempt at BSDDB fix Message-ID: Patch #103937 has been updated. Project: python Category: Build Status: Accepted Submitted by: akuchling Assigned to : akuchling Summary: Attempt at BSDDB fix Follow-Ups: Date: 2001-Feb-22 08:04 By: twouters Comment: After removing the "and 0", it works on RedHat 7 with all three BSDDB versions installed, and didn't break on BSDI (which was already working okay :) I assume the 'and 0' is an oversight from a debug version. ------------------------------------------------------- Date: 2001-Feb-22 08:03 By: akuchling Comment: Slightly revised version, taking out an "if ... and 0" that I forgot to take out. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103937&group_id=5470 From noreply@sourceforge.net Thu Feb 22 16:20:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Feb 2001 08:20:48 -0800 Subject: [Patches] [Patch #103930] Ignore error making grammar src if srcdir is readonly Message-ID: Patch #103930 has been updated. Project: python Category: Build Status: Open Submitted by: nascheme Assigned to : nascheme Summary: Ignore error making grammar src if srcdir is readonly Follow-Ups: Date: 2001-Feb-22 08:20 By: twouters Comment: This doesn't look like it does what it is supposed to. At least, after applying the patch, Grammar doesn't get rebuilt at all, even when graminit.h is missing: gcc -D_HAVE_BSDI -c -g -O2 -Wall -Wstrict-prototypes -I. -I../Include -DHAVE_CONFIG_H -o Python/compile.o ../Python/compile.c ../Python/compile.c:17: graminit.h: No such file or directory I can't seem to get it to make it, even though there is a $(GRAMINIT_H) dependancy. 'make Include/graminit.h' no longer works, and neither does anything else I can come up with. But I'd like to note I'm still against rebuilding the Grammar automatically in releases :-) I'm not really sure if it's still worth rebuilding the Grammar each time, myself. It was when I did the original (horribly broken) patch, but that was in the heat of 2.0, with lots of Grammar-changing patch-proposals about. ------------------------------------------------------- Date: 2001-Feb-21 05:43 By: nascheme Comment: Does this make sense? My last change making graminit.h and graminit.c in the build directory was wrong. The compiler does not understand VPATH so the include file could not be found. The new idea is to continue the build even if the grammar sources cannot be regenerated (maybe the source directory is readonly). I don't want to remove the target completely since someone may change the grammar and forget to generate the source. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103930&group_id=5470 From noreply@sourceforge.net Thu Feb 22 16:23:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Feb 2001 08:23:27 -0800 Subject: [Patches] [Patch #103948] uninstaller for bdist_wininst Message-ID: Patch #103948 has been updated. Project: python Category: distutils Status: Open Submitted by: theller Assigned to : nobody Summary: uninstaller for bdist_wininst ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103948&group_id=5470 From noreply@sourceforge.net Thu Feb 22 16:28:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Feb 2001 08:28:42 -0800 Subject: [Patches] [Patch #103948] uninstaller for bdist_wininst Message-ID: Patch #103948 has been updated. Project: python Category: distutils Status: Open Submitted by: theller Assigned to : nobody Summary: uninstaller for bdist_wininst Follow-Ups: Date: 2001-Feb-22 08:28 By: theller Comment: Uninstaller for bdist_wininst. Has been described detailed in http://mail.python.org/pipermail/distutils-sig/2001-February/001991.html. This version differs from the posted beta-version in better error checking. The patch is not complete: distutils/command/bdist_wininst.py has to be regenerated after the C-code has been compiled. I'm requesting permission to check this in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103948&group_id=5470 From noreply@sourceforge.net Thu Feb 22 16:36:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Feb 2001 08:36:35 -0800 Subject: [Patches] [Patch #103933] sys.path not set correctly when embedded Message-ID: Patch #103933 has been updated. Project: python Category: Windows Status: Open Submitted by: theller Assigned to : mhammond Summary: sys.path not set correctly when embedded Follow-Ups: Date: 2001-Feb-22 08:36 By: theller Comment: There's another semicolon after the second loop, in the else-clause of the if(skipCore) statement. I'm not sure whether the semicolon should be inserted or not, IF it is inserted, the buffer is too small and the RegQueryValueEx() fails with error 234 (More data is available). Well, only on Win98 and if there are no subkeys. ------------------------------------------------------- Date: 2001-Feb-21 17:55 By: tim_one Comment: Assigned to Mark, as it's his code and I don't understand it offhand. Mark, this is a very simple (one-liner) patch. theller, I don't understand your comment. What semicolon are you talking about? The preceding loop incremented dataSize by the lengths of all items, + one more for each item to hold a semicolon after it. And that's all the semicolons there are. It appears to me that the second loop is *incorrect*, in that it adds a semicolon whenever index>0, regardless of whether ppPaths[index] is or isn't NULL, and so may end up inserting arbitrarily more semicolons than the preceding loop saved space for. But if that's what's going on, your patch doesn't fix it in general, it would just cover up the simplest failing case. ------------------------------------------------------- Date: 2001-Feb-21 13:07 By: theller Comment: Assigned to Tim, one of the windows guys:-) This is urgent. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103933&group_id=5470 From noreply@sourceforge.net Fri Feb 23 03:32:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Feb 2001 19:32:45 -0800 Subject: [Patches] [Patch #103928] Correct zlib freeze settings for Win32 Message-ID: Patch #103928 has been updated. Project: python Category: demos and tools Status: Open Submitted by: lhudson Assigned to : tim_one Summary: Correct zlib freeze settings for Win32 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103928&group_id=5470 From noreply@sourceforge.net Fri Feb 23 03:46:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Feb 2001 19:46:04 -0800 Subject: [Patches] [Patch #103928] Correct zlib freeze settings for Win32 Message-ID: Patch #103928 has been updated. Project: python Category: demos and tools Status: Closed Submitted by: lhudson Assigned to : tim_one Summary: Correct zlib freeze settings for Win32 Follow-Ups: Date: 2001-Feb-22 19:46 By: tim_one Comment: Thanks! Checked in, extensions_win32.ini rev 1.5. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103928&group_id=5470 From noreply@sourceforge.net Fri Feb 23 06:06:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Feb 2001 22:06:35 -0800 Subject: [Patches] [Patch #103933] sys.path not set correctly when embedded Message-ID: Patch #103933 has been updated. Project: python Category: Windows Status: Open Submitted by: theller Assigned to : mhammond Summary: sys.path not set correctly when embedded Follow-Ups: Date: 2001-Feb-22 22:06 By: tim_one Comment: Yes, I saw that. I still want Mark to look at it, though: the code isn't clear (neither of us understands why it's doing what it's doing), and I don't have the bandwidth to try to sort this out before the beta release. You *may* have just hit the nail on the head: if there are no subkeys and skipcore is false, then "the preceding loop" didn't allocate any space for this semicolon, and indeed the semicolon should *not* be there. In that case a correct fix is to suppress the semicolon, not to add 1 at random beforehand (when the code is already murky, making it murkier is a Bad Idea). But, even in that case, it's unclear to me why dataBuf = malloc((dataSize+1) * sizeof(TCHAR)); already adds a 1 pulled out of thin air. ------------------------------------------------------- Date: 2001-Feb-22 08:36 By: theller Comment: There's another semicolon after the second loop, in the else-clause of the if(skipCore) statement. I'm not sure whether the semicolon should be inserted or not, IF it is inserted, the buffer is too small and the RegQueryValueEx() fails with error 234 (More data is available). Well, only on Win98 and if there are no subkeys. ------------------------------------------------------- Date: 2001-Feb-21 17:55 By: tim_one Comment: Assigned to Mark, as it's his code and I don't understand it offhand. Mark, this is a very simple (one-liner) patch. theller, I don't understand your comment. What semicolon are you talking about? The preceding loop incremented dataSize by the lengths of all items, + one more for each item to hold a semicolon after it. And that's all the semicolons there are. It appears to me that the second loop is *incorrect*, in that it adds a semicolon whenever index>0, regardless of whether ppPaths[index] is or isn't NULL, and so may end up inserting arbitrarily more semicolons than the preceding loop saved space for. But if that's what's going on, your patch doesn't fix it in general, it would just cover up the simplest failing case. ------------------------------------------------------- Date: 2001-Feb-21 13:07 By: theller Comment: Assigned to Tim, one of the windows guys:-) This is urgent. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103933&group_id=5470 From noreply@sourceforge.net Fri Feb 23 06:58:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Feb 2001 22:58:45 -0800 Subject: [Patches] [Patch #103933] sys.path not set correctly when embedded Message-ID: Patch #103933 has been updated. Project: python Category: Windows Status: Open Submitted by: theller Assigned to : mhammond Summary: sys.path not set correctly when embedded Follow-Ups: Date: 2001-Feb-22 22:58 By: mhammond Comment: Yes - Tim spotted it. the dataSize returned from RegQueryInfoKey() does not include the NULL, hence the one from thin air. Ive added a comment :) If skipcore is false, we do indeed stick the extra semicolon for the non-existant sub-values, and this makes the buffer one byte too small. The code is still a little strange as it used to work on Win16, where the sizes weren't available in advance. I'll add a comment about that too ;-) I will work out an appropriate patch and submit a new version in a few minutes. ------------------------------------------------------- Date: 2001-Feb-22 22:06 By: tim_one Comment: Yes, I saw that. I still want Mark to look at it, though: the code isn't clear (neither of us understands why it's doing what it's doing), and I don't have the bandwidth to try to sort this out before the beta release. You *may* have just hit the nail on the head: if there are no subkeys and skipcore is false, then "the preceding loop" didn't allocate any space for this semicolon, and indeed the semicolon should *not* be there. In that case a correct fix is to suppress the semicolon, not to add 1 at random beforehand (when the code is already murky, making it murkier is a Bad Idea). But, even in that case, it's unclear to me why dataBuf = malloc((dataSize+1) * sizeof(TCHAR)); already adds a 1 pulled out of thin air. ------------------------------------------------------- Date: 2001-Feb-22 08:36 By: theller Comment: There's another semicolon after the second loop, in the else-clause of the if(skipCore) statement. I'm not sure whether the semicolon should be inserted or not, IF it is inserted, the buffer is too small and the RegQueryValueEx() fails with error 234 (More data is available). Well, only on Win98 and if there are no subkeys. ------------------------------------------------------- Date: 2001-Feb-21 17:55 By: tim_one Comment: Assigned to Mark, as it's his code and I don't understand it offhand. Mark, this is a very simple (one-liner) patch. theller, I don't understand your comment. What semicolon are you talking about? The preceding loop incremented dataSize by the lengths of all items, + one more for each item to hold a semicolon after it. And that's all the semicolons there are. It appears to me that the second loop is *incorrect*, in that it adds a semicolon whenever index>0, regardless of whether ppPaths[index] is or isn't NULL, and so may end up inserting arbitrarily more semicolons than the preceding loop saved space for. But if that's what's going on, your patch doesn't fix it in general, it would just cover up the simplest failing case. ------------------------------------------------------- Date: 2001-Feb-21 13:07 By: theller Comment: Assigned to Tim, one of the windows guys:-) This is urgent. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103933&group_id=5470 From noreply@sourceforge.net Fri Feb 23 07:44:17 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Feb 2001 23:44:17 -0800 Subject: [Patches] [Patch #103933] sys.path not set correctly when embedded Message-ID: Patch #103933 has been updated. Project: python Category: Windows Status: Open Submitted by: theller Assigned to : mhammond Summary: sys.path not set correctly when embedded Follow-Ups: Date: 2001-Feb-22 23:44 By: mhammond Comment: OK - stepping through in the debugger, it appears as tho Win2k always gives us a much bigger buffer. Stepping through in the debugger with a value of "foo" in the registry, 2k told me the buffer size was 8! Can speculate as to why, but that doesn't help. Unfortunately, I don't have MSVC etc on my 9x box, but I can only speculate that there RegKeyQueryInfo() there works as documented - returning exactly the size without room for the NULL. Hence we would hit this bug there. Uploading a revised patch which has _not_ been tested on Win9x, but the behaviour was verified in the debugger on 2k, even if the sizes werent set to kill us. I would be grateful if someone could test this on Win9x for me. A reasonable way to test is to rename your existing "2.1" key to "2.1_save", and create a new key with just a PythonPath value. Then copy Python.exe to your temp dir and run it. I'll check it in as soon as I hear someone has done that, or Tim tells me to ------------------------------------------------------- Date: 2001-Feb-22 22:58 By: mhammond Comment: Yes - Tim spotted it. the dataSize returned from RegQueryInfoKey() does not include the NULL, hence the one from thin air. Ive added a comment :) If skipcore is false, we do indeed stick the extra semicolon for the non-existant sub-values, and this makes the buffer one byte too small. The code is still a little strange as it used to work on Win16, where the sizes weren't available in advance. I'll add a comment about that too ;-) I will work out an appropriate patch and submit a new version in a few minutes. ------------------------------------------------------- Date: 2001-Feb-22 22:06 By: tim_one Comment: Yes, I saw that. I still want Mark to look at it, though: the code isn't clear (neither of us understands why it's doing what it's doing), and I don't have the bandwidth to try to sort this out before the beta release. You *may* have just hit the nail on the head: if there are no subkeys and skipcore is false, then "the preceding loop" didn't allocate any space for this semicolon, and indeed the semicolon should *not* be there. In that case a correct fix is to suppress the semicolon, not to add 1 at random beforehand (when the code is already murky, making it murkier is a Bad Idea). But, even in that case, it's unclear to me why dataBuf = malloc((dataSize+1) * sizeof(TCHAR)); already adds a 1 pulled out of thin air. ------------------------------------------------------- Date: 2001-Feb-22 08:36 By: theller Comment: There's another semicolon after the second loop, in the else-clause of the if(skipCore) statement. I'm not sure whether the semicolon should be inserted or not, IF it is inserted, the buffer is too small and the RegQueryValueEx() fails with error 234 (More data is available). Well, only on Win98 and if there are no subkeys. ------------------------------------------------------- Date: 2001-Feb-21 17:55 By: tim_one Comment: Assigned to Mark, as it's his code and I don't understand it offhand. Mark, this is a very simple (one-liner) patch. theller, I don't understand your comment. What semicolon are you talking about? The preceding loop incremented dataSize by the lengths of all items, + one more for each item to hold a semicolon after it. And that's all the semicolons there are. It appears to me that the second loop is *incorrect*, in that it adds a semicolon whenever index>0, regardless of whether ppPaths[index] is or isn't NULL, and so may end up inserting arbitrarily more semicolons than the preceding loop saved space for. But if that's what's going on, your patch doesn't fix it in general, it would just cover up the simplest failing case. ------------------------------------------------------- Date: 2001-Feb-21 13:07 By: theller Comment: Assigned to Tim, one of the windows guys:-) This is urgent. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103933&group_id=5470 From noreply@sourceforge.net Fri Feb 23 08:23:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Feb 2001 00:23:35 -0800 Subject: [Patches] [Patch #103933] sys.path not set correctly when embedded Message-ID: Patch #103933 has been updated. Project: python Category: Windows Status: Open Submitted by: theller Assigned to : mhammond Summary: sys.path not set correctly when embedded Follow-Ups: Date: 2001-Feb-23 00:23 By: theller Comment: I would be happy to test your new patch (running Win98 with VC6 under VMWare under 2000), but where is it? BTW: RegQueryInfoKey as documented, includes NULL! ------------------------------------------------------- Date: 2001-Feb-22 23:44 By: mhammond Comment: OK - stepping through in the debugger, it appears as tho Win2k always gives us a much bigger buffer. Stepping through in the debugger with a value of "foo" in the registry, 2k told me the buffer size was 8! Can speculate as to why, but that doesn't help. Unfortunately, I don't have MSVC etc on my 9x box, but I can only speculate that there RegKeyQueryInfo() there works as documented - returning exactly the size without room for the NULL. Hence we would hit this bug there. Uploading a revised patch which has _not_ been tested on Win9x, but the behaviour was verified in the debugger on 2k, even if the sizes werent set to kill us. I would be grateful if someone could test this on Win9x for me. A reasonable way to test is to rename your existing "2.1" key to "2.1_save", and create a new key with just a PythonPath value. Then copy Python.exe to your temp dir and run it. I'll check it in as soon as I hear someone has done that, or Tim tells me to ------------------------------------------------------- Date: 2001-Feb-22 22:58 By: mhammond Comment: Yes - Tim spotted it. the dataSize returned from RegQueryInfoKey() does not include the NULL, hence the one from thin air. Ive added a comment :) If skipcore is false, we do indeed stick the extra semicolon for the non-existant sub-values, and this makes the buffer one byte too small. The code is still a little strange as it used to work on Win16, where the sizes weren't available in advance. I'll add a comment about that too ;-) I will work out an appropriate patch and submit a new version in a few minutes. ------------------------------------------------------- Date: 2001-Feb-22 22:06 By: tim_one Comment: Yes, I saw that. I still want Mark to look at it, though: the code isn't clear (neither of us understands why it's doing what it's doing), and I don't have the bandwidth to try to sort this out before the beta release. You *may* have just hit the nail on the head: if there are no subkeys and skipcore is false, then "the preceding loop" didn't allocate any space for this semicolon, and indeed the semicolon should *not* be there. In that case a correct fix is to suppress the semicolon, not to add 1 at random beforehand (when the code is already murky, making it murkier is a Bad Idea). But, even in that case, it's unclear to me why dataBuf = malloc((dataSize+1) * sizeof(TCHAR)); already adds a 1 pulled out of thin air. ------------------------------------------------------- Date: 2001-Feb-22 08:36 By: theller Comment: There's another semicolon after the second loop, in the else-clause of the if(skipCore) statement. I'm not sure whether the semicolon should be inserted or not, IF it is inserted, the buffer is too small and the RegQueryValueEx() fails with error 234 (More data is available). Well, only on Win98 and if there are no subkeys. ------------------------------------------------------- Date: 2001-Feb-21 17:55 By: tim_one Comment: Assigned to Mark, as it's his code and I don't understand it offhand. Mark, this is a very simple (one-liner) patch. theller, I don't understand your comment. What semicolon are you talking about? The preceding loop incremented dataSize by the lengths of all items, + one more for each item to hold a semicolon after it. And that's all the semicolons there are. It appears to me that the second loop is *incorrect*, in that it adds a semicolon whenever index>0, regardless of whether ppPaths[index] is or isn't NULL, and so may end up inserting arbitrarily more semicolons than the preceding loop saved space for. But if that's what's going on, your patch doesn't fix it in general, it would just cover up the simplest failing case. ------------------------------------------------------- Date: 2001-Feb-21 13:07 By: theller Comment: Assigned to Tim, one of the windows guys:-) This is urgent. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103933&group_id=5470 From noreply@sourceforge.net Fri Feb 23 09:02:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Feb 2001 01:02:42 -0800 Subject: [Patches] [Patch #103933] sys.path not set correctly when embedded Message-ID: Patch #103933 has been updated. Project: python Category: Windows Status: Open Submitted by: theller Assigned to : mhammond Summary: sys.path not set correctly when embedded Follow-Ups: Date: 2001-Feb-23 01:02 By: tim_one Comment: Mark overwrote your patch with his. That is, his patch is *right here*. It's 4am here, and I have to get some sleep, so do try it! ------------------------------------------------------- Date: 2001-Feb-23 00:23 By: theller Comment: I would be happy to test your new patch (running Win98 with VC6 under VMWare under 2000), but where is it? BTW: RegQueryInfoKey as documented, includes NULL! ------------------------------------------------------- Date: 2001-Feb-22 23:44 By: mhammond Comment: OK - stepping through in the debugger, it appears as tho Win2k always gives us a much bigger buffer. Stepping through in the debugger with a value of "foo" in the registry, 2k told me the buffer size was 8! Can speculate as to why, but that doesn't help. Unfortunately, I don't have MSVC etc on my 9x box, but I can only speculate that there RegKeyQueryInfo() there works as documented - returning exactly the size without room for the NULL. Hence we would hit this bug there. Uploading a revised patch which has _not_ been tested on Win9x, but the behaviour was verified in the debugger on 2k, even if the sizes werent set to kill us. I would be grateful if someone could test this on Win9x for me. A reasonable way to test is to rename your existing "2.1" key to "2.1_save", and create a new key with just a PythonPath value. Then copy Python.exe to your temp dir and run it. I'll check it in as soon as I hear someone has done that, or Tim tells me to ------------------------------------------------------- Date: 2001-Feb-22 22:58 By: mhammond Comment: Yes - Tim spotted it. the dataSize returned from RegQueryInfoKey() does not include the NULL, hence the one from thin air. Ive added a comment :) If skipcore is false, we do indeed stick the extra semicolon for the non-existant sub-values, and this makes the buffer one byte too small. The code is still a little strange as it used to work on Win16, where the sizes weren't available in advance. I'll add a comment about that too ;-) I will work out an appropriate patch and submit a new version in a few minutes. ------------------------------------------------------- Date: 2001-Feb-22 22:06 By: tim_one Comment: Yes, I saw that. I still want Mark to look at it, though: the code isn't clear (neither of us understands why it's doing what it's doing), and I don't have the bandwidth to try to sort this out before the beta release. You *may* have just hit the nail on the head: if there are no subkeys and skipcore is false, then "the preceding loop" didn't allocate any space for this semicolon, and indeed the semicolon should *not* be there. In that case a correct fix is to suppress the semicolon, not to add 1 at random beforehand (when the code is already murky, making it murkier is a Bad Idea). But, even in that case, it's unclear to me why dataBuf = malloc((dataSize+1) * sizeof(TCHAR)); already adds a 1 pulled out of thin air. ------------------------------------------------------- Date: 2001-Feb-22 08:36 By: theller Comment: There's another semicolon after the second loop, in the else-clause of the if(skipCore) statement. I'm not sure whether the semicolon should be inserted or not, IF it is inserted, the buffer is too small and the RegQueryValueEx() fails with error 234 (More data is available). Well, only on Win98 and if there are no subkeys. ------------------------------------------------------- Date: 2001-Feb-21 17:55 By: tim_one Comment: Assigned to Mark, as it's his code and I don't understand it offhand. Mark, this is a very simple (one-liner) patch. theller, I don't understand your comment. What semicolon are you talking about? The preceding loop incremented dataSize by the lengths of all items, + one more for each item to hold a semicolon after it. And that's all the semicolons there are. It appears to me that the second loop is *incorrect*, in that it adds a semicolon whenever index>0, regardless of whether ppPaths[index] is or isn't NULL, and so may end up inserting arbitrarily more semicolons than the preceding loop saved space for. But if that's what's going on, your patch doesn't fix it in general, it would just cover up the simplest failing case. ------------------------------------------------------- Date: 2001-Feb-21 13:07 By: theller Comment: Assigned to Tim, one of the windows guys:-) This is urgent. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103933&group_id=5470 From noreply@sourceforge.net Fri Feb 23 11:13:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Feb 2001 03:13:20 -0800 Subject: [Patches] [Patch #103933] sys.path not set correctly when embedded Message-ID: Patch #103933 has been updated. Project: python Category: Windows Status: Open Submitted by: theller Assigned to : mhammond Summary: sys.path not set correctly when embedded Follow-Ups: Date: 2001-Feb-23 03:13 By: mhammond Comment: *sigh* - in my haste, my eyes fixed on the parameter above (lpcMaxValueNameLen) which says "The length does not include the terminating null character." In my docs, this specific param (lpcMaxValueLen) says nothing about the size of the string (but does say the param itself can be none). Hrm - actually, I can test this in 98 - (comes back) - yes, I can repro the behaviour (garbage on sys.path) before the patch, and the correct behaviour after on 9x. OK - I think I should check it in! ------------------------------------------------------- Date: 2001-Feb-23 01:02 By: tim_one Comment: Mark overwrote your patch with his. That is, his patch is *right here*. It's 4am here, and I have to get some sleep, so do try it! ------------------------------------------------------- Date: 2001-Feb-23 00:23 By: theller Comment: I would be happy to test your new patch (running Win98 with VC6 under VMWare under 2000), but where is it? BTW: RegQueryInfoKey as documented, includes NULL! ------------------------------------------------------- Date: 2001-Feb-22 23:44 By: mhammond Comment: OK - stepping through in the debugger, it appears as tho Win2k always gives us a much bigger buffer. Stepping through in the debugger with a value of "foo" in the registry, 2k told me the buffer size was 8! Can speculate as to why, but that doesn't help. Unfortunately, I don't have MSVC etc on my 9x box, but I can only speculate that there RegKeyQueryInfo() there works as documented - returning exactly the size without room for the NULL. Hence we would hit this bug there. Uploading a revised patch which has _not_ been tested on Win9x, but the behaviour was verified in the debugger on 2k, even if the sizes werent set to kill us. I would be grateful if someone could test this on Win9x for me. A reasonable way to test is to rename your existing "2.1" key to "2.1_save", and create a new key with just a PythonPath value. Then copy Python.exe to your temp dir and run it. I'll check it in as soon as I hear someone has done that, or Tim tells me to ------------------------------------------------------- Date: 2001-Feb-22 22:58 By: mhammond Comment: Yes - Tim spotted it. the dataSize returned from RegQueryInfoKey() does not include the NULL, hence the one from thin air. Ive added a comment :) If skipcore is false, we do indeed stick the extra semicolon for the non-existant sub-values, and this makes the buffer one byte too small. The code is still a little strange as it used to work on Win16, where the sizes weren't available in advance. I'll add a comment about that too ;-) I will work out an appropriate patch and submit a new version in a few minutes. ------------------------------------------------------- Date: 2001-Feb-22 22:06 By: tim_one Comment: Yes, I saw that. I still want Mark to look at it, though: the code isn't clear (neither of us understands why it's doing what it's doing), and I don't have the bandwidth to try to sort this out before the beta release. You *may* have just hit the nail on the head: if there are no subkeys and skipcore is false, then "the preceding loop" didn't allocate any space for this semicolon, and indeed the semicolon should *not* be there. In that case a correct fix is to suppress the semicolon, not to add 1 at random beforehand (when the code is already murky, making it murkier is a Bad Idea). But, even in that case, it's unclear to me why dataBuf = malloc((dataSize+1) * sizeof(TCHAR)); already adds a 1 pulled out of thin air. ------------------------------------------------------- Date: 2001-Feb-22 08:36 By: theller Comment: There's another semicolon after the second loop, in the else-clause of the if(skipCore) statement. I'm not sure whether the semicolon should be inserted or not, IF it is inserted, the buffer is too small and the RegQueryValueEx() fails with error 234 (More data is available). Well, only on Win98 and if there are no subkeys. ------------------------------------------------------- Date: 2001-Feb-21 17:55 By: tim_one Comment: Assigned to Mark, as it's his code and I don't understand it offhand. Mark, this is a very simple (one-liner) patch. theller, I don't understand your comment. What semicolon are you talking about? The preceding loop incremented dataSize by the lengths of all items, + one more for each item to hold a semicolon after it. And that's all the semicolons there are. It appears to me that the second loop is *incorrect*, in that it adds a semicolon whenever index>0, regardless of whether ppPaths[index] is or isn't NULL, and so may end up inserting arbitrarily more semicolons than the preceding loop saved space for. But if that's what's going on, your patch doesn't fix it in general, it would just cover up the simplest failing case. ------------------------------------------------------- Date: 2001-Feb-21 13:07 By: theller Comment: Assigned to Tim, one of the windows guys:-) This is urgent. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103933&group_id=5470 From noreply@sourceforge.net Fri Feb 23 11:28:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Feb 2001 03:28:07 -0800 Subject: [Patches] [Patch #103933] sys.path not set correctly when embedded Message-ID: Patch #103933 has been updated. Project: python Category: Windows Status: Open Submitted by: theller Assigned to : mhammond Summary: sys.path not set correctly when embedded Follow-Ups: Date: 2001-Feb-23 03:28 By: mhammond Comment: Shouldn't have tried to be so slack :) The online docs are the same as mine - says nothing about this specific parameter, but for every other "length of string" param bar one, it specifically says "not include the NULL". Strangely, the one exception is lpcMaxSubKeyLen which says the NULL _is_ included on 9x and not on 2k. However, I think it a reasonable assumption that this param is "normal" and doesn't. The fact it works better this way also helps ;-) ------------------------------------------------------- Date: 2001-Feb-23 03:13 By: mhammond Comment: *sigh* - in my haste, my eyes fixed on the parameter above (lpcMaxValueNameLen) which says "The length does not include the terminating null character." In my docs, this specific param (lpcMaxValueLen) says nothing about the size of the string (but does say the param itself can be none). Hrm - actually, I can test this in 98 - (comes back) - yes, I can repro the behaviour (garbage on sys.path) before the patch, and the correct behaviour after on 9x. OK - I think I should check it in! ------------------------------------------------------- Date: 2001-Feb-23 01:02 By: tim_one Comment: Mark overwrote your patch with his. That is, his patch is *right here*. It's 4am here, and I have to get some sleep, so do try it! ------------------------------------------------------- Date: 2001-Feb-23 00:23 By: theller Comment: I would be happy to test your new patch (running Win98 with VC6 under VMWare under 2000), but where is it? BTW: RegQueryInfoKey as documented, includes NULL! ------------------------------------------------------- Date: 2001-Feb-22 23:44 By: mhammond Comment: OK - stepping through in the debugger, it appears as tho Win2k always gives us a much bigger buffer. Stepping through in the debugger with a value of "foo" in the registry, 2k told me the buffer size was 8! Can speculate as to why, but that doesn't help. Unfortunately, I don't have MSVC etc on my 9x box, but I can only speculate that there RegKeyQueryInfo() there works as documented - returning exactly the size without room for the NULL. Hence we would hit this bug there. Uploading a revised patch which has _not_ been tested on Win9x, but the behaviour was verified in the debugger on 2k, even if the sizes werent set to kill us. I would be grateful if someone could test this on Win9x for me. A reasonable way to test is to rename your existing "2.1" key to "2.1_save", and create a new key with just a PythonPath value. Then copy Python.exe to your temp dir and run it. I'll check it in as soon as I hear someone has done that, or Tim tells me to ------------------------------------------------------- Date: 2001-Feb-22 22:58 By: mhammond Comment: Yes - Tim spotted it. the dataSize returned from RegQueryInfoKey() does not include the NULL, hence the one from thin air. Ive added a comment :) If skipcore is false, we do indeed stick the extra semicolon for the non-existant sub-values, and this makes the buffer one byte too small. The code is still a little strange as it used to work on Win16, where the sizes weren't available in advance. I'll add a comment about that too ;-) I will work out an appropriate patch and submit a new version in a few minutes. ------------------------------------------------------- Date: 2001-Feb-22 22:06 By: tim_one Comment: Yes, I saw that. I still want Mark to look at it, though: the code isn't clear (neither of us understands why it's doing what it's doing), and I don't have the bandwidth to try to sort this out before the beta release. You *may* have just hit the nail on the head: if there are no subkeys and skipcore is false, then "the preceding loop" didn't allocate any space for this semicolon, and indeed the semicolon should *not* be there. In that case a correct fix is to suppress the semicolon, not to add 1 at random beforehand (when the code is already murky, making it murkier is a Bad Idea). But, even in that case, it's unclear to me why dataBuf = malloc((dataSize+1) * sizeof(TCHAR)); already adds a 1 pulled out of thin air. ------------------------------------------------------- Date: 2001-Feb-22 08:36 By: theller Comment: There's another semicolon after the second loop, in the else-clause of the if(skipCore) statement. I'm not sure whether the semicolon should be inserted or not, IF it is inserted, the buffer is too small and the RegQueryValueEx() fails with error 234 (More data is available). Well, only on Win98 and if there are no subkeys. ------------------------------------------------------- Date: 2001-Feb-21 17:55 By: tim_one Comment: Assigned to Mark, as it's his code and I don't understand it offhand. Mark, this is a very simple (one-liner) patch. theller, I don't understand your comment. What semicolon are you talking about? The preceding loop incremented dataSize by the lengths of all items, + one more for each item to hold a semicolon after it. And that's all the semicolons there are. It appears to me that the second loop is *incorrect*, in that it adds a semicolon whenever index>0, regardless of whether ppPaths[index] is or isn't NULL, and so may end up inserting arbitrarily more semicolons than the preceding loop saved space for. But if that's what's going on, your patch doesn't fix it in general, it would just cover up the simplest failing case. ------------------------------------------------------- Date: 2001-Feb-21 13:07 By: theller Comment: Assigned to Tim, one of the windows guys:-) This is urgent. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103933&group_id=5470 From noreply@sourceforge.net Fri Feb 23 11:31:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Feb 2001 03:31:56 -0800 Subject: [Patches] [Patch #103933] sys.path not set correctly when embedded Message-ID: Patch #103933 has been updated. Project: python Category: Windows Status: Open Submitted by: theller Assigned to : mhammond Summary: sys.path not set correctly when embedded Follow-Ups: Date: 2001-Feb-23 03:31 By: mhammond Comment: Shouldn't have tried to be so slack :) The online docs are the same as mine - says nothing about this specific parameter, but for every other "length of string" param bar one, it specifically says "not include the NULL". Strangely, the one exception is lpcMaxSubKeyLen which says the NULL _is_ included on 9x and not on 2k. However, I think it a reasonable assumption that this param is "normal" and doesn't. The fact it works better this way also helps ;-) ------------------------------------------------------- Date: 2001-Feb-23 03:28 By: mhammond Comment: Shouldn't have tried to be so slack :) The online docs are the same as mine - says nothing about this specific parameter, but for every other "length of string" param bar one, it specifically says "not include the NULL". Strangely, the one exception is lpcMaxSubKeyLen which says the NULL _is_ included on 9x and not on 2k. However, I think it a reasonable assumption that this param is "normal" and doesn't. The fact it works better this way also helps ;-) ------------------------------------------------------- Date: 2001-Feb-23 03:13 By: mhammond Comment: *sigh* - in my haste, my eyes fixed on the parameter above (lpcMaxValueNameLen) which says "The length does not include the terminating null character." In my docs, this specific param (lpcMaxValueLen) says nothing about the size of the string (but does say the param itself can be none). Hrm - actually, I can test this in 98 - (comes back) - yes, I can repro the behaviour (garbage on sys.path) before the patch, and the correct behaviour after on 9x. OK - I think I should check it in! ------------------------------------------------------- Date: 2001-Feb-23 01:02 By: tim_one Comment: Mark overwrote your patch with his. That is, his patch is *right here*. It's 4am here, and I have to get some sleep, so do try it! ------------------------------------------------------- Date: 2001-Feb-23 00:23 By: theller Comment: I would be happy to test your new patch (running Win98 with VC6 under VMWare under 2000), but where is it? BTW: RegQueryInfoKey as documented, includes NULL! ------------------------------------------------------- Date: 2001-Feb-22 23:44 By: mhammond Comment: OK - stepping through in the debugger, it appears as tho Win2k always gives us a much bigger buffer. Stepping through in the debugger with a value of "foo" in the registry, 2k told me the buffer size was 8! Can speculate as to why, but that doesn't help. Unfortunately, I don't have MSVC etc on my 9x box, but I can only speculate that there RegKeyQueryInfo() there works as documented - returning exactly the size without room for the NULL. Hence we would hit this bug there. Uploading a revised patch which has _not_ been tested on Win9x, but the behaviour was verified in the debugger on 2k, even if the sizes werent set to kill us. I would be grateful if someone could test this on Win9x for me. A reasonable way to test is to rename your existing "2.1" key to "2.1_save", and create a new key with just a PythonPath value. Then copy Python.exe to your temp dir and run it. I'll check it in as soon as I hear someone has done that, or Tim tells me to ------------------------------------------------------- Date: 2001-Feb-22 22:58 By: mhammond Comment: Yes - Tim spotted it. the dataSize returned from RegQueryInfoKey() does not include the NULL, hence the one from thin air. Ive added a comment :) If skipcore is false, we do indeed stick the extra semicolon for the non-existant sub-values, and this makes the buffer one byte too small. The code is still a little strange as it used to work on Win16, where the sizes weren't available in advance. I'll add a comment about that too ;-) I will work out an appropriate patch and submit a new version in a few minutes. ------------------------------------------------------- Date: 2001-Feb-22 22:06 By: tim_one Comment: Yes, I saw that. I still want Mark to look at it, though: the code isn't clear (neither of us understands why it's doing what it's doing), and I don't have the bandwidth to try to sort this out before the beta release. You *may* have just hit the nail on the head: if there are no subkeys and skipcore is false, then "the preceding loop" didn't allocate any space for this semicolon, and indeed the semicolon should *not* be there. In that case a correct fix is to suppress the semicolon, not to add 1 at random beforehand (when the code is already murky, making it murkier is a Bad Idea). But, even in that case, it's unclear to me why dataBuf = malloc((dataSize+1) * sizeof(TCHAR)); already adds a 1 pulled out of thin air. ------------------------------------------------------- Date: 2001-Feb-22 08:36 By: theller Comment: There's another semicolon after the second loop, in the else-clause of the if(skipCore) statement. I'm not sure whether the semicolon should be inserted or not, IF it is inserted, the buffer is too small and the RegQueryValueEx() fails with error 234 (More data is available). Well, only on Win98 and if there are no subkeys. ------------------------------------------------------- Date: 2001-Feb-21 17:55 By: tim_one Comment: Assigned to Mark, as it's his code and I don't understand it offhand. Mark, this is a very simple (one-liner) patch. theller, I don't understand your comment. What semicolon are you talking about? The preceding loop incremented dataSize by the lengths of all items, + one more for each item to hold a semicolon after it. And that's all the semicolons there are. It appears to me that the second loop is *incorrect*, in that it adds a semicolon whenever index>0, regardless of whether ppPaths[index] is or isn't NULL, and so may end up inserting arbitrarily more semicolons than the preceding loop saved space for. But if that's what's going on, your patch doesn't fix it in general, it would just cover up the simplest failing case. ------------------------------------------------------- Date: 2001-Feb-21 13:07 By: theller Comment: Assigned to Tim, one of the windows guys:-) This is urgent. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103933&group_id=5470 From noreply@sourceforge.net Fri Feb 23 11:39:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Feb 2001 03:39:53 -0800 Subject: [Patches] [Patch #103933] sys.path not set correctly when embedded Message-ID: Patch #103933 has been updated. Project: python Category: Windows Status: Open Submitted by: theller Assigned to : mhammond Summary: sys.path not set correctly when embedded Follow-Ups: Date: 2001-Feb-23 03:39 By: mhammond Comment: Checked in: /cvsroot/python/python/dist/src/PC/getpathp.c,v <-- getpathp.c new revision: 1.23; previous revision: 1.22 ------------------------------------------------------- Date: 2001-Feb-23 03:31 By: mhammond Comment: Shouldn't have tried to be so slack :) The online docs are the same as mine - says nothing about this specific parameter, but for every other "length of string" param bar one, it specifically says "not include the NULL". Strangely, the one exception is lpcMaxSubKeyLen which says the NULL _is_ included on 9x and not on 2k. However, I think it a reasonable assumption that this param is "normal" and doesn't. The fact it works better this way also helps ;-) ------------------------------------------------------- Date: 2001-Feb-23 03:28 By: mhammond Comment: Shouldn't have tried to be so slack :) The online docs are the same as mine - says nothing about this specific parameter, but for every other "length of string" param bar one, it specifically says "not include the NULL". Strangely, the one exception is lpcMaxSubKeyLen which says the NULL _is_ included on 9x and not on 2k. However, I think it a reasonable assumption that this param is "normal" and doesn't. The fact it works better this way also helps ;-) ------------------------------------------------------- Date: 2001-Feb-23 03:13 By: mhammond Comment: *sigh* - in my haste, my eyes fixed on the parameter above (lpcMaxValueNameLen) which says "The length does not include the terminating null character." In my docs, this specific param (lpcMaxValueLen) says nothing about the size of the string (but does say the param itself can be none). Hrm - actually, I can test this in 98 - (comes back) - yes, I can repro the behaviour (garbage on sys.path) before the patch, and the correct behaviour after on 9x. OK - I think I should check it in! ------------------------------------------------------- Date: 2001-Feb-23 01:02 By: tim_one Comment: Mark overwrote your patch with his. That is, his patch is *right here*. It's 4am here, and I have to get some sleep, so do try it! ------------------------------------------------------- Date: 2001-Feb-23 00:23 By: theller Comment: I would be happy to test your new patch (running Win98 with VC6 under VMWare under 2000), but where is it? BTW: RegQueryInfoKey as documented, includes NULL! ------------------------------------------------------- Date: 2001-Feb-22 23:44 By: mhammond Comment: OK - stepping through in the debugger, it appears as tho Win2k always gives us a much bigger buffer. Stepping through in the debugger with a value of "foo" in the registry, 2k told me the buffer size was 8! Can speculate as to why, but that doesn't help. Unfortunately, I don't have MSVC etc on my 9x box, but I can only speculate that there RegKeyQueryInfo() there works as documented - returning exactly the size without room for the NULL. Hence we would hit this bug there. Uploading a revised patch which has _not_ been tested on Win9x, but the behaviour was verified in the debugger on 2k, even if the sizes werent set to kill us. I would be grateful if someone could test this on Win9x for me. A reasonable way to test is to rename your existing "2.1" key to "2.1_save", and create a new key with just a PythonPath value. Then copy Python.exe to your temp dir and run it. I'll check it in as soon as I hear someone has done that, or Tim tells me to ------------------------------------------------------- Date: 2001-Feb-22 22:58 By: mhammond Comment: Yes - Tim spotted it. the dataSize returned from RegQueryInfoKey() does not include the NULL, hence the one from thin air. Ive added a comment :) If skipcore is false, we do indeed stick the extra semicolon for the non-existant sub-values, and this makes the buffer one byte too small. The code is still a little strange as it used to work on Win16, where the sizes weren't available in advance. I'll add a comment about that too ;-) I will work out an appropriate patch and submit a new version in a few minutes. ------------------------------------------------------- Date: 2001-Feb-22 22:06 By: tim_one Comment: Yes, I saw that. I still want Mark to look at it, though: the code isn't clear (neither of us understands why it's doing what it's doing), and I don't have the bandwidth to try to sort this out before the beta release. You *may* have just hit the nail on the head: if there are no subkeys and skipcore is false, then "the preceding loop" didn't allocate any space for this semicolon, and indeed the semicolon should *not* be there. In that case a correct fix is to suppress the semicolon, not to add 1 at random beforehand (when the code is already murky, making it murkier is a Bad Idea). But, even in that case, it's unclear to me why dataBuf = malloc((dataSize+1) * sizeof(TCHAR)); already adds a 1 pulled out of thin air. ------------------------------------------------------- Date: 2001-Feb-22 08:36 By: theller Comment: There's another semicolon after the second loop, in the else-clause of the if(skipCore) statement. I'm not sure whether the semicolon should be inserted or not, IF it is inserted, the buffer is too small and the RegQueryValueEx() fails with error 234 (More data is available). Well, only on Win98 and if there are no subkeys. ------------------------------------------------------- Date: 2001-Feb-21 17:55 By: tim_one Comment: Assigned to Mark, as it's his code and I don't understand it offhand. Mark, this is a very simple (one-liner) patch. theller, I don't understand your comment. What semicolon are you talking about? The preceding loop incremented dataSize by the lengths of all items, + one more for each item to hold a semicolon after it. And that's all the semicolons there are. It appears to me that the second loop is *incorrect*, in that it adds a semicolon whenever index>0, regardless of whether ppPaths[index] is or isn't NULL, and so may end up inserting arbitrarily more semicolons than the preceding loop saved space for. But if that's what's going on, your patch doesn't fix it in general, it would just cover up the simplest failing case. ------------------------------------------------------- Date: 2001-Feb-21 13:07 By: theller Comment: Assigned to Tim, one of the windows guys:-) This is urgent. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103933&group_id=5470 From noreply@sourceforge.net Fri Feb 23 11:40:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Feb 2001 03:40:19 -0800 Subject: [Patches] [Patch #103933] sys.path not set correctly when embedded Message-ID: Patch #103933 has been updated. Project: python Category: Windows Status: Accepted Submitted by: theller Assigned to : mhammond Summary: sys.path not set correctly when embedded Follow-Ups: Date: 2001-Feb-23 03:39 By: mhammond Comment: Checked in: /cvsroot/python/python/dist/src/PC/getpathp.c,v <-- getpathp.c new revision: 1.23; previous revision: 1.22 ------------------------------------------------------- Date: 2001-Feb-23 03:31 By: mhammond Comment: Shouldn't have tried to be so slack :) The online docs are the same as mine - says nothing about this specific parameter, but for every other "length of string" param bar one, it specifically says "not include the NULL". Strangely, the one exception is lpcMaxSubKeyLen which says the NULL _is_ included on 9x and not on 2k. However, I think it a reasonable assumption that this param is "normal" and doesn't. The fact it works better this way also helps ;-) ------------------------------------------------------- Date: 2001-Feb-23 03:28 By: mhammond Comment: Shouldn't have tried to be so slack :) The online docs are the same as mine - says nothing about this specific parameter, but for every other "length of string" param bar one, it specifically says "not include the NULL". Strangely, the one exception is lpcMaxSubKeyLen which says the NULL _is_ included on 9x and not on 2k. However, I think it a reasonable assumption that this param is "normal" and doesn't. The fact it works better this way also helps ;-) ------------------------------------------------------- Date: 2001-Feb-23 03:13 By: mhammond Comment: *sigh* - in my haste, my eyes fixed on the parameter above (lpcMaxValueNameLen) which says "The length does not include the terminating null character." In my docs, this specific param (lpcMaxValueLen) says nothing about the size of the string (but does say the param itself can be none). Hrm - actually, I can test this in 98 - (comes back) - yes, I can repro the behaviour (garbage on sys.path) before the patch, and the correct behaviour after on 9x. OK - I think I should check it in! ------------------------------------------------------- Date: 2001-Feb-23 01:02 By: tim_one Comment: Mark overwrote your patch with his. That is, his patch is *right here*. It's 4am here, and I have to get some sleep, so do try it! ------------------------------------------------------- Date: 2001-Feb-23 00:23 By: theller Comment: I would be happy to test your new patch (running Win98 with VC6 under VMWare under 2000), but where is it? BTW: RegQueryInfoKey as documented, includes NULL! ------------------------------------------------------- Date: 2001-Feb-22 23:44 By: mhammond Comment: OK - stepping through in the debugger, it appears as tho Win2k always gives us a much bigger buffer. Stepping through in the debugger with a value of "foo" in the registry, 2k told me the buffer size was 8! Can speculate as to why, but that doesn't help. Unfortunately, I don't have MSVC etc on my 9x box, but I can only speculate that there RegKeyQueryInfo() there works as documented - returning exactly the size without room for the NULL. Hence we would hit this bug there. Uploading a revised patch which has _not_ been tested on Win9x, but the behaviour was verified in the debugger on 2k, even if the sizes werent set to kill us. I would be grateful if someone could test this on Win9x for me. A reasonable way to test is to rename your existing "2.1" key to "2.1_save", and create a new key with just a PythonPath value. Then copy Python.exe to your temp dir and run it. I'll check it in as soon as I hear someone has done that, or Tim tells me to ------------------------------------------------------- Date: 2001-Feb-22 22:58 By: mhammond Comment: Yes - Tim spotted it. the dataSize returned from RegQueryInfoKey() does not include the NULL, hence the one from thin air. Ive added a comment :) If skipcore is false, we do indeed stick the extra semicolon for the non-existant sub-values, and this makes the buffer one byte too small. The code is still a little strange as it used to work on Win16, where the sizes weren't available in advance. I'll add a comment about that too ;-) I will work out an appropriate patch and submit a new version in a few minutes. ------------------------------------------------------- Date: 2001-Feb-22 22:06 By: tim_one Comment: Yes, I saw that. I still want Mark to look at it, though: the code isn't clear (neither of us understands why it's doing what it's doing), and I don't have the bandwidth to try to sort this out before the beta release. You *may* have just hit the nail on the head: if there are no subkeys and skipcore is false, then "the preceding loop" didn't allocate any space for this semicolon, and indeed the semicolon should *not* be there. In that case a correct fix is to suppress the semicolon, not to add 1 at random beforehand (when the code is already murky, making it murkier is a Bad Idea). But, even in that case, it's unclear to me why dataBuf = malloc((dataSize+1) * sizeof(TCHAR)); already adds a 1 pulled out of thin air. ------------------------------------------------------- Date: 2001-Feb-22 08:36 By: theller Comment: There's another semicolon after the second loop, in the else-clause of the if(skipCore) statement. I'm not sure whether the semicolon should be inserted or not, IF it is inserted, the buffer is too small and the RegQueryValueEx() fails with error 234 (More data is available). Well, only on Win98 and if there are no subkeys. ------------------------------------------------------- Date: 2001-Feb-21 17:55 By: tim_one Comment: Assigned to Mark, as it's his code and I don't understand it offhand. Mark, this is a very simple (one-liner) patch. theller, I don't understand your comment. What semicolon are you talking about? The preceding loop incremented dataSize by the lengths of all items, + one more for each item to hold a semicolon after it. And that's all the semicolons there are. It appears to me that the second loop is *incorrect*, in that it adds a semicolon whenever index>0, regardless of whether ppPaths[index] is or isn't NULL, and so may end up inserting arbitrarily more semicolons than the preceding loop saved space for. But if that's what's going on, your patch doesn't fix it in general, it would just cover up the simplest failing case. ------------------------------------------------------- Date: 2001-Feb-21 13:07 By: theller Comment: Assigned to Tim, one of the windows guys:-) This is urgent. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103933&group_id=5470 From noreply@sourceforge.net Fri Feb 23 11:55:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Feb 2001 03:55:53 -0800 Subject: [Patches] [Patch #103899] Remove modules configured in Setup Message-ID: Patch #103899 has been updated. Project: python Category: distutils Status: Open Submitted by: akuchling Assigned to : theller Summary: Remove modules configured in Setup Follow-Ups: Date: 2001-Feb-23 03:55 By: theller Comment: Yes, this look much better! ------------------------------------------------------- Date: 2001-Feb-21 20:08 By: akuchling Comment: This takes a much simpler approach; if a module is in Modules/Setup, don't compile it. Then you can set flags to yours heart's content in Setup, and you can sing and jump and dance about and the little goat-footed balloon man will... sorry. ------------------------------------------------------- Date: 2001-Feb-21 12:24 By: akuchling Comment: Setup.dist, you're thinking of, but yes, you've got the right idea. ------------------------------------------------------- Date: 2001-Feb-21 12:21 By: theller Comment: Shouldn't Modules/Setup be hacked or recreated from Setup.in in this case (although I'm not at all familiar with this stuff) ------------------------------------------------------- Date: 2001-Feb-21 12:18 By: akuchling Comment: It's needed to handle special-cases; what if GDBM is installed in /depot/gnu/ instead of either OTOH, maybe this fixes the wrong problem. If the setup.py script parsed Modules/Setup and ignored any modules turned on in that file, that might be much easier that having a bunch of switches. Hm... ------------------------------------------------------- Date: 2001-Feb-21 12:15 By: theller Comment: The previous one was my comment, but I wasn't logged in. sorry. ------------------------------------------------------- Date: 2001-Feb-21 12:13 By: nobody Comment: Looks as if it could work, but I only can say this from reading the patch. But: Why is it neccessary? Why aren't the include-directories defined in the Extension instances? Would anyone sane give them from the command line? ------------------------------------------------------- Date: 2001-Feb-21 11:47 By: akuchling Comment: New version of the patch, this time as a context diff. ------------------------------------------------------- Date: 2001-Feb-21 11:40 By: akuchling Comment: Reassigning to Thomas Heller (since he's done a fair bit of Distutil hacking) for a sanity check. ------------------------------------------------------- Date: 2001-Feb-20 07:34 By: akuchling Comment: Greg, can you please take a look at this in the next day or two? If you can't, let me know and I'll reassign it to someone else. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103899&group_id=5470 From noreply@sourceforge.net Fri Feb 23 15:21:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Feb 2001 07:21:32 -0800 Subject: [Patches] [Patch #103972] threaded profiler. Message-ID: Patch #103972 has been updated. Project: python Category: demos and tools Status: Open Submitted by: amila Assigned to : nobody Summary: threaded profiler. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103972&group_id=5470 From noreply@sourceforge.net Fri Feb 23 15:27:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Feb 2001 07:27:27 -0800 Subject: [Patches] [Patch #103972] threaded profiler. Message-ID: Patch #103972 has been updated. Project: python Category: demos and tools Status: Open Submitted by: amila Assigned to : nobody Summary: threaded profiler. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103972&group_id=5470 From noreply@sourceforge.net Fri Feb 23 16:28:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Feb 2001 08:28:37 -0800 Subject: [Patches] [Patch #103937] Attempt at BSDDB fix Message-ID: Patch #103937 has been updated. Project: python Category: Build Status: Closed Submitted by: akuchling Assigned to : akuchling Summary: Attempt at BSDDB fix Follow-Ups: Date: 2001-Feb-23 08:28 By: akuchling Comment: Checked in to revision 1.29 of setup.py. ------------------------------------------------------- Date: 2001-Feb-22 08:04 By: twouters Comment: After removing the "and 0", it works on RedHat 7 with all three BSDDB versions installed, and didn't break on BSDI (which was already working okay :) I assume the 'and 0' is an oversight from a debug version. ------------------------------------------------------- Date: 2001-Feb-22 08:03 By: akuchling Comment: Slightly revised version, taking out an "if ... and 0" that I forgot to take out. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103937&group_id=5470 From noreply@sourceforge.net Fri Feb 23 16:29:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Feb 2001 08:29:30 -0800 Subject: [Patches] [Patch #103886] Building bsddb module with/without "-ldb" - BugID 132600 Message-ID: Patch #103886 has been updated. Project: python Category: Build Status: Rejected Submitted by: mfavas Assigned to : akuchling Summary: Building bsddb module with/without "-ldb" - BugID 132600 Follow-Ups: Date: 2001-Feb-23 08:29 By: akuchling Comment: Marking as rejected, since patch #103937 was checked in. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103886&group_id=5470 From noreply@sourceforge.net Fri Feb 23 16:33:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Feb 2001 08:33:07 -0800 Subject: [Patches] [Patch #103899] Remove modules configured in Setup Message-ID: Patch #103899 has been updated. Project: python Category: distutils Status: Closed Submitted by: akuchling Assigned to : akuchling Summary: Remove modules configured in Setup Follow-Ups: Date: 2001-Feb-23 08:33 By: akuchling Comment: Checked in to revision 1.30 of setup.py. ------------------------------------------------------- Date: 2001-Feb-23 03:55 By: theller Comment: Yes, this look much better! ------------------------------------------------------- Date: 2001-Feb-21 20:08 By: akuchling Comment: This takes a much simpler approach; if a module is in Modules/Setup, don't compile it. Then you can set flags to yours heart's content in Setup, and you can sing and jump and dance about and the little goat-footed balloon man will... sorry. ------------------------------------------------------- Date: 2001-Feb-21 12:24 By: akuchling Comment: Setup.dist, you're thinking of, but yes, you've got the right idea. ------------------------------------------------------- Date: 2001-Feb-21 12:21 By: theller Comment: Shouldn't Modules/Setup be hacked or recreated from Setup.in in this case (although I'm not at all familiar with this stuff) ------------------------------------------------------- Date: 2001-Feb-21 12:18 By: akuchling Comment: It's needed to handle special-cases; what if GDBM is installed in /depot/gnu/ instead of either OTOH, maybe this fixes the wrong problem. If the setup.py script parsed Modules/Setup and ignored any modules turned on in that file, that might be much easier that having a bunch of switches. Hm... ------------------------------------------------------- Date: 2001-Feb-21 12:15 By: theller Comment: The previous one was my comment, but I wasn't logged in. sorry. ------------------------------------------------------- Date: 2001-Feb-21 12:13 By: nobody Comment: Looks as if it could work, but I only can say this from reading the patch. But: Why is it neccessary? Why aren't the include-directories defined in the Extension instances? Would anyone sane give them from the command line? ------------------------------------------------------- Date: 2001-Feb-21 11:47 By: akuchling Comment: New version of the patch, this time as a context diff. ------------------------------------------------------- Date: 2001-Feb-21 11:40 By: akuchling Comment: Reassigning to Thomas Heller (since he's done a fair bit of Distutil hacking) for a sanity check. ------------------------------------------------------- Date: 2001-Feb-20 07:34 By: akuchling Comment: Greg, can you please take a look at this in the next day or two? If you can't, let me know and I'll reassign it to someone else. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103899&group_id=5470 From noreply@sourceforge.net Fri Feb 23 16:37:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Feb 2001 08:37:13 -0800 Subject: [Patches] [Patch #103678] setup.py.in Message-ID: Patch #103678 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : akuchling Summary: setup.py.in Follow-Ups: Date: 2001-Feb-23 08:37 By: akuchling Comment: Donn, is this patch still relevant? Do there remain BeOS-specific issues to fix? Probably separate patches and bugs should be opened to handle any outstanding problems. ------------------------------------------------------- Date: 2001-Feb-08 15:43 By: donnc Comment: Not worried, just was trying to point out the good side of a throw-away system for the dirty business of platform warts. Anyway, with all that stuff to get done in setup.py, obviously the release is a ways off yet. ------------------------------------------------------- Date: 2001-Feb-08 14:51 By: lemburg Comment: Na, it's not higher, only in this case, the design is going in the wrong direction. The new setup.py mechanism was meant to allow as much automatic configuration as possible (previously people had to edit Modules/Setup which was not difficult, but obscure enough to keep people from enabling important add-ons such as Tkinter). Now with the setup.py auto-detection mechanisms in place, there should be much less user interaction required to get a fully functional system. As for the other patches: many of the Python core team are currently out of town so there's a natural delay there. Nothing to worry about though. ------------------------------------------------------- Date: 2001-Feb-08 11:16 By: donnc Comment: I would be happy with extra symbols in Makefile, for setup.py to use. I think this system will be somewhat obscure for someone trying to figure out how to make a build work, so some pointer comments at the top of setup.py would be good. The last point there is not so clear to me -- it sounds like there's an intent to move a lot of logic from "configure" to setup.py. I look forward to seeing whether that does give us much more power and flexibility. It will put some pressure on the Python code base, though - I already have changes in for distutils and even os.py, to get through the build, not to mention the two unsuccessful attempts to get changes into setup.py. In 2.0, I came along pretty late in the beta with changes that make it build for BeOS. Here I am right at the beginning of 2.1 alpha, but the hurdle seems a lot higher. ------------------------------------------------------- Date: 2001-Feb-08 10:45 By: nascheme Comment: One more reason for not using step.py.in or setup.cfg.in: The Makefile is available to distutils when building extension modules after the source is gone (ie. its installed in lib). ------------------------------------------------------- Date: 2001-Feb-08 10:29 By: lemburg Comment: I'd prefer if you'd put all the code into setup.py -- the tools are all there. If you need extra symbols, then have configure place them in the Makefile or config.h. Both are available for distutils to use. Platform specifica can then be dealt with under Python's control which gives you much more power and flexibility. ------------------------------------------------------- Date: 2001-Feb-08 10:12 By: donnc Comment: That's OK with me, all I need is a place where I can deal with platform specific issues, and it doesn't matter a bit to me where. setup.py.in, Makefile, setup.cfg, write the stuff right into setup.py (e.g., if platform == 'Darwin'). What do you like? ------------------------------------------------------- Date: 2001-Feb-08 08:38 By: akuchling Comment: Agreed; generating Makefiles from the configure script is bad enough, and generating executable scripts is worse still. Reintroducing setup.cfg.in would be better, if that proves necessary. ------------------------------------------------------- Date: 2001-Feb-08 05:01 By: lemburg Comment: Using setup.py.in is the wrong strategy here: you should consider placing the symbols into the generated Makefile or config.h and then have setup.py parse these files (the tools for this are all there in distutils). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103678&group_id=5470 From noreply@sourceforge.net Fri Feb 23 18:22:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Feb 2001 10:22:21 -0800 Subject: [Patches] [Patch #103678] setup.py.in Message-ID: Patch #103678 has been updated. Project: python Category: Build Status: Open Submitted by: donnc Assigned to : akuchling Summary: setup.py.in Follow-Ups: Date: 2001-Feb-23 10:22 By: donnc Comment: Yes, it's still waiting to be resolved. The patch at least illustrates the problems (and of course it would also solve them if applied.) I have been hoping that you would put some thought into it, since your sense of direction on it is at least clear enough to know that it's different from where I would go. Since there's plenty of specific information about what needs to be done, I would prefer that you do at least something for it, in setup.py. Then after you have wrestled with the issues, I can check it out and see what you came up with, and if necessary straighten out anything that doesn't actually work. If you want, I might be able to take a look at what it would take to remove every single directory path literal ('/usr/X11R5', '/usr/lib/termcap', etc.), every platform literal ('aix', 'sunos5', etc.) and every reference to a platform specific flag ("linker_so + ' -shared' - what's up with that?) and put it in configure if it's really needed at all. Don't know if I could get that done for 2.1a3, but the sooner that gets cleaned up the better. ------------------------------------------------------- Date: 2001-Feb-23 08:37 By: akuchling Comment: Donn, is this patch still relevant? Do there remain BeOS-specific issues to fix? Probably separate patches and bugs should be opened to handle any outstanding problems. ------------------------------------------------------- Date: 2001-Feb-08 15:43 By: donnc Comment: Not worried, just was trying to point out the good side of a throw-away system for the dirty business of platform warts. Anyway, with all that stuff to get done in setup.py, obviously the release is a ways off yet. ------------------------------------------------------- Date: 2001-Feb-08 14:51 By: lemburg Comment: Na, it's not higher, only in this case, the design is going in the wrong direction. The new setup.py mechanism was meant to allow as much automatic configuration as possible (previously people had to edit Modules/Setup which was not difficult, but obscure enough to keep people from enabling important add-ons such as Tkinter). Now with the setup.py auto-detection mechanisms in place, there should be much less user interaction required to get a fully functional system. As for the other patches: many of the Python core team are currently out of town so there's a natural delay there. Nothing to worry about though. ------------------------------------------------------- Date: 2001-Feb-08 11:16 By: donnc Comment: I would be happy with extra symbols in Makefile, for setup.py to use. I think this system will be somewhat obscure for someone trying to figure out how to make a build work, so some pointer comments at the top of setup.py would be good. The last point there is not so clear to me -- it sounds like there's an intent to move a lot of logic from "configure" to setup.py. I look forward to seeing whether that does give us much more power and flexibility. It will put some pressure on the Python code base, though - I already have changes in for distutils and even os.py, to get through the build, not to mention the two unsuccessful attempts to get changes into setup.py. In 2.0, I came along pretty late in the beta with changes that make it build for BeOS. Here I am right at the beginning of 2.1 alpha, but the hurdle seems a lot higher. ------------------------------------------------------- Date: 2001-Feb-08 10:45 By: nascheme Comment: One more reason for not using step.py.in or setup.cfg.in: The Makefile is available to distutils when building extension modules after the source is gone (ie. its installed in lib). ------------------------------------------------------- Date: 2001-Feb-08 10:29 By: lemburg Comment: I'd prefer if you'd put all the code into setup.py -- the tools are all there. If you need extra symbols, then have configure place them in the Makefile or config.h. Both are available for distutils to use. Platform specifica can then be dealt with under Python's control which gives you much more power and flexibility. ------------------------------------------------------- Date: 2001-Feb-08 10:12 By: donnc Comment: That's OK with me, all I need is a place where I can deal with platform specific issues, and it doesn't matter a bit to me where. setup.py.in, Makefile, setup.cfg, write the stuff right into setup.py (e.g., if platform == 'Darwin'). What do you like? ------------------------------------------------------- Date: 2001-Feb-08 08:38 By: akuchling Comment: Agreed; generating Makefiles from the configure script is bad enough, and generating executable scripts is worse still. Reintroducing setup.cfg.in would be better, if that proves necessary. ------------------------------------------------------- Date: 2001-Feb-08 05:01 By: lemburg Comment: Using setup.py.in is the wrong strategy here: you should consider placing the symbols into the generated Makefile or config.h and then have setup.py parse these files (the tools for this are all there in distutils). ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103678&group_id=5470 From noreply@sourceforge.net Fri Feb 23 21:28:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Feb 2001 13:28:07 -0800 Subject: [Patches] [Patch #103977] Rename config.h to pyac_config.h, per SF bug #131774 Message-ID: Patch #103977 has been updated. Project: python Category: Build Status: Open Submitted by: twouters Assigned to : nobody Summary: Rename config.h to pyac_config.h, per SF bug #131774 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103977&group_id=5470 From noreply@sourceforge.net Fri Feb 23 21:32:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Feb 2001 13:32:06 -0800 Subject: [Patches] [Patch #103977] Rename config.h to pyac_config.h, per SF bug #131774 Message-ID: Patch #103977 has been updated. Project: python Category: Build Status: Open Submitted by: twouters Assigned to : tim_one Summary: Rename config.h to pyac_config.h, per SF bug #131774 Follow-Ups: Date: 2001-Feb-23 13:32 By: twouters Comment: Apologies for the large blurb in the 'details' section. I keep forgetting SF strips *all* whitespace from that block :( Assigning to Tim "The Windows Bot" Peters to test (and fix) the Windows build changes. Let me know if your patch still doesn't work and you want me to send you patched files instead, Tim. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103977&group_id=5470 From noreply@sourceforge.net Fri Feb 23 21:34:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Feb 2001 13:34:12 -0800 Subject: [Patches] [Patch #103978] config.h -> pyac_config.h change for OS2 Message-ID: Patch #103978 has been updated. Project: python Category: Build Status: Open Submitted by: twouters Assigned to : nobody Summary: config.h -> pyac_config.h change for OS2 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103978&group_id=5470 From deposito@eastmail.com Sat Feb 24 05:16:46 2001 From: deposito@eastmail.com (deposito@eastmail.com) Date: Sat, 24 Feb 2001 00:16:46 -0500 Subject: [Patches] REGALE UN DOMINIO O REGISTRE EL SUYO Message-ID: Si tiene una empresa en marcha, un proyecto o una idea registre su dominio en Internet AHORA, tal vez mañana sea demasiado tarde. Si conoce a alguien en esta situacion y no sabe que regalarle por navidad regalele un dominio, es original y quedara bien. Vea toda la informacion referente al registro de dominios en http://dominios.es-homepage.com REGALE UN DOMINIO O REGISTRE EL SUYO Otros servicios: hospedaje, redireccion de dominio, ...etc ¿HAS DE RENOVAR EL REGISTRO DE TU DOMINIO? PRECIO ESPECIAL POR TRANSFERENCIA DE DOMINIO (20$) PRECIO DE HOSTING IMBATIBLE -------------------------------------------------------------------------------------- Mensaje enviado por el Centro de Mensajes Masivos -------------------------------------------------------------------------------------- -----------------------REMOVE------------------------------ SI NO QUIERE RECIBIR MAS MENSAJES DESDE ESTA DIRECCION VAYA AL LINK INDICADO Y SERA DADO DE BAJA INMEDIATAMENTE. DICHO LINK ES UN SERVICIO INDEPENDIENTE DEL ENVIO DE ESTE EMAIL ---------------------------------------------------------------------- dar de baja de la lista de distribucion - remove distribution list http://borrame.onweb.cx RemovingNet. Cuentas gratuitas para el control de bajas. Free accounts for the control of "unsubscribes" RemovingNet nada tiene que ver con este email ni con su contenido RemovingNet nothing has to do with this email nor with contained his ---------------------------------------------------------------- IF YOU DON'T WANT TO RECEIVE MORE MESSAGES FROM US, PLEASE CLICK ON THE LINK BELOW. http://borrame.onweb.cx YOUR EMAIL ADDRESS WILL BE REMOVED FROM OUR DATA BASE IMMEDIATELY. REMOVING.NET IS AN INDEPENDENT SERVICE -----------------------REMOVE------------------------------ From noreply@sourceforge.net Sat Feb 24 06:38:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Feb 2001 22:38:49 -0800 Subject: [Patches] [Patch #103930] Ignore error making grammar src if srcdir is readonly Message-ID: Patch #103930 has been updated. Project: python Category: Build Status: Open Submitted by: nascheme Assigned to : twouters Summary: Ignore error making grammar src if srcdir is readonly Follow-Ups: Date: 2001-Feb-23 22:38 By: nascheme Comment: "If make doesn't do what you expect it to, it's a good chance the makefile is wrong." -- BSD Make manual Some dependances were missing. Can you give the current patch a whirl? BTW, why to you think rebuilding the grammar source is a bad idea? ------------------------------------------------------- Date: 2001-Feb-22 08:20 By: twouters Comment: This doesn't look like it does what it is supposed to. At least, after applying the patch, Grammar doesn't get rebuilt at all, even when graminit.h is missing: gcc -D_HAVE_BSDI -c -g -O2 -Wall -Wstrict-prototypes -I. -I../Include -DHAVE_CONFIG_H -o Python/compile.o ../Python/compile.c ../Python/compile.c:17: graminit.h: No such file or directory I can't seem to get it to make it, even though there is a $(GRAMINIT_H) dependancy. 'make Include/graminit.h' no longer works, and neither does anything else I can come up with. But I'd like to note I'm still against rebuilding the Grammar automatically in releases :-) I'm not really sure if it's still worth rebuilding the Grammar each time, myself. It was when I did the original (horribly broken) patch, but that was in the heat of 2.0, with lots of Grammar-changing patch-proposals about. ------------------------------------------------------- Date: 2001-Feb-21 05:43 By: nascheme Comment: Does this make sense? My last change making graminit.h and graminit.c in the build directory was wrong. The compiler does not understand VPATH so the include file could not be found. The new idea is to continue the build even if the grammar sources cannot be regenerated (maybe the source directory is readonly). I don't want to remove the target completely since someone may change the grammar and forget to generate the source. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103930&group_id=5470 From noreply@sourceforge.net Sat Feb 24 07:52:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Feb 2001 23:52:10 -0800 Subject: [Patches] [Patch #103985] Add support for weak-keyed dictionaries Message-ID: Patch #103985 has been updated. Project: python Category: Modules Status: Open Submitted by: loewis Assigned to : nobody Summary: Add support for weak-keyed dictionaries ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103985&group_id=5470 From noreply@sourceforge.net Sat Feb 24 07:52:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Feb 2001 23:52:37 -0800 Subject: [Patches] [Patch #103985] Add support for weak-keyed dictionaries Message-ID: Patch #103985 has been updated. Project: python Category: Modules Status: Open Submitted by: loewis Assigned to : fdrake Summary: Add support for weak-keyed dictionaries ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103985&group_id=5470 From noreply@sourceforge.net Sat Feb 24 07:58:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Feb 2001 23:58:04 -0800 Subject: [Patches] [Patch #101196] IPv6 patch against 2.0 CVS tree, as of 20001230 Message-ID: Patch #101196 has been updated. Project: python Category: core (C code) Status: Open Submitted by: itojun Assigned to : fdrake Summary: IPv6 patch against 2.0 CVS tree, as of 20001230 Follow-Ups: Date: 2001-Feb-23 23:58 By: loewis Comment: After a shallow review of this patch, I found the following issues: configure.in does not need to list both enable and disable options. When running configure, I got the following error message on Linux checking whether to enable ipv6... yes checking ipv6 stack type... linux-glibc ./configure: test: too many arguments using libc The call to /usr/bin/test should be corrected; I could not find out which specific invocation caused the problem. HAVE_ADDRINFO is not used. Perhaps getaddrinfo.c/getnameinfo.c is missing in the patch? ------------------------------------------------------- Date: 2001-Jan-04 07:51 By: gvanrossum Comment: A new patch is available. I've changed the subject accordingly. Due to upload size restrictions, the patch is now at http://www.itojun.org/diary/20001230/python-2.0-v6-20001230.diff.gz ------------------------------------------------------- Date: 2000-Dec-30 07:25 By: loewis Comment: I got *many* rejects when trying to apply this patch to today's CVS tree. I recommend that patches for generated files (config.h.in, configure) are not included in the patch because they outdate too easily. A number of changes in this patch have already been done by somebody else; others just don't fit into the current code anymore (perhaps due to indentation changes?). Anyway, I'll mark the patch as out-of-date. Please let me know when you upload a new version. ------------------------------------------------------- Date: 2000-Aug-16 05:59 By: itojun Comment: this is revised version of patch #101186 (now with my SourceForge accout... i'm not familiar with the system here, so forgive my possible mistake). 1.6b1 patch applied mostly clean to 2.0. It is confirmed that: - 1.6b1 + IPv6 patch works fine on NetBSD 1.4.2 + KAME, and NetBSD 1.5 - 1.6b1 + IPv6 patch works fine on NetBSD 1.4.2 (NOT an IPv6 ready machine) - 2.0 CVS tree + IPv6 patch works fine on NetBSD + KAME forgot to attach the following into the diff - so i attach it (README.v6) here as comment. I have submitted the patch for 1.5.1, 1.5.2 and 1.6b1, all hit a bad timing - bad luck. contact: core@kame.net, or itojun@kame.net --- IPv6-ready python 1.6 KAME Project $KAME: README.v6,v 1.9 2000/08/15 02:40:38 itojun Exp $ This patchkit enables python 1.6 to perform AF_INET6 socket operations. The only affected module is Modules/socketmodule.c. Modules/socketmodule.c In most cases, IPv6 address can be placed where IPv4 address fits. sockaddr sockaddr tuple is formatted as follows: IPv4: (host, port) IPv6: socket class methods always generate (host, port, flowinfo, scopeid). socket class methods will accept 2, 3, or 4 tuple (for backward compatibility). Compatibility warning: Some of the scripts assume that the sockaddr structure is 2 tuple, like: host, port = sock.getpeername() this will fail if you are connected to IPv6 node. socket.getaddrinfo(host, port [, family, socktype, proto, flags]) host: String or None port: String, Int or None family, socktype, proto, flags: Int, can be omitted Perform getaddrinfo(3). Returns List of the following 5 tuple: (family, socktype, proto, canonname, sockaddr) family: Int socktype: Int proto: Int canonname: String sockaddr: sockaddr (see above) See Lib/httplib.py for typical usage on the client side. socket.getnameinfo(sockaddr, flags) sockaddr: sockaddr flags: Int Perform getnameinfo(3). Returns the following 2 tuple: host: String, numeric or hostname depending on flgags port: String, numeric or portname depending on flgags socket.gethostbyname2(host, af) host: String af: Int Performs gethostbyname2(3). Returns numeric address representation for "host". socket.gethostbyaddr(addr) (behavior change if IPv6 support is compiled in) addr: String Performs gethostbyaddr(3). Returns string address representation for "addr". The function can take IPv6 numeric address as well. This behavior is not problematical, because - if you pass numeric "addr" parameter, we can always identify address family for it - return value is string address reprsentation, where IPv6 and IPv4 are not distinguishable. socket.bind(sa), socket.connect(sa) and others. (No behavior change, but be careful) See above for sockaddr format change. With Python "addr" portion of sockaddr (first element) can be string hostname. When the string hostname resolved to numeric address, it will obey address family of the socket (which was specified when socket.socket() was called). If you give some string that does not give matching address family, you will get some error. s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) # this is okay, if 'localhost' resolves to both IPv4/v6 s.connect('localhost', 80) # this is not okay, of course s.connect('::1', 80) # this is not okay, as v6only.kame.net will not resolve to IPv4 s.connect('v6only.kame.net', 80) Lib/httplib.py IPv6 ready. "host" in HTTP(host) will accept the following 3 forms: [host]:port host:port there must be only single colon host This is to allow IPv6 numeric URL (http://[host]:port/) in documents. IMHO "host:port" parsing should be implemented in urllib.py, not here. Lib/ftplib.py IPv6 ready. This uses EPSV/EPRT on IPv6 ftp. See RFC2428 for protocol details. Lib/SocketServer.py IPv6 ready. Wildcard bind on TCPServer, i.e. TCPServer(('', port)), will bind to wildcard socket on TCPServer.address_family. TCPServer.addresss_family is set to AF_INET by default, so ('', port) will usually bind AF_INET. Lib/smtplib.py, Lib/telnetlib.py, Lib/poplib.py IPv6 ready. Not much to say about protocol details - they just use TCP over IPv6. configure Configure has extra option, --enable-ipv6 and --disable-ipv6. The option controls IPv6 support feature. dynamic link issues in Modules/socketmodule.c Modules/socketmodule.c can be dynamically loaded only in the following situations: - getaddrinfo(3) and getnameinfo(3) are supplied by OS vendor in libc, and libc is dynamic link library. - OS vendor is NOT supplying getaddrinfo(3) nor getnameinfo(3), and You are configuring this package with --disable-ipv6. In this case, you'll be using missing/get{addr,name}info.c and they will refer to gethostby{name,addr}. gethostnameby{name,addr} can usually be found in dynamic-linking libc. In other situations, such as the following, please link Modules/socketmodule.c into python itself. - getaddrinfo(3) and getnameinfo(3) are supplied by OS vendor, but they are in statically linked library like libinet6.a. (KAME falls into this category) python usually links Modules/socketmodule.c into python itself (due to its popularity) so there should be no problem. restrictions - The patched tree will not use gethostbyname_r and other thread-ready libraries. Instead, it will use getaddrinfo() and getnameinfo() throughout the operation. todo - Patch bunch of library files in Lib/*.py. compatibility issues with existing scripts If you disable IPv6 support (./configure --disable-ipv6), the patched code is mostly compatible with original Python (except files in "Lib" directory modified for dual stack support). User script may choke if: - IPv4/v6 dualstack libc is supplied, python is compiled for dual stack, and script assumes some of IPv4-only behavior (especially sockaddr) - IPv4/v6 dualstack libc is supplied, python is compiled for IPv4 only, and script assumes some of IPv4-only behavior. In this case, Python socket class itself does not support IPv6, however, name resolution functions can return IPv6 names since they use IPv6-ready libc functions! I do not recommend this configuration. - script assumes certain IPv4-only version behavior in Lib/*.py. compilation If you use IPv6 features, it is assumed that you have working getaddrinfo() and getnameinfo() library functions. We have noticed that some of IPv6 stack is shipped with broken getaddrinfo(). In such cases, use missing/get{addr,name}info.c instead (but then, you need to have working getipnodeby{name,addr}). If you compile this on IPv4-only machine without get{addr,name}info, missing/get{addr,name}info.c will be used. They are from KAME IPv6 distribution and is #ifdef'ed for IPv4 only support. They are fairly complete implementation and you don't need to bother with bind 8.2 (bind 8.2 get{addr,name}info() has bugs). When compiling this kit on IPv6 node, you may need to specify some additional library paths or cpp defs. (like -linet6 or -DINET6) --enable-ipv6 will give you some warning, if the IPv6 stack is unknown to the "configure" script. Currently, the following IPv6 stacks are officially supported (i.e. we've checked that the package works well): - KAME IPv6 stack, http://www.kame.net/ References RFC2553, for getaddrinfo(3) and getnameinfo(3). Author contacts http://www.kame.net/ mailto:core@kame.net ------------------------------------------------------- Date: 2000-Aug-16 06:07 By: moshez Comment: Assigned to Tim, since he's in charge of postponing new features. I'm to timid to postpone it myself. ------------------------------------------------------- Date: 2000-Aug-16 07:00 By: fdrake Comment: Postponed until Python 2.1 -- there's not enough time to review this and get it sufficiently tested on enough IPv6-connected platforms in time for 2.0, and we're already in feature freeze. This should go into the tree very quickly once Python 2.0 has been released. Assigned to myself to open it back up after Python 2.0. ------------------------------------------------------- ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=101196&group_id=5470 From thomas@xs4all.net Sat Feb 24 15:35:44 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 24 Feb 2001 16:35:44 +0100 Subject: [Patches] RE: [Patch #103693] tupleobject.c: implement tuple.index() and t In-Reply-To: ; from markus.oberhumer@jk.uni-linz.ac.at on Sat, Feb 24, 2001 at 03:08:07PM +0100 References: Message-ID: <20010224163543.H16781@xs4all.nl> On Sat, Feb 24, 2001 at 03:08:07PM +0100, Markus F.X.J. Oberhumer wrote: > Guido, > are you really sure about this one ? > The two methods here proposed relate to the constness of > tuples (compare also with immutable_list_methods[]), > and I do indeed think that their absence is a semantical > mismatch, esp. now that strings also have methods. > And for the size argument - well, it's really just a few bytes > of code. I think Guido keeps in mind that tuples are used in a large number of places inside Python itself. Like codeobjects. Tuples are intended to be a lower-level type of object, and not cluttered with user-friendly stuff :) > On 15-Feb-2001 noreply@sourceforge.net wrote: > > Patch #103693 has been updated. > > > > Project: python > > Category: core (C code) > > Status: Closed > > Submitted by: mfx > > Assigned to : gvanrossum > > Summary: tupleobject.c: implement tuple.index() and tuple.count() > > > > Follow-Ups: > > > > Date: 2001-Feb-15 05:49 > > By: gvanrossum > > > > Comment: > > Why bother? I like the fact that when you want to do list-ish things you > > have to use lists. Use list(t).count(x) if you really want this for a > > tuple. > > > > I'm rejecting this in the name of all those users who want Python to be > > small. > > ------------------------------------------------------- > > > > Date: 2001-Feb-09 16:13 > > By: jhylton > > > > Comment: > > interested in adding this to 2.1? > > > > ------------------------------------------------------- > > > > ------------------------------------------------------- > > For more info, visit: > > > > http://sourceforge.net/patch/?func=detailpatch&patch_id=103693&group_id=5470 > > > > ---- Markus F.X.J. Oberhumer @ http://www.oberhumer.com ---- > ---- 5E CB 5C 85 DE AF 9E BF E9 DA 7E 6A 39 F8 CC 67 ---- > > 3 WARPS TO URANUS > > > _______________________________________________ > Patches mailing list > Patches@python.org > http://mail.python.org/mailman/listinfo/patches -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From guido@digicool.com Sat Feb 24 17:15:38 2001 From: guido@digicool.com (Guido van Rossum) Date: Sat, 24 Feb 2001 12:15:38 -0500 Subject: [Patches] Re: [Patch #103693] tupleobject.c: implement tuple.index() and t In-Reply-To: Your message of "Sat, 24 Feb 2001 15:08:07 +0100." References: Message-ID: <200102241715.MAA06241@cj20424-a.reston1.va.home.com> > Guido, > > are you really sure about this one ? Yes, I am. If you have a need for using count() or index() on tuples, you're using them the wrong way. Tuples should be used in situations where a small record (in Pascal terms) or struct (in C terms) would be used in other languages -- not as immutable arrays. > The two methods here proposed relate to the constness of > tuples (compare also with immutable_list_methods[]), String methods were introduced for a good reason -- the introduction of Unicode. > and I do indeed think that their absence is a semantical > mismatch, esp. now that strings also have methods. I think adding these particular methods to tuples will just propagate the misunderstanding that tuples are primarily sequences -- they're not. > And for the size argument - well, it's really just a few bytes > of code. I didn't mean code size -- I meant stuff that has to be taught, learned, documented. > Markus > (author of PySol) Thanks for PySol, Markus! It's an excellent game and has even drawn people into learning Python! --Guido van Rossum (home page: http://www.python.org/~guido/) From donwulff@nic.fi Sun Feb 25 19:23:03 2001 From: donwulff@nic.fi (Jukka Santala) Date: Sun, 25 Feb 2001 21:23:03 +0200 Subject: [Patches] WinSocks... Message-ID: <000a01c09f60$604e87d0$48dee5c1@sandatac1l0st9> This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C09F71.22F00510 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit This is more of just a FYI at this time due to the lack of clarity in Microsoft documentation, but a patch against Python 2.0 socketmodule.c is included for testing etc. anyway. However, according to aforementioned documentation, there are two conditions when Microsoft WinSock could return with an indication that there was an error with the socket, for recv() (and send()) when there in fact was not: WSAEWOULDBLOCK See the Microsoft knowledge-base entry http://support.microsoft.com/support/kb/articles/q177/3/46.asp for the "detailed" coverage of this inssue. There is no indication on that bug-report that the behavior is limited to non-blocking sockets, and Windows programming sites recommend programs to be prepared to handle the WSAEWOULDBLOCK error even when one is not expected as a matter of course. A slight problem in the patch to fix this is that the KB article calls for "retrying after a while". The attached patch allows going into a tight loop waiting for change in status, because we can't return an unambigious "No data yet, but try again later" with present API.Windows non-blocking sockets should probably pass the WSAEWOULDBLOCK straight to application instead, as is presently happening, and have applications just be aware they may get this error. But there's no good reason applications should expect to get WSAEWOULDBLOCK on blocking sockets, nor a good way to determine whether we should really be getting WSAEWOULDBLOCK or not. WSAEMSGSIZE Again, fairly confusing situation. According to Windows Sockets 2 Reference, "If the datagram _or message_ is larger than the buffer supplied, the buffer is filled with the first part of the datagram, and recv generates the error WSAEMSGSIZE". Emphasis mine. While quite a few Windows programming-sites say WSAEMSGSIZE applies only to datagrams, which is logical, the Reference documentation seems to imply this is not neccessarily so. Since there are multiple vendors of WinSock stacks, it might not be safe to trust even in the behavior of invidual stack when the reference says something else. Using large enough recv() buffer might be one application-level solution, but one mans "large enough" is another's "not even near", so to allow for all contingencies and optimize performance, a patch to skip this situation is included. Ps. There's been some discussion over FD_SETSIZE for Python 2.1; according to some Windows programming sites W9X can support only 256 concurrent sockets, and some invidual WinSock implementations are reported to be limited to 64 entries in select(). However, in their high wisdom Microsoft has removed the feature for querying maximum number of sockets supported in WSAStartup in WinSocks 2 (thereby breaking many programs using WinSocks). However, since Windows uses lists instead of true masks in select(), the applications can remain happily using selectmodule with higher FD_SETSIZE as long as they don't actually use more sockets than the system provides. Making the Windows default FD_SETSIZE 256 might still save some grievances, though. -Donwulff ------=_NextPart_000_0007_01C09F71.22F00510 Content-Type: application/octet-stream; name="socketmodule.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="socketmodule.patch" --- socketmodule.old Thu Oct 19 13:37:05 2000 +++ socketmodule.c Sun Feb 25 20:59:49 2001 @@ -1173,13 +1173,31 @@ buf = PyString_FromStringAndSize((char *) 0, len); if (buf == NULL) return NULL; - Py_BEGIN_ALLOW_THREADS - n = recv(s->sock_fd, PyString_AsString(buf), len, flags); + Py_BEGIN_ALLOW_THREADS + /* No WSAEWOULDBLOCK for blockwing WinSocks; fix for issue detailed at + * http://support.microsoft.com/support/kb/articles/q177/3/46.asp + */ +#ifdef MS_WINDOWS + do { +#endif + n = recv(s->sock_fd, PyString_AsString(buf), len, flags); +#ifdef MS_WINDOWS + } while (n<0 && WSAGetLastError()==WSAEWOULDBLOCK); +#endif Py_END_ALLOW_THREADS - if (n < 0) { - Py_DECREF(buf); - return PySocket_Err(); - } + if (n < 0) { + if(WSAGetLastError==WSAEMSGSIZE) { + /* According to Windows Sockets 2 Reference: + * If the datagram or message is larger than the buffer supplied, + * the buffer is filled with the first part of the datagram, + * and recv generates the error WSAEMSGSIZE. + */ + n = len; + } else + Py_DECREF(buf); + return PySocket_Err(); + } +} if (n != len && _PyString_Resize(&buf, n) < 0) return NULL; return buf; @@ -1259,9 +1277,18 @@ if (!PyArg_ParseTuple(args, "s#|i:send", &buf, &len, &flags)) return NULL; Py_BEGIN_ALLOW_THREADS - n = send(s->sock_fd, buf, len, flags); + /* No WSAEWOULDBLOCK for blockwing WinSocks; fix for issue detailed at + * http://support.microsoft.com/support/kb/articles/q177/3/46.asp + */ +#ifdef MS_WINDOWS + do { +#endif + n = send(s->sock_fd, buf, len, flags); +#ifdef MS_WINDOWS + } while (n<0 && WSAGetLastError()==WSAEWOULDBLOCK); +#endif Py_END_ALLOW_THREADS - if (n < 0) + if (n < 0) return PySocket_Err(); return PyInt_FromLong((long)n); } ------=_NextPart_000_0007_01C09F71.22F00510-- From tim.one@home.com Sun Feb 25 20:16:32 2001 From: tim.one@home.com (Tim Peters) Date: Sun, 25 Feb 2001 15:16:32 -0500 Subject: [Patches] WinSocks... In-Reply-To: <000a01c09f60$604e87d0$48dee5c1@sandatac1l0st9> Message-ID: [Jukka Santala] > This is more of just a FYI at this time due to the lack of clarity in > Microsoft documentation, but a patch against Python 2.0 socketmodule.c is > included for testing etc. anyway. Please upload Python patches to SourceForge; the patches mailing list is a black hole. > Ps. There's been some discussion over FD_SETSIZE for Python 2.1; > ... > Making the Windows default FD_SETSIZE 256 might still save some > grievances, though. FYI, the Windows default FD_SETSIZE was boosted to 512 in Python 2.1a1. From nobody@sourceforge.net Sun Feb 25 22:21:33 2001 From: nobody@sourceforge.net (nobody) Date: Sun, 25 Feb 2001 14:21:33 -0800 Subject: [Patches] [ python-Patches-404159 ] New platform support: RISC OS Message-ID: Artifact #404159, was updated on 2001-02-25 14:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404159&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous Assigned to: Nobody/Anonymous Summary: New platform support: RISC OS Initial Comment: Hi, these patches add support for the RISC OS operating system (running on the ARM based computers that were formerly produced by the british manufacturer Acorn). The attached .tar.gz archive contains following: 1. A file Patches.txt with context diffs (relative to 2.0 release sources) to 16 C and library files. 2. A directory Lib.plat-riscos with RISC OS specific library files 3. A directory RISCOS with RISC OS specific source and support files. Thanks, Dietmar dietmar@schwertberger.de ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404159&group_id=5470 From nobody@sourceforge.net Sun Feb 25 22:28:21 2001 From: nobody@sourceforge.net (nobody) Date: Sun, 25 Feb 2001 14:28:21 -0800 Subject: [Patches] [ python-Patches-404162 ] New platform support: RISC OS Message-ID: Artifact #404162, was updated on 2001-02-25 14:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404162&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Dietmar Schwertberger Assigned to: Nobody/Anonymous Summary: New platform support: RISC OS Initial Comment: Hi, these patches add support for the RISC OS operating system (running on the computers formerly produced by the british manufacturer Acorn). The attached .tar.gz archive contains the following: 1. A file Patches.txt with context diffs (relative to 2.0 release sources) to 16 C source and library files. 2. A directory Lib.plat-riscos with RISC OS specific library files 3. A directory RISCOS with RISC OS specific C source and support files. Thanks, Dietmar dietmar@schwertberger.de ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404162&group_id=5470 From nobody@sourceforge.net Sun Feb 25 22:29:24 2001 From: nobody@sourceforge.net (nobody) Date: Sun, 25 Feb 2001 14:29:24 -0800 Subject: [Patches] [ python-Patches-404163 ] New platform support: RISC OS Message-ID: Artifact #404163, was updated on 2001-02-25 14:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404163&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Dietmar Schwertberger Assigned to: Nobody/Anonymous Summary: New platform support: RISC OS Initial Comment: Hi, these patches add support for the RISC OS operating system (running on the computers formerly produced by the british manufacturer Acorn). The attached .tar.gz archive contains the following: 1. A file Patches.txt with context diffs (relative to 2.0 release sources) to 16 C source and library files. 2. A directory Lib.plat-riscos with RISC OS specific library files 3. A directory RISCOS with RISC OS specific C source and support files. Thanks, Dietmar dietmar@schwertberger.de ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404163&group_id=5470 From nobody@sourceforge.net Sun Feb 25 22:48:16 2001 From: nobody@sourceforge.net (nobody) Date: Sun, 25 Feb 2001 14:48:16 -0800 Subject: [Patches] [ python-Patches-404162 ] New platform support: RISC OS Message-ID: Artifact #404162, was updated on 2001-02-25 14:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404162&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Dietmar Schwertberger Assigned to: Nobody/Anonymous Summary: New platform support: RISC OS Initial Comment: Hi, these patches add support for the RISC OS operating system (running on the computers formerly produced by the british manufacturer Acorn). The attached .tar.gz archive contains the following: 1. A file Patches.txt with context diffs (relative to 2.0 release sources) to 16 C source and library files. 2. A directory Lib.plat-riscos with RISC OS specific library files 3. A directory RISCOS with RISC OS specific C source and support files. Thanks, Dietmar dietmar@schwertberger.de ---------------------------------------------------------------------- Comment By: Dietmar Schwertberger Date: 2001-02-25 14:48 Message: Logged In: YES user_id=86612 The mentioned archive is available from http://www.schwertberger.de/RISCOSFiles.tar.gz Sorry for having submitted multiple, but my browser and sourceforge seem to dislike each other. Especially uploading seems to be impossible. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404162&group_id=5470 From nobody@sourceforge.net Sun Feb 25 22:56:02 2001 From: nobody@sourceforge.net (nobody) Date: Sun, 25 Feb 2001 14:56:02 -0800 Subject: [Patches] [ python-Patches-404163 ] New platform support: RISC OS Message-ID: Artifact #404163, was updated on 2001-02-25 14:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404163&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Dietmar Schwertberger Assigned to: Nobody/Anonymous Summary: New platform support: RISC OS Initial Comment: Hi, these patches add support for the RISC OS operating system (running on the computers formerly produced by the british manufacturer Acorn). The attached .tar.gz archive contains the following: 1. A file Patches.txt with context diffs (relative to 2.0 release sources) to 16 C source and library files. 2. A directory Lib.plat-riscos with RISC OS specific library files 3. A directory RISCOS with RISC OS specific C source and support files. Thanks, Dietmar dietmar@schwertberger.de ---------------------------------------------------------------------- Comment By: Dietmar Schwertberger Date: 2001-02-25 14:56 Message: Logged In: YES user_id=86612 Please ignore this patch and refer to 404162. Where are the delete and undo buttons? The mentioned archive is available from http://www.schwertberger.de/RISCOSFiles.tar.gz Sorry for having submitted multiple, but my browser and sourceforge seem to dislike each other. Especially uploading seems to be impossible. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404163&group_id=5470 From nobody@sourceforge.net Sun Feb 25 22:59:38 2001 From: nobody@sourceforge.net (nobody) Date: Sun, 25 Feb 2001 14:59:38 -0800 Subject: [Patches] [ python-Patches-404159 ] New platform support: RISC OS Message-ID: Artifact #404159, was updated on 2001-02-25 14:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404159&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous Assigned to: Nobody/Anonymous Summary: New platform support: RISC OS Initial Comment: Hi, these patches add support for the RISC OS operating system (running on the ARM based computers that were formerly produced by the british manufacturer Acorn). The attached .tar.gz archive contains following: 1. A file Patches.txt with context diffs (relative to 2.0 release sources) to 16 C and library files. 2. A directory Lib.plat-riscos with RISC OS specific library files 3. A directory RISCOS with RISC OS specific source and support files. Thanks, Dietmar dietmar@schwertberger.de ---------------------------------------------------------------------- Comment By: Dietmar Schwertberger Date: 2001-02-25 14:59 Message: Logged In: YES user_id=86612 Please ignore this patch and refer to 404162. The mentioned archive is available from http://www.schwertberger.de/RISCOSFiles.tar.gz Sorry for having submitted multiple, but my browser and sourceforge seem to dislike each other. Especially uploading seems to be impossible. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404159&group_id=5470 From nobody@sourceforge.net Mon Feb 26 10:24:04 2001 From: nobody@sourceforge.net (nobody) Date: Mon, 26 Feb 2001 02:24:04 -0800 Subject: [Patches] [ python-Patches-401196 ] IPv6 patch against 2.0 CVS tree, as of 20001230 Message-ID: Artifact #401196, was updated on 2000-08-16 05:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401196&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Jun-ichiro itojun Hagino Assigned to: Fred L. Drake, Jr. Summary: IPv6 patch against 2.0 CVS tree, as of 20001230 Initial Comment: ---------------------------------------------------------------------- Comment By: Jun-ichiro itojun Hagino Date: 2001-02-26 02:24 Message: Logged In: YES user_id=63767 about /usr/bin/test argument: does linux /usr/bin/test have -d support? if not, we may need to change configure.in slightly. you are correct that fallback getaddrinfo/getnameinfo.c was missing in the patch. sorry. a question i need to ask is, do we need to supply Python function Socket.getaddrinfo on platforms that do not have getaddrinfo(3)? HAVE_ADDRINFO is used in Include/addrinfo.h, which is also missing in the patch set i have submitted. i've put the missing files into http://www.itojun.org/diary/20001230/missing.shar. ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-02-23 23:58 Message: After a shallow review of this patch, I found the following issues: configure.in does not need to list both enable and disable options. When running configure, I got the following error message on Linux checking whether to enable ipv6... yes checking ipv6 stack type... linux-glibc ./configure: test: too many arguments using libc The call to /usr/bin/test should be corrected; I could not find out which specific invocation caused the problem. HAVE_ADDRINFO is not used. Perhaps getaddrinfo.c/getnameinfo.c is missing in the patch? ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-01-04 07:51 Message: A new patch is available. I've changed the subject accordingly. Due to upload size restrictions, the patch is now at http://www.itojun.org/diary/20001230/python-2.0-v6-20001230.diff.gz ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2000-12-30 07:25 Message: I got *many* rejects when trying to apply this patch to today's CVS tree. I recommend that patches for generated files (config.h.in, configure) are not included in the patch because they outdate too easily. A number of changes in this patch have already been done by somebody else; others just don't fit into the current code anymore (perhaps due to indentation changes?). Anyway, I'll mark the patch as out-of-date. Please let me know when you upload a new version. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2000-08-16 07:00 Message: Postponed until Python 2.1 -- there's not enough time to review this and get it sufficiently tested on enough IPv6-connected platforms in time for 2.0, and we're already in feature freeze. This should go into the tree very quickly once Python 2.0 has been released. Assigned to myself to open it back up after Python 2.0. ---------------------------------------------------------------------- Comment By: Moshe Zadka Date: 2000-08-16 06:07 Message: Assigned to Tim, since he's in charge of postponing new features. I'm to timid to postpone it myself. ---------------------------------------------------------------------- Comment By: Jun-ichiro itojun Hagino Date: 2000-08-16 05:59 Message: this is revised version of patch #101186 (now with my SourceForge accout... i'm not familiar with the system here, so forgive my possible mistake). 1.6b1 patch applied mostly clean to 2.0. It is confirmed that: - 1.6b1 + IPv6 patch works fine on NetBSD 1.4.2 + KAME, and NetBSD 1.5 - 1.6b1 + IPv6 patch works fine on NetBSD 1.4.2 (NOT an IPv6 ready machine) - 2.0 CVS tree + IPv6 patch works fine on NetBSD + KAME forgot to attach the following into the diff - so i attach it (README.v6) here as comment. I have submitted the patch for 1.5.1, 1.5.2 and 1.6b1, all hit a bad timing - bad luck. contact: core@kame.net, or itojun@kame.net --- IPv6-ready python 1.6 KAME Project $KAME: README.v6,v 1.9 2000/08/15 02:40:38 itojun Exp $ This patchkit enables python 1.6 to perform AF_INET6 socket operations. The only affected module is Modules/socketmodule.c. Modules/socketmodule.c In most cases, IPv6 address can be placed where IPv4 address fits. sockaddr sockaddr tuple is formatted as follows: IPv4: (host, port) IPv6: socket class methods always generate (host, port, flowinfo, scopeid). socket class methods will accept 2, 3, or 4 tuple (for backward compatibility). Compatibility warning: Some of the scripts assume that the sockaddr structure is 2 tuple, like: host, port = sock.getpeername() this will fail if you are connected to IPv6 node. socket.getaddrinfo(host, port [, family, socktype, proto, flags]) host: String or None port: String, Int or None family, socktype, proto, flags: Int, can be omitted Perform getaddrinfo(3). Returns List of the following 5 tuple: (family, socktype, proto, canonname, sockaddr) family: Int socktype: Int proto: Int canonname: String sockaddr: sockaddr (see above) See Lib/httplib.py for typical usage on the client side. socket.getnameinfo(sockaddr, flags) sockaddr: sockaddr flags: Int Perform getnameinfo(3). Returns the following 2 tuple: host: String, numeric or hostname depending on flgags port: String, numeric or portname depending on flgags socket.gethostbyname2(host, af) host: String af: Int Performs gethostbyname2(3). Returns numeric address representation for "host". socket.gethostbyaddr(addr) (behavior change if IPv6 support is compiled in) addr: String Performs gethostbyaddr(3). Returns string address representation for "addr". The function can take IPv6 numeric address as well. This behavior is not problematical, because - if you pass numeric "addr" parameter, we can always identify address family for it - return value is string address reprsentation, where IPv6 and IPv4 are not distinguishable. socket.bind(sa), socket.connect(sa) and others. (No behavior change, but be careful) See above for sockaddr format change. With Python "addr" portion of sockaddr (first element) can be string hostname. When the string hostname resolved to numeric address, it will obey address family of the socket (which was specified when socket.socket() was called). If you give some string that does not give matching address family, you will get some error. s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) # this is okay, if 'localhost' resolves to both IPv4/v6 s.connect('localhost', 80) # this is not okay, of course s.connect('::1', 80) # this is not okay, as v6only.kame.net will not resolve to IPv4 s.connect('v6only.kame.net', 80) Lib/httplib.py IPv6 ready. "host" in HTTP(host) will accept the following 3 forms: [host]:port host:port there must be only single colon host This is to allow IPv6 numeric URL (http://[host]:port/) in documents. IMHO "host:port" parsing should be implemented in urllib.py, not here. Lib/ftplib.py IPv6 ready. This uses EPSV/EPRT on IPv6 ftp. See RFC2428 for protocol details. Lib/SocketServer.py IPv6 ready. Wildcard bind on TCPServer, i.e. TCPServer(('', port)), will bind to wildcard socket on TCPServer.address_family. TCPServer.addresss_family is set to AF_INET by default, so ('', port) will usually bind AF_INET. Lib/smtplib.py, Lib/telnetlib.py, Lib/poplib.py IPv6 ready. Not much to say about protocol details - they just use TCP over IPv6. configure Configure has extra option, --enable-ipv6 and --disable-ipv6. The option controls IPv6 support feature. dynamic link issues in Modules/socketmodule.c Modules/socketmodule.c can be dynamically loaded only in the following situations: - getaddrinfo(3) and getnameinfo(3) are supplied by OS vendor in libc, and libc is dynamic link library. - OS vendor is NOT supplying getaddrinfo(3) nor getnameinfo(3), and You are configuring this package with --disable-ipv6. In this case, you'll be using missing/get{addr,name}info.c and they will refer to gethostby{name,addr}. gethostnameby{name,addr} can usually be found in dynamic-linking libc. In other situations, such as the following, please link Modules/socketmodule.c into python itself. - getaddrinfo(3) and getnameinfo(3) are supplied by OS vendor, but they are in statically linked library like libinet6.a. (KAME falls into this category) python usually links Modules/socketmodule.c into python itself (due to its popularity) so there should be no problem. restrictions - The patched tree will not use gethostbyname_r and other thread-ready libraries. Instead, it will use getaddrinfo() and getnameinfo() throughout the operation. todo - Patch bunch of library files in Lib/*.py. compatibility issues with existing scripts If you disable IPv6 support (./configure --disable-ipv6), the patched code is mostly compatible with original Python (except files in "Lib" directory modified for dual stack support). User script may choke if: - IPv4/v6 dualstack libc is supplied, python is compiled for dual stack, and script assumes some of IPv4-only behavior (especially sockaddr) - IPv4/v6 dualstack libc is supplied, python is compiled for IPv4 only, and script assumes some of IPv4-only behavior. In this case, Python socket class itself does not support IPv6, however, name resolution functions can return IPv6 names since they use IPv6-ready libc functions! I do not recommend this configuration. - script assumes certain IPv4-only version behavior in Lib/*.py. compilation If you use IPv6 features, it is assumed that you have working getaddrinfo() and getnameinfo() library functions. We have noticed that some of IPv6 stack is shipped with broken getaddrinfo(). In such cases, use missing/get{addr,name}info.c instead (but then, you need to have working getipnodeby{name,addr}). If you compile this on IPv4-only machine without get{addr,name}info, missing/get{addr,name}info.c will be used. They are from KAME IPv6 distribution and is #ifdef'ed for IPv4 only support. They are fairly complete implementation and you don't need to bother with bind 8.2 (bind 8.2 get{addr,name}info() has bugs). When compiling this kit on IPv6 node, you may need to specify some additional library paths or cpp defs. (like -linet6 or -DINET6) --enable-ipv6 will give you some warning, if the IPv6 stack is unknown to the "configure" script. Currently, the following IPv6 stacks are officially supported (i.e. we've checked that the package works well): - KAME IPv6 stack, http://www.kame.net/ References RFC2553, for getaddrinfo(3) and getnameinfo(3). Author contacts http://www.kame.net/ mailto:core@kame.net ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401196&group_id=5470 From nobody@sourceforge.net Mon Feb 26 13:10:43 2001 From: nobody@sourceforge.net (nobody) Date: Mon, 26 Feb 2001 05:10:43 -0800 Subject: [Patches] [ python-Patches-404275 ] get_platform(), patch for AIX Message-ID: Artifact #404275, was updated on 2001-02-26 05:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404275&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Rene Liebscher Assigned to: Nobody/Anonymous Summary: get_platform(), patch for AIX Initial Comment: The platform string which is build by get_platform() for AIX doesnt make much sense. Therefore I provide here a patch which brings up a better string. (eg. for AIX 4.3 -> aix-4.3 not aix-3-XXXXXXXXXXXX , uname/machine seems to be a hardware/network id ? ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404275&group_id=5470 From nobody@sourceforge.net Mon Feb 26 13:10:26 2001 From: nobody@sourceforge.net (nobody) Date: Mon, 26 Feb 2001 05:10:26 -0800 Subject: [Patches] [ python-Patches-404276 ] get_platform(), patch for AIX Message-ID: Artifact #404276, was updated on 2001-02-26 05:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404276&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Rene Liebscher Assigned to: Nobody/Anonymous Summary: get_platform(), patch for AIX Initial Comment: The platform string which is build by get_platform() for AIX doesnt make much sense. Therefore I provide here a patch which brings up a better string. (eg. for AIX 4.3 -> aix-4.3 not aix-3-XXXXXXXXXXXX , uname/machine seems to be a hardware/network id ? ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404276&group_id=5470 From nobody@sourceforge.net Mon Feb 26 13:11:16 2001 From: nobody@sourceforge.net (nobody) Date: Mon, 26 Feb 2001 05:11:16 -0800 Subject: [Patches] [ python-Patches-404276 ] get_platform(), patch for AIX Message-ID: Artifact #404276, was updated on 2001-02-26 05:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404276&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Rene Liebscher Assigned to: Nobody/Anonymous Summary: get_platform(), patch for AIX Initial Comment: The platform string which is build by get_platform() for AIX doesnt make much sense. Therefore I provide here a patch which brings up a better string. (eg. for AIX 4.3 -> aix-4.3 not aix-3-XXXXXXXXXXXX , uname/machine seems to be a hardware/network id ? ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404276&group_id=5470 From nobody@sourceforge.net Mon Feb 26 13:12:35 2001 From: nobody@sourceforge.net (nobody) Date: Mon, 26 Feb 2001 05:12:35 -0800 Subject: [Patches] [ python-Patches-404276 ] get_platform(), patch for AIX Message-ID: Artifact #404276, was updated on 2001-02-26 05:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404276&group_id=5470 Category: distutils Group: None Status: Deleted Priority: 5 Submitted By: Rene Liebscher Assigned to: Nobody/Anonymous Summary: get_platform(), patch for AIX Initial Comment: The platform string which is build by get_platform() for AIX doesnt make much sense. Therefore I provide here a patch which brings up a better string. (eg. for AIX 4.3 -> aix-4.3 not aix-3-XXXXXXXXXXXX , uname/machine seems to be a hardware/network id ? ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404276&group_id=5470 From nobody@sourceforge.net Mon Feb 26 13:12:42 2001 From: nobody@sourceforge.net (nobody) Date: Mon, 26 Feb 2001 05:12:42 -0800 Subject: [Patches] [ python-Patches-404275 ] get_platform(), patch for AIX Message-ID: Artifact #404275, was updated on 2001-02-26 05:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404275&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Rene Liebscher Assigned to: Nobody/Anonymous Summary: get_platform(), patch for AIX Initial Comment: The platform string which is build by get_platform() for AIX doesnt make much sense. Therefore I provide here a patch which brings up a better string. (eg. for AIX 4.3 -> aix-4.3 not aix-3-XXXXXXXXXXXX , uname/machine seems to be a hardware/network id ? ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404275&group_id=5470 From nobody@sourceforge.net Mon Feb 26 13:22:10 2001 From: nobody@sourceforge.net (nobody) Date: Mon, 26 Feb 2001 05:22:10 -0800 Subject: [Patches] [ python-Patches-404275 ] get_platform(), patch for AIX Message-ID: Artifact #404275, was updated on 2001-02-26 05:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404275&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Rene Liebscher Assigned to: Nobody/Anonymous Summary: get_platform(), patch for AIX Initial Comment: The platform string which is build by get_platform() for AIX doesnt make much sense. Therefore I provide here a patch which brings up a better string. (eg. for AIX 4.3 -> aix-4.3 not aix-3-XXXXXXXXXXXX , uname/machine seems to be a hardware/network id ? ) ---------------------------------------------------------------------- Comment By: Rene Liebscher Date: 2001-02-26 05:22 Message: Logged In: YES user_id=28463 Index: distutils/util.py =================================================================== RCS file: /cvsroot/python/distutils/distutils/util.py,v retrieving revision 1.59 diff -c -r1.59 util.py *** distutils/util.py 2001/01/28 12:23:32 1.59 --- distutils/util.py 2001/02/26 13:04:11 *************** *** 54,59 **** --- 54,61 ---- # fall through to standard osname-release-machine representation elif osname[:4] == "irix": # could be "irix64"! return "%s-%s" % (osname, release) + elif osname[:3] == "aix": + return "%s-%s.%s" % (osname, version, release) elif osname[:6] == "cygwin": rel_re = re.compile (r'[\d.]+') m = rel_re.match(release) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404275&group_id=5470 From nobody@sourceforge.net Mon Feb 26 13:36:31 2001 From: nobody@sourceforge.net (nobody) Date: Mon, 26 Feb 2001 05:36:31 -0800 Subject: [Patches] [ python-Patches-404282 ] Manifest.in not included in sdist... Message-ID: Artifact #404282, was updated on 2001-02-26 05:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404282&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Rene Liebscher Assigned to: Nobody/Anonymous Summary: Manifest.in not included in sdist... Initial Comment: The sdist command includes some files in MANIFEST without you to have specify them (setup.py, README) (The use_defaults option is on by default.) If you create MANIFEST from MANIFEST.IN then it should also include MANIFEST.IN. (see also http://mail.python.org/pipermail/distutils-sig/2000-October/001685.html ) This patch adds the template file if it is used and use_defaults is on. ------------------------------------------------------- Index: distutils/command/sdist.py =================================================================== RCS file: /cvsroot/python/distutils/distutils/command/sdist.py,v retrieving revision 1.51 diff -c -r1.51 sdist.py *** distutils/command/sdist.py 2000/10/14 04:06:40 1.51 --- distutils/command/sdist.py 2001/02/26 13:27:48 *************** *** 244,249 **** --- 244,251 ---- # Read manifest template if it exists if template_exists: self.read_template() + if self.use_defaults: # don't forget MANIFEST.in + self.filelist.append(self.template) # Prune away any directories that don't belong in the source # distribution ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404282&group_id=5470 From nobody@sourceforge.net Mon Feb 26 13:38:48 2001 From: nobody@sourceforge.net (nobody) Date: Mon, 26 Feb 2001 05:38:48 -0800 Subject: [Patches] [ python-Patches-404282 ] Manifest.in not included in sdist... Message-ID: Artifact #404282, was updated on 2001-02-26 05:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404282&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Rene Liebscher Assigned to: Nobody/Anonymous Summary: Manifest.in not included in sdist... Initial Comment: The sdist command includes some files in MANIFEST without you to have specify them (setup.py, README) (The use_defaults option is on by default.) If you create MANIFEST from MANIFEST.IN then it should also include MANIFEST.IN. (see also http://mail.python.org/pipermail/distutils-sig/2000-October/001685.html ) This patch adds the template file if it is used and use_defaults is on. ------------------------------------------------------- Index: distutils/command/sdist.py =================================================================== RCS file: /cvsroot/python/distutils/distutils/command/sdist.py,v retrieving revision 1.51 diff -c -r1.51 sdist.py *** distutils/command/sdist.py 2000/10/14 04:06:40 1.51 --- distutils/command/sdist.py 2001/02/26 13:27:48 *************** *** 244,249 **** --- 244,251 ---- # Read manifest template if it exists if template_exists: self.read_template() + if self.use_defaults: # don't forget MANIFEST.in + self.filelist.append(self.template) # Prune away any directories that don't belong in the source # distribution ---------------------------------------------------------------------- Comment By: Rene Liebscher Date: 2001-02-26 05:38 Message: Logged In: YES user_id=28463 Where are the blanks? (see http://mail.python.org/pipermail/distutils-sig/2000-October/001693.html for a correct indentation) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404282&group_id=5470 From nobody@sourceforge.net Mon Feb 26 16:53:04 2001 From: nobody@sourceforge.net (nobody) Date: Mon, 26 Feb 2001 08:53:04 -0800 Subject: [Patches] [ python-Patches-401104 ] Optional object mem allocator Message-ID: Artifact #401104, was updated on 2000-08-06 20:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401104&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Vladimir Marangozov Assigned to: Neil Schemenauer Summary: Optional object mem allocator Initial Comment: ---------------------------------------------------------------------- Comment By: Barry Warsaw Date: 2001-02-26 08:53 Message: Logged In: YES user_id=12800 Giving Neil the green light. ---------------------------------------------------------------------- Comment By: Vladimir Marangozov Date: 2000-08-18 21:11 Message: Update: (1) fixing a missing case for realloc(p,0) == free(p) + ret NULL (2) simplify the hooks interface: set_hooks/fetch_hooks are better than install/uninstall. ---------------------------------------------------------------------- Comment By: Vladimir Marangozov Date: 2000-08-12 13:31 Message: Status set to Postponed. Although promising, this hasn't enjoyed much user testing for the 2.0 time frame (partly because of the lack of an introspective Python interface which can't be completed in time according to the release schedule). Assigned to marangoz who's responsible to reopen it again in due time (except if BDFL decides otherwise). ---------------------------------------------------------------------- Comment By: Vladimir Marangozov Date: 2000-08-07 09:19 Message: Thanks. Fixed (acconfig.h) ---------------------------------------------------------------------- Comment By: Thomas Wouters Date: 2000-08-07 06:30 Message: Small nit: you shouldn't edit config.h.in yourself, it's autogenerated from acconfig.h and configure.in (with 'autoheader', part of 'autoconf.) You should define WITH_PYMALLOC in acconfig.h, not config.h.in, and run 'autoheader' and 'autoconf' to generate a new 'configure'. I'm in the process of testing this patch on Linux and BSDI, by the way :) ---------------------------------------------------------------------- Comment By: Vladimir Marangozov Date: 2000-08-06 21:05 Message: A stab on obmalloc.c -- an optional object allocator. A configure "--with(out)-pymalloc" option is introduced for enabling specialized mallocs. Off by default. The code is included conditionally at the end of object.c obmalloc.c contains only the core malloc functionality. No profiling, nor debugging are there -- these would come as separate (and optional) modules: memprof.c & memdebug.c in the Modules/ directory and will exploit the hooks of the allocator. I've managed to draw a rather nice diagram in the comments at the top of obmalloc.c explaining what this stuff is all about. Look there. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401104&group_id=5470 From nobody@sourceforge.net Mon Feb 26 16:56:48 2001 From: nobody@sourceforge.net (nobody) Date: Mon, 26 Feb 2001 08:56:48 -0800 Subject: [Patches] [ python-Patches-403495 ] case sensitive import for case insensitive FileSystem Message-ID: Artifact #403495, was updated on 2001-01-29 15:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403495&group_id=5470 Category: core (C code) Group: None Status: Closed Priority: 5 Submitted By: Steven D. Majewski Assigned to: Barry Warsaw Summary: case sensitive import for case insensitive FileSystem Initial Comment: Here's a patch that fixes the case insensitive import problem on MacOSX. It's not a mac-specific patch -- just requires HAVE_DIRENT_H, but I'm not sure if anyone not on MacOSX would want it. ( Even if you're using a mac HFS filesystem from LinuxPPC, I don't think you're going to install Python on it! ) or maybe there should be a config flag or including it? I'm not sure what preprocessor symbols could be used to determine macosx. __APPLE__ is predefined, but I don't know if this is also defined for non-bsd "classic" macos. ( I guess __APPLE__ & HAVE_DIRENT_H should work. ) -- Steve Majewski ---------------------------------------------------------------------- Comment By: Barry Warsaw Date: 2001-02-26 08:56 Message: Logged In: YES user_id=12800 Closing, since this patch was applied. At least I'm pretty sure it was -- hard to tell since SF seems to have regenerated all new patch numbers. :( ---------------------------------------------------------------------- Comment By: Tim Peters Date: 2001-02-16 21:41 Message: Reassigning to Barry since he marked it Accepted, and changing it to Open because I *think* it's already been applied. Barry, if you did apply it, mark it as Closed. ---------------------------------------------------------------------- Comment By: Barry Warsaw Date: 2001-02-02 11:09 Message: Whoops! Marking as accepted. ---------------------------------------------------------------------- Comment By: Barry Warsaw Date: 2001-02-02 11:08 Message: Here's a version of the patch that applies cleanly to the 2.1a2 source, conforms to C coding styles, and builds on Linux RH 6.1. It passes regrtest and "import getpass" (termios/TERMIOS). I cannot test it on any other platform. I'm marking this as accepted and commiting it to the 2.1a2 tree. Once other platforms have verified that it works for them, we can close the patch. ---------------------------------------------------------------------- Comment By: Jason Tishler Date: 2001-02-01 06:47 Message: Scratch the comment about the bug -- I've too much C++ on the head to think in straight C anymore. ---------------------------------------------------------------------- Comment By: Jason Tishler Date: 2001-01-31 18:20 Message: Guido, Do you find the style of this patch more acceptable than mine (103154)? If so, would you consider including a cleaned up version into 2.1a2? Note that I have found one bug (MatchFilename() does not handle a NULL pathname correctly) and the code should probably be enabled on something more specific than HAVE_DIRENT_H (e.g., platform #defs, UNIX_STYLE_CHECK_IMPORT_CASE, etc). ---------------------------------------------------------------------- Comment By: Steven D. Majewski Date: 2001-01-29 20:30 Message: Oops! The previous patch crashes if the path is empty, which is the case for the current directory. Added a line to check for that and use "." instead on diropen. -- Steve M. ---------------------------------------------------------------------- Comment By: Steven D. Majewski Date: 2001-01-29 20:27 Message: Oops! The previous patch crashes if the path is empty, which is the case for the current directory. Added a line to check for that and use "." instead on diropen. -- Steve M. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403495&group_id=5470 From nobody@sourceforge.net Mon Feb 26 19:12:26 2001 From: nobody@sourceforge.net (nobody) Date: Mon, 26 Feb 2001 11:12:26 -0800 Subject: [Patches] [ python-Patches-403985 ] Add support for weak-keyed dictionaries Message-ID: Artifact #403985, was updated on 2001-02-23 23:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403985&group_id=5470 Category: Modules Group: None Status: Open Priority: 7 Submitted By: Martin v. Löwis Assigned to: Fred L. Drake, Jr. Summary: Add support for weak-keyed dictionaries Initial Comment: This patch adds a parameter weakkeys to weakref.mapping. To allow weak references as dictionary keys, they cache their hash value and support equality. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-02-26 11:12 Message: Logged In: YES user_id=3066 I'll take a look at this (and some other patches) later today. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403985&group_id=5470 From nobody@sourceforge.net Mon Feb 26 19:19:14 2001 From: nobody@sourceforge.net (nobody) Date: Mon, 26 Feb 2001 11:19:14 -0800 Subject: [Patches] [ python-Patches-403892 ] a small optimization for threading.py Message-ID: Artifact #403892, was updated on 2001-02-19 22:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403892&group_id=5470 Category: library Group: None Status: Closed Priority: 5 Submitted By: Nobody/Anonymous Assigned to: Tim Peters Summary: a small optimization for threading.py Initial Comment: This gets rid of some unnecessary calls in the condition variable code of threading.py. More significantly, it optimizes (what I believe) notify's common case--n == 1. It's about a 10-15% speedup on the small test program at the end. If you've questions, post them here. ---------------------------------------------------------------------- Comment By: Tim Peters Date: 2001-02-26 11:19 Message: Logged In: YES user_id=31435 Rejected, for reasons explained in the followup 6 days ago. ---------------------------------------------------------------------- Comment By: Tim Peters Date: 2001-02-20 17:22 Message: n==1 may or may not be the most common case, but the new code is subject to races so can't be accepted anyway; e.g., thread T1 does a timed .wait(), thread T2 does .notify() and loses its timeslice right before the new self.__waiters[0].release(), T1 gets back just in time for its timed wait to expire, and executes its self.__waiters.remove(waiter), T2 then blows up with an IndexError trying to index into a list that's now empty. There's a reason .remove() is used everywhere: self.__waiters is subject to almost arbitrary mutation while .notify() is executing, so you can't safely assume anything about its state is invariant from one line to the next. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403892&group_id=5470 From nobody@sourceforge.net Tue Feb 27 03:26:38 2001 From: nobody@sourceforge.net (nobody) Date: Mon, 26 Feb 2001 19:26:38 -0800 Subject: [Patches] [ python-Patches-403930 ] Ignore error making grammar src if srcdir is readonly Message-ID: Artifact #403930, was updated on 2001-02-21 05:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403930&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Neil Schemenauer Assigned to: Thomas Wouters Summary: Ignore error making grammar src if srcdir is readonly Initial Comment: ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-26 19:26 Message: Logged In: YES user_id=35752 Applied. The old behavor was much too broken to leave for the beta. ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-23 22:38 Message: "If make doesn't do what you expect it to, it's a good chance the makefile is wrong." -- BSD Make manual Some dependances were missing. Can you give the current patch a whirl? BTW, why to you think rebuilding the grammar source is a bad idea? ---------------------------------------------------------------------- Comment By: Thomas Wouters Date: 2001-02-22 08:20 Message: This doesn't look like it does what it is supposed to. At least, after applying the patch, Grammar doesn't get rebuilt at all, even when graminit.h is missing: gcc -D_HAVE_BSDI -c -g -O2 -Wall -Wstrict-prototypes -I. -I../Include -DHAVE_CONFIG_H -o Python/compile.o ../Python/compile.c ../Python/compile.c:17: graminit.h: No such file or directory I can't seem to get it to make it, even though there is a $(GRAMINIT_H) dependancy. 'make Include/graminit.h' no longer works, and neither does anything else I can come up with. But I'd like to note I'm still against rebuilding the Grammar automatically in releases :-) I'm not really sure if it's still worth rebuilding the Grammar each time, myself. It was when I did the original (horribly broken) patch, but that was in the heat of 2.0, with lots of Grammar-changing patch-proposals about. ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-21 05:43 Message: Does this make sense? My last change making graminit.h and graminit.c in the build directory was wrong. The compiler does not understand VPATH so the include file could not be found. The new idea is to continue the build even if the grammar sources cannot be regenerated (maybe the source directory is readonly). I don't want to remove the target completely since someone may change the grammar and forget to generate the source. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403930&group_id=5470 From nobody@sourceforge.net Tue Feb 27 04:57:19 2001 From: nobody@sourceforge.net (nobody) Date: Mon, 26 Feb 2001 20:57:19 -0800 Subject: [Patches] [ python-Patches-401104 ] Optional object mem allocator Message-ID: Artifact #401104, was updated on 2000-08-06 20:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401104&group_id=5470 Category: core (C code) Group: None Status: Closed Priority: 5 Submitted By: Vladimir Marangozov Assigned to: Neil Schemenauer Summary: Optional object mem allocator Initial Comment: ---------------------------------------------------------------------- Comment By: Barry Warsaw Date: 2001-02-26 08:53 Message: Logged In: YES user_id=12800 Giving Neil the green light. ---------------------------------------------------------------------- Comment By: Vladimir Marangozov Date: 2000-08-18 21:11 Message: Update: (1) fixing a missing case for realloc(p,0) == free(p) + ret NULL (2) simplify the hooks interface: set_hooks/fetch_hooks are better than install/uninstall. ---------------------------------------------------------------------- Comment By: Vladimir Marangozov Date: 2000-08-12 13:31 Message: Status set to Postponed. Although promising, this hasn't enjoyed much user testing for the 2.0 time frame (partly because of the lack of an introspective Python interface which can't be completed in time according to the release schedule). Assigned to marangoz who's responsible to reopen it again in due time (except if BDFL decides otherwise). ---------------------------------------------------------------------- Comment By: Vladimir Marangozov Date: 2000-08-07 09:19 Message: Thanks. Fixed (acconfig.h) ---------------------------------------------------------------------- Comment By: Thomas Wouters Date: 2000-08-07 06:30 Message: Small nit: you shouldn't edit config.h.in yourself, it's autogenerated from acconfig.h and configure.in (with 'autoheader', part of 'autoconf.) You should define WITH_PYMALLOC in acconfig.h, not config.h.in, and run 'autoheader' and 'autoconf' to generate a new 'configure'. I'm in the process of testing this patch on Linux and BSDI, by the way :) ---------------------------------------------------------------------- Comment By: Vladimir Marangozov Date: 2000-08-06 21:05 Message: A stab on obmalloc.c -- an optional object allocator. A configure "--with(out)-pymalloc" option is introduced for enabling specialized mallocs. Off by default. The code is included conditionally at the end of object.c obmalloc.c contains only the core malloc functionality. No profiling, nor debugging are there -- these would come as separate (and optional) modules: memprof.c & memdebug.c in the Modules/ directory and will exploit the hooks of the allocator. I've managed to draw a rather nice diagram in the comments at the top of obmalloc.c explaining what this stuff is all about. Look there. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401104&group_id=5470 From nobody@sourceforge.net Tue Feb 27 13:11:50 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 05:11:50 -0800 Subject: [Patches] [ python-Patches-404564 ] tempfile.py: Change order of tmp dirs Message-ID: Artifact #404564, was updated on 2001-02-27 05:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404564&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Gregor Hoffleit Assigned to: Nobody/Anonymous Summary: tempfile.py: Change order of tmp dirs Initial Comment: [cf. Debian bug#87538, http://bugs.debian.org/87538] Please change the order of the dirs in the attemptdirs list in Lib/tempfile.py. It seems more reasonable according to the FHS (File System Hierarchy Standard), if '/tmp' would precede '/var/tmp': attempdirs = ['/tmp', '/var/tmp', '/usr/tmp', pwd] '/var/tmp' was added recently to the list (Aug 2000, 'Patch by tg@FreeBSD.org to try /var/tmp first. This helps on 4.4BSD-based systems.'). I guess it would make no difference if '/var/tmp' would only tried after '/tmp'. In the words of James Troup : "Well... o /var/tmp/ (at least on Debian) is not cleaned on start-up like /tmp is o /var/tmp/ is often/sometimes on a different drive and could potentially have a lot less free space than /tmp o it's not documented o it's unexpected I think a better question might be: what's the advantage of the change? *shrug*" ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404564&group_id=5470 From nobody@sourceforge.net Tue Feb 27 15:46:58 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 07:46:58 -0800 Subject: [Patches] [ python-Patches-404564 ] tempfile.py: Change order of tmp dirs Message-ID: Artifact #404564, was updated on 2001-02-27 05:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404564&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Gregor Hoffleit Assigned to: Nobody/Anonymous Summary: tempfile.py: Change order of tmp dirs Initial Comment: [cf. Debian bug#87538, http://bugs.debian.org/87538] Please change the order of the dirs in the attemptdirs list in Lib/tempfile.py. It seems more reasonable according to the FHS (File System Hierarchy Standard), if '/tmp' would precede '/var/tmp': attempdirs = ['/tmp', '/var/tmp', '/usr/tmp', pwd] '/var/tmp' was added recently to the list (Aug 2000, 'Patch by tg@FreeBSD.org to try /var/tmp first. This helps on 4.4BSD-based systems.'). I guess it would make no difference if '/var/tmp' would only tried after '/tmp'. In the words of James Troup : "Well... o /var/tmp/ (at least on Debian) is not cleaned on start-up like /tmp is o /var/tmp/ is often/sometimes on a different drive and could potentially have a lot less free space than /tmp o it's not documented o it's unexpected I think a better question might be: what's the advantage of the change? *shrug*" ---------------------------------------------------------------------- Comment By: Skip Montanaro Date: 2001-02-27 07:46 Message: Logged In: YES user_id=44345 Regarding this statement: /var/tmp/ is often/sometimes on a different drive and could potentially have a lot less free space than /tmp It is a red herring. /var is often given it's own separate partition precisely because the / partition is often very small. I think /var/tmp should appear before /tmp. If you want it cleaned up on reboot, simply modify your startup scripts or (better yet) add a daily or weekly cron job to zap old files in /var/tmp. After all, who cares about cleanup at reboot on systems that can remain up for more than a year? What do you think this is - Windows? ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404564&group_id=5470 From nobody@sourceforge.net Tue Feb 27 16:03:33 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 08:03:33 -0800 Subject: [Patches] [ python-Patches-404564 ] tempfile.py: Change order of tmp dirs Message-ID: Artifact #404564, was updated on 2001-02-27 05:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404564&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Gregor Hoffleit Assigned to: Nobody/Anonymous Summary: tempfile.py: Change order of tmp dirs Initial Comment: [cf. Debian bug#87538, http://bugs.debian.org/87538] Please change the order of the dirs in the attemptdirs list in Lib/tempfile.py. It seems more reasonable according to the FHS (File System Hierarchy Standard), if '/tmp' would precede '/var/tmp': attempdirs = ['/tmp', '/var/tmp', '/usr/tmp', pwd] '/var/tmp' was added recently to the list (Aug 2000, 'Patch by tg@FreeBSD.org to try /var/tmp first. This helps on 4.4BSD-based systems.'). I guess it would make no difference if '/var/tmp' would only tried after '/tmp'. In the words of James Troup : "Well... o /var/tmp/ (at least on Debian) is not cleaned on start-up like /tmp is o /var/tmp/ is often/sometimes on a different drive and could potentially have a lot less free space than /tmp o it's not documented o it's unexpected I think a better question might be: what's the advantage of the change? *shrug*" ---------------------------------------------------------------------- Comment By: Gregor Hoffleit Date: 2001-02-27 08:03 Message: Logged In: YES user_id=5293 Regarding your statement: "If you want it cleaned up on reboot, simply modify your startup scripts or (better yet) add a daily or weekly cron job to zap old files in /var/tmp." The Linux Standard Base (more specifically: the File System Hierarchy) says this about /var/tmp: 5.12 /var/tmp : Temporary files preserved between system reboots The /var/tmp directory is made available for programs that require temporary files or directories that are preserved between system reboots. Therefore, data stored in /var/tmp is more persistent than data in /tmp. Files and directories located in /var/tmp must not be deleted when the system is booted. Although data stored in /var/tmp is typically deleted in a site-specific manner, it is recommended that deletions occur at a less frequent interval than /tmp. Therefore, if you setup your system to remove files in /var/tmp on reboot, your system will not be compliant with the Linux standard. Moreover, the description for /tmp seems more appropriate for tempfile IMHO: 3.11 /tmp : Temporary files The /tmp directory shall be made available for programs that require temporary files. Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted. Programs shall not assume that any files or directories in /tmp are preserved between invocations of the program. ---------------------------------------------------------------------- Comment By: Skip Montanaro Date: 2001-02-27 07:46 Message: Logged In: YES user_id=44345 Regarding this statement: /var/tmp/ is often/sometimes on a different drive and could potentially have a lot less free space than /tmp It is a red herring. /var is often given it's own separate partition precisely because the / partition is often very small. I think /var/tmp should appear before /tmp. If you want it cleaned up on reboot, simply modify your startup scripts or (better yet) add a daily or weekly cron job to zap old files in /var/tmp. After all, who cares about cleanup at reboot on systems that can remain up for more than a year? What do you think this is - Windows? ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404564&group_id=5470 From nobody@sourceforge.net Tue Feb 27 17:13:51 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 09:13:51 -0800 Subject: [Patches] [ python-Patches-403947 ] For Cygwin built Python use Cygwin like an UNIX C compiler Message-ID: Artifact #403947, was updated on 2001-02-22 07:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403947&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Rene Liebscher Assigned to: Nobody/Anonymous Summary: For Cygwin built Python use Cygwin like an UNIX C compiler Initial Comment: The patch from 1.37->1.38 went too far, as it assigns the cygwinccompiler class as default for Pythons built with cygwin. You can use cygwin in this case as normal UNIX-like compiler. (cygwinccompiler needs some work to handle the differences in Cygwin- and MSVC-Python. Makefile and config files are currently ignored by cygwinccompiler, as it was written to support cygwin for extensions which are intended to be used with the standard MSVC built Python.) ---------------------------------------------------------------------- Comment By: Jason Tishler Date: 2001-02-27 09:13 Message: Logged In: YES user_id=86216 Will this patch be committed in time for Beta 1 scheduled for Thursday, 3/1/01? Without it Cygwin Python no longer builds OOTB. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403947&group_id=5470 From nobody@sourceforge.net Tue Feb 27 17:16:52 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 09:16:52 -0800 Subject: [Patches] [ python-Patches-404564 ] tempfile.py: Change order of tmp dirs Message-ID: Artifact #404564, was updated on 2001-02-27 05:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404564&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Gregor Hoffleit Assigned to: Nobody/Anonymous Summary: tempfile.py: Change order of tmp dirs Initial Comment: [cf. Debian bug#87538, http://bugs.debian.org/87538] Please change the order of the dirs in the attemptdirs list in Lib/tempfile.py. It seems more reasonable according to the FHS (File System Hierarchy Standard), if '/tmp' would precede '/var/tmp': attempdirs = ['/tmp', '/var/tmp', '/usr/tmp', pwd] '/var/tmp' was added recently to the list (Aug 2000, 'Patch by tg@FreeBSD.org to try /var/tmp first. This helps on 4.4BSD-based systems.'). I guess it would make no difference if '/var/tmp' would only tried after '/tmp'. In the words of James Troup : "Well... o /var/tmp/ (at least on Debian) is not cleaned on start-up like /tmp is o /var/tmp/ is often/sometimes on a different drive and could potentially have a lot less free space than /tmp o it's not documented o it's unexpected I think a better question might be: what's the advantage of the change? *shrug*" ---------------------------------------------------------------------- Comment By: Skip Montanaro Date: 2001-02-27 09:16 Message: Logged In: YES user_id=44345 Then the standard is wrong. ;-) I will rephrase: Any system that relies on boot-time cleanup to keep a disk partition from filling up is broken. /tmp is generally on the root partition, the partition that is most dangerous to allow to fill. ---------------------------------------------------------------------- Comment By: Gregor Hoffleit Date: 2001-02-27 08:03 Message: Logged In: YES user_id=5293 Regarding your statement: "If you want it cleaned up on reboot, simply modify your startup scripts or (better yet) add a daily or weekly cron job to zap old files in /var/tmp." The Linux Standard Base (more specifically: the File System Hierarchy) says this about /var/tmp: 5.12 /var/tmp : Temporary files preserved between system reboots The /var/tmp directory is made available for programs that require temporary files or directories that are preserved between system reboots. Therefore, data stored in /var/tmp is more persistent than data in /tmp. Files and directories located in /var/tmp must not be deleted when the system is booted. Although data stored in /var/tmp is typically deleted in a site-specific manner, it is recommended that deletions occur at a less frequent interval than /tmp. Therefore, if you setup your system to remove files in /var/tmp on reboot, your system will not be compliant with the Linux standard. Moreover, the description for /tmp seems more appropriate for tempfile IMHO: 3.11 /tmp : Temporary files The /tmp directory shall be made available for programs that require temporary files. Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted. Programs shall not assume that any files or directories in /tmp are preserved between invocations of the program. ---------------------------------------------------------------------- Comment By: Skip Montanaro Date: 2001-02-27 07:46 Message: Logged In: YES user_id=44345 Regarding this statement: /var/tmp/ is often/sometimes on a different drive and could potentially have a lot less free space than /tmp It is a red herring. /var is often given it's own separate partition precisely because the / partition is often very small. I think /var/tmp should appear before /tmp. If you want it cleaned up on reboot, simply modify your startup scripts or (better yet) add a daily or weekly cron job to zap old files in /var/tmp. After all, who cares about cleanup at reboot on systems that can remain up for more than a year? What do you think this is - Windows? ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404564&group_id=5470 From nobody@sourceforge.net Tue Feb 27 17:17:49 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 09:17:49 -0800 Subject: [Patches] [ python-Patches-403903 ] Change EXEEXT back to EXE in the makefile Message-ID: Artifact #403903, was updated on 2001-02-20 11:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403903&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Neil Schemenauer Assigned to: Fred L. Drake, Jr. Summary: Change EXEEXT back to EXE in the makefile Initial Comment: I think changing EXE to EXEEXT in the Makefile was a bad idea. I changed it because I wanted the Makefile variable to have the same name as the configure variable. I now think that backwards compatibility it more important. EXE is used by both regen and distutils. Its possible that 3rd party tools use it as well. ---------------------------------------------------------------------- Comment By: Jason Tishler Date: 2001-02-27 09:17 Message: Logged In: YES user_id=86216 Will this patch be committed in time for Beta 1 scheduled for Thursday, 3/1/01? Without it Cygwin Python no longer builds (i.e., installs) OOTB. ---------------------------------------------------------------------- Comment By: Jason Tishler Date: 2001-02-21 11:37 Message: Note that Marc has informed me that he will be offline for the next two weeks so may be this should be assigned to someone else... ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-20 11:11 Message: Assigned to Marc mostly at random. Please review or assign to someone else. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403903&group_id=5470 From nobody@sourceforge.net Tue Feb 27 17:28:21 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 09:28:21 -0800 Subject: [Patches] [ python-Patches-403903 ] Change EXEEXT back to EXE in the makefile Message-ID: Artifact #403903, was updated on 2001-02-20 11:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403903&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Neil Schemenauer Assigned to: Fred L. Drake, Jr. Summary: Change EXEEXT back to EXE in the makefile Initial Comment: I think changing EXE to EXEEXT in the Makefile was a bad idea. I changed it because I wanted the Makefile variable to have the same name as the configure variable. I now think that backwards compatibility it more important. EXE is used by both regen and distutils. Its possible that 3rd party tools use it as well. ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-27 09:28 Message: Logged In: YES user_id=35752 Jason, does this patch look okay to you? If it does I will check it in. I've been making a lot of stupid build process checkins lately and want some peer review. ---------------------------------------------------------------------- Comment By: Jason Tishler Date: 2001-02-27 09:17 Message: Logged In: YES user_id=86216 Will this patch be committed in time for Beta 1 scheduled for Thursday, 3/1/01? Without it Cygwin Python no longer builds (i.e., installs) OOTB. ---------------------------------------------------------------------- Comment By: Jason Tishler Date: 2001-02-21 11:37 Message: Note that Marc has informed me that he will be offline for the next two weeks so may be this should be assigned to someone else... ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-20 11:11 Message: Assigned to Marc mostly at random. Please review or assign to someone else. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403903&group_id=5470 From nobody@sourceforge.net Tue Feb 27 17:31:33 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 09:31:33 -0800 Subject: [Patches] [ python-Patches-403947 ] For Cygwin built Python use Cygwin like an UNIX C compiler Message-ID: Artifact #403947, was updated on 2001-02-22 07:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403947&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Rene Liebscher Assigned to: A.M. Kuchling Summary: For Cygwin built Python use Cygwin like an UNIX C compiler Initial Comment: The patch from 1.37->1.38 went too far, as it assigns the cygwinccompiler class as default for Pythons built with cygwin. You can use cygwin in this case as normal UNIX-like compiler. (cygwinccompiler needs some work to handle the differences in Cygwin- and MSVC-Python. Makefile and config files are currently ignored by cygwinccompiler, as it was written to support cygwin for extensions which are intended to be used with the standard MSVC built Python.) ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-02-27 09:31 Message: Logged In: YES user_id=11375 Assigning to myself; I'll look at it after lunch. ---------------------------------------------------------------------- Comment By: Jason Tishler Date: 2001-02-27 09:13 Message: Logged In: YES user_id=86216 Will this patch be committed in time for Beta 1 scheduled for Thursday, 3/1/01? Without it Cygwin Python no longer builds OOTB. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403947&group_id=5470 From nobody@sourceforge.net Tue Feb 27 17:42:31 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 09:42:31 -0800 Subject: [Patches] [ python-Patches-403903 ] Change EXEEXT back to EXE in the makefile Message-ID: Patches #403903, was updated on 2001-02-20 11:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403903&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Neil Schemenauer Assigned to: Fred L. Drake, Jr. Summary: Change EXEEXT back to EXE in the makefile Initial Comment: I think changing EXE to EXEEXT in the Makefile was a bad idea. I changed it because I wanted the Makefile variable to have the same name as the configure variable. I now think that backwards compatibility it more important. EXE is used by both regen and distutils. Its possible that 3rd party tools use it as well. ---------------------------------------------------------------------- Comment By: Jason Tishler Date: 2001-02-27 09:42 Message: Logged In: YES user_id=86216 I just reviewed the patch and it looks good to me. Let me know when you check it in and I will do a cvs update and test it for you. ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-27 09:28 Message: Logged In: YES user_id=35752 Jason, does this patch look okay to you? If it does I will check it in. I've been making a lot of stupid build process checkins lately and want some peer review. ---------------------------------------------------------------------- Comment By: Jason Tishler Date: 2001-02-27 09:17 Message: Logged In: YES user_id=86216 Will this patch be committed in time for Beta 1 scheduled for Thursday, 3/1/01? Without it Cygwin Python no longer builds (i.e., installs) OOTB. ---------------------------------------------------------------------- Comment By: Jason Tishler Date: 2001-02-21 11:37 Message: Note that Marc has informed me that he will be offline for the next two weeks so may be this should be assigned to someone else... ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-20 11:11 Message: Assigned to Marc mostly at random. Please review or assign to someone else. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403903&group_id=5470 From nobody@sourceforge.net Tue Feb 27 17:49:11 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 09:49:11 -0800 Subject: [Patches] [ python-Patches-403903 ] Change EXEEXT back to EXE in the makefile Message-ID: Patches #403903, was updated on 2001-02-20 11:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403903&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Neil Schemenauer Assigned to: Neil Schemenauer Summary: Change EXEEXT back to EXE in the makefile Initial Comment: I think changing EXE to EXEEXT in the Makefile was a bad idea. I changed it because I wanted the Makefile variable to have the same name as the configure variable. I now think that backwards compatibility it more important. EXE is used by both regen and distutils. Its possible that 3rd party tools use it as well. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-02-27 09:49 Message: Logged In: YES user_id=3066 Assigned to Neil since he appearantly has time to handle this. ---------------------------------------------------------------------- Comment By: Jason Tishler Date: 2001-02-27 09:42 Message: Logged In: YES user_id=86216 I just reviewed the patch and it looks good to me. Let me know when you check it in and I will do a cvs update and test it for you. ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-27 09:28 Message: Logged In: YES user_id=35752 Jason, does this patch look okay to you? If it does I will check it in. I've been making a lot of stupid build process checkins lately and want some peer review. ---------------------------------------------------------------------- Comment By: Jason Tishler Date: 2001-02-27 09:17 Message: Logged In: YES user_id=86216 Will this patch be committed in time for Beta 1 scheduled for Thursday, 3/1/01? Without it Cygwin Python no longer builds (i.e., installs) OOTB. ---------------------------------------------------------------------- Comment By: Jason Tishler Date: 2001-02-21 11:37 Message: Note that Marc has informed me that he will be offline for the next two weeks so may be this should be assigned to someone else... ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-20 11:11 Message: Assigned to Marc mostly at random. Please review or assign to someone else. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403903&group_id=5470 From nobody@sourceforge.net Tue Feb 27 18:07:11 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 10:07:11 -0800 Subject: [Patches] [ python-Patches-403985 ] Add support for weak-keyed dictionaries Message-ID: Patches #403985, was updated on 2001-02-23 23:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403985&group_id=5470 Category: Modules Group: None Status: Open Priority: 7 Submitted By: Martin v. Löwis Assigned to: Martin v. Löwis Summary: Add support for weak-keyed dictionaries Initial Comment: This patch adds a parameter weakkeys to weakref.mapping. To allow weak references as dictionary keys, they cache their hash value and support equality. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-02-27 10:07 Message: Logged In: YES user_id=3066 Modified the patch slightly, adding some small documentation revisions and changing the name of WeakDictionary to WeakValueDictionary. Martin, if you're still happy with this after my changes, please feel free to check it in. Thanks! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-02-26 11:12 Message: Logged In: YES user_id=3066 I'll take a look at this (and some other patches) later today. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403985&group_id=5470 From nobody@sourceforge.net Tue Feb 27 18:17:20 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 10:17:20 -0800 Subject: [Patches] [ python-Patches-403985 ] Add support for weak-keyed dictionaries Message-ID: Patches #403985, was updated on 2001-02-23 23:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403985&group_id=5470 Category: Modules Group: None Status: Open Priority: 7 Submitted By: Martin v. Löwis Assigned to: Martin v. Löwis Summary: Add support for weak-keyed dictionaries Initial Comment: This patch adds a parameter weakkeys to weakref.mapping. To allow weak references as dictionary keys, they cache their hash value and support equality. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-02-27 10:17 Message: Logged In: YES user_id=3066 (Sigh...) Updating the patch here doesn't seem to be working. I've placed the revised patch here: http://starship.python.net/crew/fdrake/patches/weakkeys.patch-2 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-02-27 10:07 Message: Logged In: YES user_id=3066 Modified the patch slightly, adding some small documentation revisions and changing the name of WeakDictionary to WeakValueDictionary. Martin, if you're still happy with this after my changes, please feel free to check it in. Thanks! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-02-26 11:12 Message: Logged In: YES user_id=3066 I'll take a look at this (and some other patches) later today. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403985&group_id=5470 From nobody@sourceforge.net Tue Feb 27 18:40:46 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 10:40:46 -0800 Subject: [Patches] [ python-Patches-403985 ] Add support for weak-keyed dictionaries Message-ID: Patches #403985, was updated on 2001-02-23 23:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403985&group_id=5470 Category: Modules Group: None Status: Closed Priority: 7 Submitted By: Martin v. Löwis Assigned to: Martin v. Löwis Summary: Add support for weak-keyed dictionaries Initial Comment: This patch adds a parameter weakkeys to weakref.mapping. To allow weak references as dictionary keys, they cache their hash value and support equality. ---------------------------------------------------------------------- Comment By: Martin v. Löwis Date: 2001-02-27 10:40 Message: Logged In: YES user_id=21627 Committed weakkeys.patch-2 as 1.2 of test_weakref.py and output/test_weakref, 1.3 of libweakref.tex, 1.4 of weakref.py, and 1.7 of _weakref.c. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-02-27 10:17 Message: Logged In: YES user_id=3066 (Sigh...) Updating the patch here doesn't seem to be working. I've placed the revised patch here: http://starship.python.net/crew/fdrake/patches/weakkeys.patch-2 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-02-27 10:07 Message: Logged In: YES user_id=3066 Modified the patch slightly, adding some small documentation revisions and changing the name of WeakDictionary to WeakValueDictionary. Martin, if you're still happy with this after my changes, please feel free to check it in. Thanks! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-02-26 11:12 Message: Logged In: YES user_id=3066 I'll take a look at this (and some other patches) later today. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403985&group_id=5470 From nobody@sourceforge.net Tue Feb 27 18:48:34 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 10:48:34 -0800 Subject: [Patches] [ python-Patches-404275 ] get_platform(), patch for AIX Message-ID: Patches #404275, was updated on 2001-02-26 05:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404275&group_id=5470 Category: distutils Group: None Status: Closed Priority: 5 Submitted By: Rene Liebscher Assigned to: A.M. Kuchling Summary: get_platform(), patch for AIX Initial Comment: The platform string which is build by get_platform() for AIX doesnt make much sense. Therefore I provide here a patch which brings up a better string. (eg. for AIX 4.3 -> aix-4.3 not aix-3-XXXXXXXXXXXX , uname/machine seems to be a hardware/network id ? ) ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-02-27 10:48 Message: Logged In: YES user_id=11375 Accepted and applied; thanks! ---------------------------------------------------------------------- Comment By: Rene Liebscher Date: 2001-02-26 05:22 Message: Logged In: YES user_id=28463 Index: distutils/util.py =================================================================== RCS file: /cvsroot/python/distutils/distutils/util.py,v retrieving revision 1.59 diff -c -r1.59 util.py *** distutils/util.py 2001/01/28 12:23:32 1.59 --- distutils/util.py 2001/02/26 13:04:11 *************** *** 54,59 **** --- 54,61 ---- # fall through to standard osname-release-machine representation elif osname[:4] == "irix": # could be "irix64"! return "%s-%s" % (osname, release) + elif osname[:3] == "aix": + return "%s-%s.%s" % (osname, version, release) elif osname[:6] == "cygwin": rel_re = re.compile (r'[\d.]+') m = rel_re.match(release) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404275&group_id=5470 From nobody@sourceforge.net Tue Feb 27 18:53:33 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 10:53:33 -0800 Subject: [Patches] [ python-Patches-403903 ] Change EXEEXT back to EXE in the makefile Message-ID: Patches #403903, was updated on 2001-02-20 11:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403903&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Neil Schemenauer Assigned to: Neil Schemenauer Summary: Change EXEEXT back to EXE in the makefile Initial Comment: I think changing EXE to EXEEXT in the Makefile was a bad idea. I changed it because I wanted the Makefile variable to have the same name as the configure variable. I now think that backwards compatibility it more important. EXE is used by both regen and distutils. Its possible that 3rd party tools use it as well. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-02-27 09:49 Message: Logged In: YES user_id=3066 Assigned to Neil since he appearantly has time to handle this. ---------------------------------------------------------------------- Comment By: Jason Tishler Date: 2001-02-27 09:42 Message: Logged In: YES user_id=86216 I just reviewed the patch and it looks good to me. Let me know when you check it in and I will do a cvs update and test it for you. ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-27 09:28 Message: Logged In: YES user_id=35752 Jason, does this patch look okay to you? If it does I will check it in. I've been making a lot of stupid build process checkins lately and want some peer review. ---------------------------------------------------------------------- Comment By: Jason Tishler Date: 2001-02-27 09:17 Message: Logged In: YES user_id=86216 Will this patch be committed in time for Beta 1 scheduled for Thursday, 3/1/01? Without it Cygwin Python no longer builds (i.e., installs) OOTB. ---------------------------------------------------------------------- Comment By: Jason Tishler Date: 2001-02-21 11:37 Message: Note that Marc has informed me that he will be offline for the next two weeks so may be this should be assigned to someone else... ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-20 11:11 Message: Assigned to Marc mostly at random. Please review or assign to someone else. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403903&group_id=5470 From nobody@sourceforge.net Tue Feb 27 18:57:39 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 10:57:39 -0800 Subject: [Patches] [ python-Patches-404282 ] Manifest.in not included in sdist... Message-ID: Patches #404282, was updated on 2001-02-26 05:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404282&group_id=5470 Category: distutils Group: None Status: Closed Priority: 5 Submitted By: Rene Liebscher Assigned to: A.M. Kuchling Summary: Manifest.in not included in sdist... Initial Comment: The sdist command includes some files in MANIFEST without you to have specify them (setup.py, README) (The use_defaults option is on by default.) If you create MANIFEST from MANIFEST.IN then it should also include MANIFEST.IN. (see also http://mail.python.org/pipermail/distutils-sig/2000-October/001685.html ) This patch adds the template file if it is used and use_defaults is on. ------------------------------------------------------- Index: distutils/command/sdist.py =================================================================== RCS file: /cvsroot/python/distutils/distutils/command/sdist.py,v retrieving revision 1.51 diff -c -r1.51 sdist.py *** distutils/command/sdist.py 2000/10/14 04:06:40 1.51 --- distutils/command/sdist.py 2001/02/26 13:27:48 *************** *** 244,249 **** --- 244,251 ---- # Read manifest template if it exists if template_exists: self.read_template() + if self.use_defaults: # don't forget MANIFEST.in + self.filelist.append(self.template) # Prune away any directories that don't belong in the source # distribution ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-02-27 10:57 Message: Logged In: YES user_id=11375 I don't think I like this patch, because it means figuring out which files are added by setting .use_defaults If you already have a MANIFEST.in, why not just add a 'include MANIFEST.in' to it? Comment boxes on SF have always swallowed the whitespace; patches should always be provided as an uploaded file. ---------------------------------------------------------------------- Comment By: Rene Liebscher Date: 2001-02-26 05:38 Message: Logged In: YES user_id=28463 Where are the blanks? (see http://mail.python.org/pipermail/distutils-sig/2000-October/001693.html for a correct indentation) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404282&group_id=5470 From nobody@sourceforge.net Tue Feb 27 18:58:32 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 10:58:32 -0800 Subject: [Patches] [ python-Patches-403445 ] Fixed DB_RECNO support in bsddb module Message-ID: Patches #403445, was updated on 2001-01-26 10:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403445&group_id=5470 Category: Modules Group: None Status: Closed Priority: 5 Submitted By: Gustavo Niemeyer Assigned to: Fred L. Drake, Jr. Summary: Fixed DB_RECNO support in bsddb module Initial Comment: This module was handling DB_RECNO databases incorrectly, handling the keys as strings. As the documentation says, RECNO (record number) databases must deal with integers, using the special type recno_t. This patch fixes it. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-02-27 10:58 Message: Logged In: YES user_id=3066 Checked in as Modules/bsddbmodule.c revision 1.28. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer Date: 2001-02-20 08:49 Message: Ok. This bug is happening due to a libdb bug. Between other things, it's closing the input fd (0). I've done a little hack to avoid this bug, so, I'm sending an updated patch. Thanks! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-02-19 13:07 Message: I'm inclined to apply this, but am having problems with the bsddb module in general. I would like to see some tests that work with RECNO databases. With or without this patch, this snippet: >>> import bsddb >>> db = bsddb.rnopen('foo.db') (where foo.db does not exist) is causing a core dump somewhere in the exception handling code (Mandrake Linux 7.1, stock libraries). What platform did you test this patch on? What versions of the libraries? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-01-27 23:11 Message: Re-assigned to me; Skip only worked on the build process for this, not the module code. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-01-26 22:06 Message: I think this is fine from a quick eyeballing of the code, but would add the di_type declaration before the WITH_THREAD conditional section so that the optional part is at the end. Assigned to Skip since he's dealt a lot with this module recently. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403445&group_id=5470 From nobody@sourceforge.net Tue Feb 27 19:01:32 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 11:01:32 -0800 Subject: [Patches] [ python-Patches-403948 ] uninstaller for bdist_wininst Message-ID: Patches #403948, was updated on 2001-02-22 08:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403948&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Thomas Heller Assigned to: Thomas Heller Summary: uninstaller for bdist_wininst Initial Comment: Uninstaller for bdist_wininst. Has been described fairly extensively in http://mail.python.org/pipermail/distutils-sig/2001-February/001991.html. This version differs from the posted beta-version in better error checking. The patch is not complete: distutils/command/bdist_wininst.py has to be regenerated after the C-code has been compiled. I'm requesting permission to check this in. ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-02-27 11:01 Message: Logged In: YES user_id=11375 You have permission from me, though I can't really comment on the approach. No one else on python-dev seemed interested in inspecting it, and you're the Windows/Distutils installer expert, so go ahead. ---------------------------------------------------------------------- Comment By: Thomas Heller Date: 2001-02-22 08:28 Message: Uninstaller for bdist_wininst. Has been described detailed in http://mail.python.org/pipermail/distutils-sig/2001-February/001991.html. This version differs from the posted beta-version in better error checking. The patch is not complete: distutils/command/bdist_wininst.py has to be regenerated after the C-code has been compiled. I'm requesting permission to check this in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403948&group_id=5470 From nobody@sourceforge.net Tue Feb 27 19:13:43 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 11:13:43 -0800 Subject: [Patches] [ python-Patches-403947 ] For Cygwin built Python use Cygwin like an UNIX C compiler Message-ID: Patches #403947, was updated on 2001-02-22 07:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403947&group_id=5470 Category: distutils Group: None Status: Closed Priority: 5 Submitted By: Rene Liebscher Assigned to: A.M. Kuchling Summary: For Cygwin built Python use Cygwin like an UNIX C compiler Initial Comment: The patch from 1.37->1.38 went too far, as it assigns the cygwinccompiler class as default for Pythons built with cygwin. You can use cygwin in this case as normal UNIX-like compiler. (cygwinccompiler needs some work to handle the differences in Cygwin- and MSVC-Python. Makefile and config files are currently ignored by cygwinccompiler, as it was written to support cygwin for extensions which are intended to be used with the standard MSVC built Python.) ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-02-27 11:13 Message: Logged In: YES user_id=11375 Accepted and checked in; thanks! ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-02-27 09:31 Message: Logged In: YES user_id=11375 Assigning to myself; I'll look at it after lunch. ---------------------------------------------------------------------- Comment By: Jason Tishler Date: 2001-02-27 09:13 Message: Logged In: YES user_id=86216 Will this patch be committed in time for Beta 1 scheduled for Thursday, 3/1/01? Without it Cygwin Python no longer builds OOTB. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403947&group_id=5470 From nobody@sourceforge.net Tue Feb 27 20:03:58 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 12:03:58 -0800 Subject: [Patches] [ python-Patches-403903 ] Change EXEEXT back to EXE in the makefile Message-ID: Patches #403903, was updated on 2001-02-20 11:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403903&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Neil Schemenauer Assigned to: Neil Schemenauer Summary: Change EXEEXT back to EXE in the makefile Initial Comment: I think changing EXE to EXEEXT in the Makefile was a bad idea. I changed it because I wanted the Makefile variable to have the same name as the configure variable. I now think that backwards compatibility it more important. EXE is used by both regen and distutils. Its possible that 3rd party tools use it as well. ---------------------------------------------------------------------- Comment By: Jason Tishler Date: 2001-02-27 12:03 Message: Logged In: YES user_id=86216 My testing verifies that the patch works correctly for Cygwin. Thanks! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-02-27 09:49 Message: Logged In: YES user_id=3066 Assigned to Neil since he appearantly has time to handle this. ---------------------------------------------------------------------- Comment By: Jason Tishler Date: 2001-02-27 09:42 Message: Logged In: YES user_id=86216 I just reviewed the patch and it looks good to me. Let me know when you check it in and I will do a cvs update and test it for you. ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-27 09:28 Message: Logged In: YES user_id=35752 Jason, does this patch look okay to you? If it does I will check it in. I've been making a lot of stupid build process checkins lately and want some peer review. ---------------------------------------------------------------------- Comment By: Jason Tishler Date: 2001-02-27 09:17 Message: Logged In: YES user_id=86216 Will this patch be committed in time for Beta 1 scheduled for Thursday, 3/1/01? Without it Cygwin Python no longer builds (i.e., installs) OOTB. ---------------------------------------------------------------------- Comment By: Jason Tishler Date: 2001-02-21 11:37 Message: Note that Marc has informed me that he will be offline for the next two weeks so may be this should be assigned to someone else... ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-20 11:11 Message: Assigned to Marc mostly at random. Please review or assign to someone else. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403903&group_id=5470 From nobody@sourceforge.net Tue Feb 27 20:19:44 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 12:19:44 -0800 Subject: [Patches] [ python-Patches-404680 ] Two more Cygwin standard module issues Message-ID: Patches #404680, was updated on 2001-02-27 12:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404680&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Jason Tishler Assigned to: Nobody/Anonymous Summary: Two more Cygwin standard module issues Initial Comment: This patch disables the nis module and enables the dl module when building under Cygwin. Use patch -p0 Patches #404680, was updated on 2001-02-27 12:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404680&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Jason Tishler Assigned to: A.M. Kuchling Summary: Two more Cygwin standard module issues Initial Comment: This patch disables the nis module and enables the dl module when building under Cygwin. Use patch -p0 Patches #404680, was updated on 2001-02-27 12:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404680&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Jason Tishler Assigned to: A.M. Kuchling Summary: Two more Cygwin standard module issues Initial Comment: This patch disables the nis module and enables the dl module when building under Cygwin. Use patch -p0 Patches #404684, was updated on 2001-02-27 12:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404684&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: A.M. Kuchling Assigned to: A.M. Kuchling Summary: Test patch Initial Comment: Patch uploads don't seem to work -- testing. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404684&group_id=5470 From nobody@sourceforge.net Tue Feb 27 20:39:04 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 12:39:04 -0800 Subject: [Patches] [ python-Patches-404684 ] Test patch Message-ID: Patches #404684, was updated on 2001-02-27 12:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404684&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: A.M. Kuchling Assigned to: A.M. Kuchling Summary: Test patch Initial Comment: Patch uploads don't seem to work -- testing. ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-02-27 12:39 Message: Logged In: YES user_id=11375 Trying again... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404684&group_id=5470 From nobody@sourceforge.net Tue Feb 27 20:41:29 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 12:41:29 -0800 Subject: [Patches] [ python-Patches-404680 ] Two more Cygwin standard module issues Message-ID: Patches #404680, was updated on 2001-02-27 12:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404680&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Jason Tishler Assigned to: A.M. Kuchling Summary: Two more Cygwin standard module issues Initial Comment: This patch disables the nis module and enables the dl module when building under Cygwin. Use patch -p0 Patches #404680, was updated on 2001-02-27 12:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404680&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Jason Tishler Assigned to: A.M. Kuchling Summary: Two more Cygwin standard module issues Initial Comment: This patch disables the nis module and enables the dl module when building under Cygwin. Use patch -p0 Patches #404684, was updated on 2001-02-27 12:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404684&group_id=5470 Category: None Group: None Status: Deleted Priority: 5 Submitted By: A.M. Kuchling Assigned to: A.M. Kuchling Summary: Test patch Initial Comment: Patch uploads don't seem to work -- testing. ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-02-27 12:47 Message: Logged In: YES user_id=11375 Deleting -- file uploads do seem to be broken. ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-02-27 12:39 Message: Logged In: YES user_id=11375 Trying again... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404684&group_id=5470 From nobody@sourceforge.net Tue Feb 27 20:48:48 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 12:48:48 -0800 Subject: [Patches] [ python-Patches-403977 ] Rename config.h to pyac_config.h, per SF bug #131774 Message-ID: Patches #403977, was updated on 2001-02-23 13:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Thomas Wouters Assigned to: Jeremy Hylton Summary: Rename config.h to pyac_config.h, per SF bug #131774 Initial Comment: This patch fixes the UNIX and Windows builds to use 'pyac_config.h' instead of 'config.h', to avoid the problems summarized in SF bug #131774. It doesn't address the placing issue, however, because I believe it's intended to be like this. Most changes were done using a fairly intelligent shell+sed oneliner, but they should be correct. The Windows build *seems* correct, though I can't be sure. Someone will have to check ;) It is probably a good idea to remove 'config.h' before testing, to be sure I got all references. The UNIX build requires that autoconf is installed, and requires a 'autoheader ; autoconf' is done before running 'configure'. Removing config.h(.in) is also a good idea. I excluded the OS2 build files, and will be uploading those as a seperate patch to avoid making this one unreadable Though only two files are involved, they both list all dependencies for *all* files in its entirety, so the patch is quite large. If those files are auto-generated, someone please tell me so :-) I also didn't fix distutils, though it looks like it does need fixing. And I didn't do anything wrt. backwards compatibility. We should probably provide a config.h that just does #warning Warning: Use of Python-specific config.h is deprecated. Use pyac_config.h instead. #include The name is just my suggestion, changing it into something less acronymic would be no problem at all. I think 'pythonconfig.h' gives the wrong message though: the file isn't used to configure Python itself, after all ;) ---------------------------------------------------------------------- Comment By: Tim Peters Date: 2001-02-27 12:48 Message: Logged In: YES user_id=31435 Pushed onto Jeremy. Jeremy, we want to do this much fiddling so late in the cycle? Thomas, don't worry about Windows. I only need a warning about that, and I've aware of this now (thanks!). Check in the new MS project files or don't, it's easy for me to fix 'em up regardless (indeed, it's not worth extra time to check it in advance). Note that "#warning" is not std C. I'm afraid you'll have to make it an #error. OTOH, if you leave a file *named* "config.h" in the distribution, it doesn't really address the bug report, right? BTW, I have no idea what "pyac" is supposed to bring to mind. Is that some Unixism? ---------------------------------------------------------------------- Comment By: Thomas Wouters Date: 2001-02-23 13:32 Message: Apologies for the large blurb in the 'details' section. I keep forgetting SF strips *all* whitespace from that block :( Assigning to Tim "The Windows Bot" Peters to test (and fix) the Windows build changes. Let me know if your patch still doesn't work and you want me to send you patched files instead, Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 From nobody@sourceforge.net Tue Feb 27 20:49:15 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 12:49:15 -0800 Subject: [Patches] [ python-Patches-404680 ] Two more Cygwin standard module issues Message-ID: Patches #404680, was updated on 2001-02-27 12:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404680&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Jason Tishler Assigned to: A.M. Kuchling Summary: Two more Cygwin standard module issues Initial Comment: This patch disables the nis module and enables the dl module when building under Cygwin. Use patch -p0 Patches #404680, was updated on 2001-02-27 12:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404680&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Jason Tishler Assigned to: A.M. Kuchling Summary: Two more Cygwin standard module issues Initial Comment: This patch disables the nis module and enables the dl module when building under Cygwin. Use patch -p0 Patches #403977, was updated on 2001-02-23 13:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Thomas Wouters Assigned to: Jeremy Hylton Summary: Rename config.h to pyac_config.h, per SF bug #131774 Initial Comment: This patch fixes the UNIX and Windows builds to use 'pyac_config.h' instead of 'config.h', to avoid the problems summarized in SF bug #131774. It doesn't address the placing issue, however, because I believe it's intended to be like this. Most changes were done using a fairly intelligent shell+sed oneliner, but they should be correct. The Windows build *seems* correct, though I can't be sure. Someone will have to check ;) It is probably a good idea to remove 'config.h' before testing, to be sure I got all references. The UNIX build requires that autoconf is installed, and requires a 'autoheader ; autoconf' is done before running 'configure'. Removing config.h(.in) is also a good idea. I excluded the OS2 build files, and will be uploading those as a seperate patch to avoid making this one unreadable Though only two files are involved, they both list all dependencies for *all* files in its entirety, so the patch is quite large. If those files are auto-generated, someone please tell me so :-) I also didn't fix distutils, though it looks like it does need fixing. And I didn't do anything wrt. backwards compatibility. We should probably provide a config.h that just does #warning Warning: Use of Python-specific config.h is deprecated. Use pyac_config.h instead. #include The name is just my suggestion, changing it into something less acronymic would be no problem at all. I think 'pythonconfig.h' gives the wrong message though: the file isn't used to configure Python itself, after all ;) ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-02-27 13:05 Message: Logged In: YES user_id=11375 Regarding Distutils: I think the only actual *code* that would change is in distutils/sysconfig.py, in the get_config_h_filename() method. For backward compat., this method would probably have to check the Python version and use pyac_config.h if the version is 2.1 or greater. There are also lots of references to config.h in comments; we can change those or not, as desired. (I probably *would* change most of them.) ---------------------------------------------------------------------- Comment By: Tim Peters Date: 2001-02-27 12:48 Message: Logged In: YES user_id=31435 Pushed onto Jeremy. Jeremy, we want to do this much fiddling so late in the cycle? Thomas, don't worry about Windows. I only need a warning about that, and I've aware of this now (thanks!). Check in the new MS project files or don't, it's easy for me to fix 'em up regardless (indeed, it's not worth extra time to check it in advance). Note that "#warning" is not std C. I'm afraid you'll have to make it an #error. OTOH, if you leave a file *named* "config.h" in the distribution, it doesn't really address the bug report, right? BTW, I have no idea what "pyac" is supposed to bring to mind. Is that some Unixism? ---------------------------------------------------------------------- Comment By: Thomas Wouters Date: 2001-02-23 13:32 Message: Apologies for the large blurb in the 'details' section. I keep forgetting SF strips *all* whitespace from that block :( Assigning to Tim "The Windows Bot" Peters to test (and fix) the Windows build changes. Let me know if your patch still doesn't work and you want me to send you patched files instead, Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 From nobody@sourceforge.net Tue Feb 27 21:53:25 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 13:53:25 -0800 Subject: [Patches] [ python-Patches-403977 ] Rename config.h to pyac_config.h, per SF bug #131774 Message-ID: Patches #403977, was updated on 2001-02-23 13:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Thomas Wouters Assigned to: Jeremy Hylton Summary: Rename config.h to pyac_config.h, per SF bug #131774 Initial Comment: This patch fixes the UNIX and Windows builds to use 'pyac_config.h' instead of 'config.h', to avoid the problems summarized in SF bug #131774. It doesn't address the placing issue, however, because I believe it's intended to be like this. Most changes were done using a fairly intelligent shell+sed oneliner, but they should be correct. The Windows build *seems* correct, though I can't be sure. Someone will have to check ;) It is probably a good idea to remove 'config.h' before testing, to be sure I got all references. The UNIX build requires that autoconf is installed, and requires a 'autoheader ; autoconf' is done before running 'configure'. Removing config.h(.in) is also a good idea. I excluded the OS2 build files, and will be uploading those as a seperate patch to avoid making this one unreadable Though only two files are involved, they both list all dependencies for *all* files in its entirety, so the patch is quite large. If those files are auto-generated, someone please tell me so :-) I also didn't fix distutils, though it looks like it does need fixing. And I didn't do anything wrt. backwards compatibility. We should probably provide a config.h that just does #warning Warning: Use of Python-specific config.h is deprecated. Use pyac_config.h instead. #include The name is just my suggestion, changing it into something less acronymic would be no problem at all. I think 'pythonconfig.h' gives the wrong message though: the file isn't used to configure Python itself, after all ;) ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-27 13:53 Message: Logged In: YES user_id=35752 SF seems to have changed the bug ids! I can't find bug #131774. Unless there is a very good reason for the change I'm against it for 2.1. ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-02-27 13:05 Message: Logged In: YES user_id=11375 Regarding Distutils: I think the only actual *code* that would change is in distutils/sysconfig.py, in the get_config_h_filename() method. For backward compat., this method would probably have to check the Python version and use pyac_config.h if the version is 2.1 or greater. There are also lots of references to config.h in comments; we can change those or not, as desired. (I probably *would* change most of them.) ---------------------------------------------------------------------- Comment By: Tim Peters Date: 2001-02-27 12:48 Message: Logged In: YES user_id=31435 Pushed onto Jeremy. Jeremy, we want to do this much fiddling so late in the cycle? Thomas, don't worry about Windows. I only need a warning about that, and I've aware of this now (thanks!). Check in the new MS project files or don't, it's easy for me to fix 'em up regardless (indeed, it's not worth extra time to check it in advance). Note that "#warning" is not std C. I'm afraid you'll have to make it an #error. OTOH, if you leave a file *named* "config.h" in the distribution, it doesn't really address the bug report, right? BTW, I have no idea what "pyac" is supposed to bring to mind. Is that some Unixism? ---------------------------------------------------------------------- Comment By: Thomas Wouters Date: 2001-02-23 13:32 Message: Apologies for the large blurb in the 'details' section. I keep forgetting SF strips *all* whitespace from that block :( Assigning to Tim "The Windows Bot" Peters to test (and fix) the Windows build changes. Let me know if your patch still doesn't work and you want me to send you patched files instead, Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 From nobody@sourceforge.net Tue Feb 27 22:16:11 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 14:16:11 -0800 Subject: [Patches] [ python-Patches-404680 ] Two more Cygwin standard module issues Message-ID: Patches #404680, was updated on 2001-02-27 12:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404680&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Jason Tishler Assigned to: A.M. Kuchling Summary: Two more Cygwin standard module issues Initial Comment: This patch disables the nis module and enables the dl module when building under Cygwin. Use patch -p0 Patches #404680, was updated on 2001-02-27 12:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404680&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Jason Tishler Assigned to: A.M. Kuchling Summary: Two more Cygwin standard module issues Initial Comment: This patch disables the nis module and enables the dl module when building under Cygwin. Use patch -p0 Patches #404680, was updated on 2001-02-27 12:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404680&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Jason Tishler Assigned to: A.M. Kuchling Summary: Two more Cygwin standard module issues Initial Comment: This patch disables the nis module and enables the dl module when building under Cygwin. Use patch -p0 Patches #404680, was updated on 2001-02-27 12:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404680&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Jason Tishler Assigned to: A.M. Kuchling Summary: Two more Cygwin standard module issues Initial Comment: This patch disables the nis module and enables the dl module when building under Cygwin. Use patch -p0 Patches #404680, was updated on 2001-02-27 12:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404680&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Jason Tishler Assigned to: A.M. Kuchling Summary: Two more Cygwin standard module issues Initial Comment: This patch disables the nis module and enables the dl module when building under Cygwin. Use patch -p0 Patches #404680, was updated on 2001-02-27 12:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404680&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Jason Tishler Assigned to: A.M. Kuchling Summary: Two more Cygwin standard module issues Initial Comment: This patch disables the nis module and enables the dl module when building under Cygwin. Use patch -p0 Patches #404680, was updated on 2001-02-27 12:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404680&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Jason Tishler Assigned to: A.M. Kuchling Summary: Two more Cygwin standard module issues Initial Comment: This patch disables the nis module and enables the dl module when building under Cygwin. Use patch -p0 Patches #404680, was updated on 2001-02-27 12:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404680&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Jason Tishler Assigned to: A.M. Kuchling Summary: Two more Cygwin standard module issues Initial Comment: This patch disables the nis module and enables the dl module when building under Cygwin. Use patch -p0 Patches #404680, was updated on 2001-02-27 12:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404680&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Jason Tishler Assigned to: A.M. Kuchling Summary: Two more Cygwin standard module issues Initial Comment: This patch disables the nis module and enables the dl module when building under Cygwin. Use patch -p0 Patches #404680, was updated on 2001-02-27 12:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404680&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Jason Tishler Assigned to: A.M. Kuchling Summary: Two more Cygwin standard module issues Initial Comment: This patch disables the nis module and enables the dl module when building under Cygwin. Use patch -p0 Patches #404680, was updated on 2001-02-27 12:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404680&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Jason Tishler Assigned to: A.M. Kuchling Summary: Two more Cygwin standard module issues Initial Comment: This patch disables the nis module and enables the dl module when building under Cygwin. Use patch -p0 Patches #403871, was updated on 2001-02-18 20:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403871&group_id=5470 Category: None Group: None Status: Closed Priority: 5 Submitted By: Dave Kuhlman Assigned to: Fred L. Drake, Jr. Summary: self.fp not defined in class ZipFile for non-existing file Initial Comment: Here is a small nit, but perhaps a nit that needs to be picked. I'm using Python 2.1a2 that I built from source on Win 2000 with VC++ 6.0. In using the ZipFile module, I tried to trap the exception generated when the file does not exist. I was surprised by the attribute exception, as shown below: ===================================== //c/Dave/Python/Test [13] python Python 2.1a2 (#10, Feb 13 2001, 10:45:16) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import zipfile as z >>> try: ... a = z.ZipFile('anonexistentfile.zip') ... except IOError: ... print 'io error' ... io error Exception exceptions.AttributeError: "ZipFile instance has no attribute 'fp'" in ignored >>> ===================================== I fixed this by adding the following line at the beginning of method __init__() in class ZipFile in file lib/zipfile.py: self.fp = None Hope this helps. - Dave ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-02-27 21:35 Message: Logged In: YES user_id=3066 Fixed in Lib/zipfile.py revision 1.6; regression test added in Lib/test/test_zipfile.py revision 1.3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403871&group_id=5470 From nobody@sourceforge.net Wed Feb 28 05:41:09 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 21:41:09 -0800 Subject: [Patches] [ python-Patches-404163 ] New platform support: RISC OS Message-ID: Patches #404163, was updated on 2001-02-25 14:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404163&group_id=5470 Category: core (C code) Group: None Status: Closed Priority: 5 Submitted By: Dietmar Schwertberger Assigned to: Nobody/Anonymous Summary: New platform support: RISC OS Initial Comment: Hi, these patches add support for the RISC OS operating system (running on the computers formerly produced by the british manufacturer Acorn). The attached .tar.gz archive contains the following: 1. A file Patches.txt with context diffs (relative to 2.0 release sources) to 16 C source and library files. 2. A directory Lib.plat-riscos with RISC OS specific library files 3. A directory RISCOS with RISC OS specific C source and support files. Thanks, Dietmar dietmar@schwertberger.de ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-02-27 21:41 Message: Logged In: YES user_id=3066 Duplicate submission. ---------------------------------------------------------------------- Comment By: Dietmar Schwertberger Date: 2001-02-25 14:56 Message: Logged In: YES user_id=86612 Please ignore this patch and refer to 404162. Where are the delete and undo buttons? The mentioned archive is available from http://www.schwertberger.de/RISCOSFiles.tar.gz Sorry for having submitted multiple, but my browser and sourceforge seem to dislike each other. Especially uploading seems to be impossible. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404163&group_id=5470 From nobody@sourceforge.net Wed Feb 28 05:41:54 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 21:41:54 -0800 Subject: [Patches] [ python-Patches-404159 ] New platform support: RISC OS Message-ID: Patches #404159, was updated on 2001-02-25 14:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404159&group_id=5470 Category: core (C code) Group: None Status: Closed Priority: 5 Submitted By: Nobody/Anonymous Assigned to: Nobody/Anonymous Summary: New platform support: RISC OS Initial Comment: Hi, these patches add support for the RISC OS operating system (running on the ARM based computers that were formerly produced by the british manufacturer Acorn). The attached .tar.gz archive contains following: 1. A file Patches.txt with context diffs (relative to 2.0 release sources) to 16 C and library files. 2. A directory Lib.plat-riscos with RISC OS specific library files 3. A directory RISCOS with RISC OS specific source and support files. Thanks, Dietmar dietmar@schwertberger.de ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-02-27 21:41 Message: Logged In: YES user_id=3066 Duplicate submission. ---------------------------------------------------------------------- Comment By: Dietmar Schwertberger Date: 2001-02-25 14:59 Message: Logged In: YES user_id=86612 Please ignore this patch and refer to 404162. The mentioned archive is available from http://www.schwertberger.de/RISCOSFiles.tar.gz Sorry for having submitted multiple, but my browser and sourceforge seem to dislike each other. Especially uploading seems to be impossible. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404159&group_id=5470 From nobody@sourceforge.net Wed Feb 28 07:14:43 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 23:14:43 -0800 Subject: [Patches] [ python-Patches-403977 ] Rename config.h to pyac_config.h, per SF bug #131774 Message-ID: Patches #403977, was updated on 2001-02-23 13:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Thomas Wouters Assigned to: Guido van Rossum Summary: Rename config.h to pyac_config.h, per SF bug #131774 Initial Comment: This patch fixes the UNIX and Windows builds to use 'pyac_config.h' instead of 'config.h', to avoid the problems summarized in SF bug #131774. It doesn't address the placing issue, however, because I believe it's intended to be like this. Most changes were done using a fairly intelligent shell+sed oneliner, but they should be correct. The Windows build *seems* correct, though I can't be sure. Someone will have to check ;) It is probably a good idea to remove 'config.h' before testing, to be sure I got all references. The UNIX build requires that autoconf is installed, and requires a 'autoheader ; autoconf' is done before running 'configure'. Removing config.h(.in) is also a good idea. I excluded the OS2 build files, and will be uploading those as a seperate patch to avoid making this one unreadable Though only two files are involved, they both list all dependencies for *all* files in its entirety, so the patch is quite large. If those files are auto-generated, someone please tell me so :-) I also didn't fix distutils, though it looks like it does need fixing. And I didn't do anything wrt. backwards compatibility. We should probably provide a config.h that just does #warning Warning: Use of Python-specific config.h is deprecated. Use pyac_config.h instead. #include The name is just my suggestion, changing it into something less acronymic would be no problem at all. I think 'pythonconfig.h' gives the wrong message though: the file isn't used to configure Python itself, after all ;) ---------------------------------------------------------------------- Comment By: Jeremy Hylton Date: 2001-02-27 23:14 Message: Logged In: YES user_id=31392 No time ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-27 13:53 Message: Logged In: YES user_id=35752 SF seems to have changed the bug ids! I can't find bug #131774. Unless there is a very good reason for the change I'm against it for 2.1. ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-02-27 13:05 Message: Logged In: YES user_id=11375 Regarding Distutils: I think the only actual *code* that would change is in distutils/sysconfig.py, in the get_config_h_filename() method. For backward compat., this method would probably have to check the Python version and use pyac_config.h if the version is 2.1 or greater. There are also lots of references to config.h in comments; we can change those or not, as desired. (I probably *would* change most of them.) ---------------------------------------------------------------------- Comment By: Tim Peters Date: 2001-02-27 12:48 Message: Logged In: YES user_id=31435 Pushed onto Jeremy. Jeremy, we want to do this much fiddling so late in the cycle? Thomas, don't worry about Windows. I only need a warning about that, and I've aware of this now (thanks!). Check in the new MS project files or don't, it's easy for me to fix 'em up regardless (indeed, it's not worth extra time to check it in advance). Note that "#warning" is not std C. I'm afraid you'll have to make it an #error. OTOH, if you leave a file *named* "config.h" in the distribution, it doesn't really address the bug report, right? BTW, I have no idea what "pyac" is supposed to bring to mind. Is that some Unixism? ---------------------------------------------------------------------- Comment By: Thomas Wouters Date: 2001-02-23 13:32 Message: Apologies for the large blurb in the 'details' section. I keep forgetting SF strips *all* whitespace from that block :( Assigning to Tim "The Windows Bot" Peters to test (and fix) the Windows build changes. Let me know if your patch still doesn't work and you want me to send you patched files instead, Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 From nobody@sourceforge.net Wed Feb 28 07:13:49 2001 From: nobody@sourceforge.net (nobody) Date: Tue, 27 Feb 2001 23:13:49 -0800 Subject: [Patches] [ python-Patches-401782 ] Enhances 1.6 compiler to raise 'proper' SyntaxErrors Message-ID: Patches #401782, was updated on 2000-10-04 12:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401782&group_id=5470 Category: Parser/Compiler Group: None Status: Closed Priority: 5 Submitted By: Roman Sulzhyk Assigned to: Jeremy Hylton Summary: Enhances 1.6 compiler to raise 'proper' SyntaxErrors Initial Comment: ---------------------------------------------------------------------- Comment By: Jeremy Hylton Date: 2001-02-27 23:13 Message: Logged In: YES user_id=31392 This patch does a lot of work to keep the actual file pointer or string passed to the compiler, then re-use it when a SyntaxError is raised. This seems more complicated than necessary for file compilation, because the compiler can just re-open the file. I have opted for this approach in rev. 2.175 for compile.c. The downside of the choice is that expressions entered at the interactive prompt don't appear in the exception. I think this isn't a big problem, because the text was just entered. The changes in 2.175 are also more cleanly integrated with the exception raising facilities. It may be worth re-considering the interactive version of the patch after 2.1b1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton Date: 2001-02-02 10:36 Message: Oh, BTW, with all the changes to the compiler for 2.1, this patch no longer works. If you're interested in updating it, I'd appreciate it. I'll look at the patch either way, though. ---------------------------------------------------------------------- Comment By: Jeremy Hylton Date: 2001-02-02 10:35 Message: I didn't get a chance to look at this before 2.1a2. I will look at it before 2.1b1, because it appears to fall under the bug fix category. ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-01-19 14:51 Message: This is better for Jeremy to review, since he has done a major refactoring on the compiler code. Jeremy, I don't want this in 2.1a1, but could you see if you can get it either approved or rejected in time for 2.1a2? ---------------------------------------------------------------------- Comment By: Roman Sulzhyk Date: 2000-10-09 10:59 Message: I've ported it to the latest CVS version - check it out, Roman ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2000-10-04 23:40 Message: This needs to be ported to the latest CVS version before being considered for implementation (but discussion of the feature is welcome!). This cannot be considered for inclusion in 2.0 since we're in feature freeze already, and are only fixing bugs at this point. This can be considered for 2.1. Marking as postponed. ---------------------------------------------------------------------- Comment By: Roman Sulzhyk Date: 2000-10-04 12:29 Message: Hello: There's a problem with the compiler.c (which persists in 2.0 also) which means it raises 'old style' SyntaxErrors, which could not be formatted properly. I mentioned this to Guido during the last conference, and he said it can best be done by moving parts of the 'linecache' functionality to core python, or something along those lines. Well, I've put together something which is not so far-fetching, but plugs this hole. The only time it reverts to the 'old style' compile error is when the input file is not a regular file (like stdin), since the line information is lost at that point - don't think parser.c saves it anywhere. Tell me what you think - should I port it to 2.0, or just drop it altogether if it's not needed. Thanks, Roman ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=401782&group_id=5470 From nobody@sourceforge.net Wed Feb 28 09:01:53 2001 From: nobody@sourceforge.net (nobody) Date: Wed, 28 Feb 2001 01:01:53 -0800 Subject: [Patches] [ python-Patches-403978 ] config.h -> pyac_config.h change for OS2 Message-ID: Patches #403978, was updated on 2001-02-23 13:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403978&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Thomas Wouters Assigned to: Nobody/Anonymous Summary: config.h -> pyac_config.h change for OS2 Initial Comment: Companion to SF patch #103977, the OS2 part. To keep the size down, I didn't include pyac_config.h. If you want to test this patch, you'll have to rename config.h to pyac_config.h manually. ---------------------------------------------------------------------- Comment By: Thomas Wouters Date: 2001-02-28 01:01 Message: Logged In: YES user_id=34209 Postponed, it's too late to get it into 2.1 (I actually intended to mark it postponed from the start, but forgot to.) The companion patch is now numbered '#403977', by the way. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403978&group_id=5470 From nobody@sourceforge.net Wed Feb 28 09:07:39 2001 From: nobody@sourceforge.net (nobody) Date: Wed, 28 Feb 2001 01:07:39 -0800 Subject: [Patches] [ python-Patches-403977 ] Rename config.h to pyac_config.h, per SF bug #131774 Message-ID: Patches #403977, was updated on 2001-02-23 13:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Thomas Wouters Assigned to: Guido van Rossum Summary: Rename config.h to pyac_config.h, per SF bug #131774 Initial Comment: This patch fixes the UNIX and Windows builds to use 'pyac_config.h' instead of 'config.h', to avoid the problems summarized in SF bug #131774. It doesn't address the placing issue, however, because I believe it's intended to be like this. Most changes were done using a fairly intelligent shell+sed oneliner, but they should be correct. The Windows build *seems* correct, though I can't be sure. Someone will have to check ;) It is probably a good idea to remove 'config.h' before testing, to be sure I got all references. The UNIX build requires that autoconf is installed, and requires a 'autoheader ; autoconf' is done before running 'configure'. Removing config.h(.in) is also a good idea. I excluded the OS2 build files, and will be uploading those as a seperate patch to avoid making this one unreadable Though only two files are involved, they both list all dependencies for *all* files in its entirety, so the patch is quite large. If those files are auto-generated, someone please tell me so :-) I also didn't fix distutils, though it looks like it does need fixing. And I didn't do anything wrt. backwards compatibility. We should probably provide a config.h that just does #warning Warning: Use of Python-specific config.h is deprecated. Use pyac_config.h instead. #include The name is just my suggestion, changing it into something less acronymic would be no problem at all. I think 'pythonconfig.h' gives the wrong message though: the file isn't used to configure Python itself, after all ;) ---------------------------------------------------------------------- Comment By: Thomas Wouters Date: 2001-02-28 01:07 Message: Logged In: YES user_id=34209 I forgot to mention that I think this should be postponed until 2.2 or 2.1.1 anyway. It's not that big a change, but it's big enough to have weird and unsuspected sideffects. The bug is now numbered #231774, by the way. The problem is that 'config.h' is an oft-used name, and if you include it but have another directory with another project's config.h earlier in your include path, you get the wrong one. Similar if you intend to use the other one, but get this one. Leaving a fake config.h would only cause this patch to fix half of those problems, but only the first problem was reported in the bugreport :) The 'pyac_config' name comes from 'python', 'autoconf', 'config', and is IMHO sufficiently vague that it implies it is autogenerated :-) ---------------------------------------------------------------------- Comment By: Jeremy Hylton Date: 2001-02-27 23:14 Message: Logged In: YES user_id=31392 No time ---------------------------------------------------------------------- Comment By: Neil Schemenauer Date: 2001-02-27 13:53 Message: Logged In: YES user_id=35752 SF seems to have changed the bug ids! I can't find bug #131774. Unless there is a very good reason for the change I'm against it for 2.1. ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-02-27 13:05 Message: Logged In: YES user_id=11375 Regarding Distutils: I think the only actual *code* that would change is in distutils/sysconfig.py, in the get_config_h_filename() method. For backward compat., this method would probably have to check the Python version and use pyac_config.h if the version is 2.1 or greater. There are also lots of references to config.h in comments; we can change those or not, as desired. (I probably *would* change most of them.) ---------------------------------------------------------------------- Comment By: Tim Peters Date: 2001-02-27 12:48 Message: Logged In: YES user_id=31435 Pushed onto Jeremy. Jeremy, we want to do this much fiddling so late in the cycle? Thomas, don't worry about Windows. I only need a warning about that, and I've aware of this now (thanks!). Check in the new MS project files or don't, it's easy for me to fix 'em up regardless (indeed, it's not worth extra time to check it in advance). Note that "#warning" is not std C. I'm afraid you'll have to make it an #error. OTOH, if you leave a file *named* "config.h" in the distribution, it doesn't really address the bug report, right? BTW, I have no idea what "pyac" is supposed to bring to mind. Is that some Unixism? ---------------------------------------------------------------------- Comment By: Thomas Wouters Date: 2001-02-23 13:32 Message: Apologies for the large blurb in the 'details' section. I keep forgetting SF strips *all* whitespace from that block :( Assigning to Tim "The Windows Bot" Peters to test (and fix) the Windows build changes. Let me know if your patch still doesn't work and you want me to send you patched files instead, Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 From nobody@sourceforge.net Wed Feb 28 09:11:15 2001 From: nobody@sourceforge.net (nobody) Date: Wed, 28 Feb 2001 01:11:15 -0800 Subject: [Patches] [ python-Patches-404826 ] urllib2 enhancements Message-ID: Patches #404826, was updated on 2001-02-28 01:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404826&group_id=5470 Category: library Group: None Status: Open Priority: 3 Submitted By: Moshe Zadka Assigned to: Jeremy Hylton Summary: urllib2 enhancements Initial Comment: This are some enhancements and bug fixes to urllib2: * Documentation * Better proxy support, including authentication * HTTPS support ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404826&group_id=5470 From nobody@sourceforge.net Wed Feb 28 10:31:28 2001 From: nobody@sourceforge.net (nobody) Date: Wed, 28 Feb 2001 02:31:28 -0800 Subject: [Patches] [ python-Patches-404826 ] urllib2 enhancements Message-ID: Patches #404826, was updated on 2001-02-28 01:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404826&group_id=5470 Category: library Group: None Status: Open Priority: 3 Submitted By: Moshe Zadka Assigned to: Jeremy Hylton Summary: urllib2 enhancements Initial Comment: This are some enhancements and bug fixes to urllib2: * Documentation * Better proxy support, including authentication * HTTPS support ---------------------------------------------------------------------- Comment By: Moshe Zadka Date: 2001-02-28 02:31 Message: Logged In: YES user_id=11645 I'm having troubles attaching a file, I've put it up at http://www.lerner.co.il/~moshez/urllib2.py.patch (If anyone manages to attach it, I'll be greateful) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404826&group_id=5470 From nobody@sourceforge.net Wed Feb 28 15:42:04 2001 From: nobody@sourceforge.net (nobody) Date: Wed, 28 Feb 2001 07:42:04 -0800 Subject: [Patches] [ python-Patches-404680 ] Two more Cygwin standard module issues Message-ID: Patches #404680, was updated on 2001-02-27 12:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404680&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Jason Tishler Assigned to: A.M. Kuchling Summary: Two more Cygwin standard module issues Initial Comment: This patch disables the nis module and enables the dl module when building under Cygwin. Use patch -p0 Patches #404923, was updated on 2001-02-28 08:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404923&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Jason Tishler Assigned to: Nobody/Anonymous Summary: Cygwin termios module patch Initial Comment: The attached patch re-enables clean compilation of the termios module under Cygwin. Unfortunately this patch is Cygwin specific, so hopefully someone more knowledgeable with other platforms (e.g. IRIX) can generalize it to cover more platforms. To apply: $ cd Modules $ patch Patches #404924, was updated on 2001-02-28 08:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404924&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Jason Tishler Assigned to: Nobody/Anonymous Summary: Cygwin termios module patch Initial Comment: The attached patch re-enables clean compilation of the termios module under Cygwin. Unfortunately this patch is Cygwin specific, so hopefully someone more knowledgeable with other platforms (e.g. IRIX) can generalize it to cover more platforms. To apply: $ cd Modules $ patch Patches #404928, was updated on 2001-02-28 08:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404928&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Jason Tishler Assigned to: Nobody/Anonymous Summary: Support for next Cygwin gcc (2.95.2-8) Initial Comment: This (minor) patch prepares the Python source to cope with the next Cygwin gcc release (2.95.2-8) and later. Unfortunately, Cygwin gcc is becoming a "Unix bigot" meaning that it will no longer #def WINNT, _WIN32, etc. and look in the standard place for Windows header files. Cygwin packagers will also have to configure using the following: CC='gcc -mwin32' configure ... I will submit a patch to automate adding "-mwin32" after Cygwin gcc 2.95.2-8 is released. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404928&group_id=5470 From nobody@sourceforge.net Wed Feb 28 16:31:34 2001 From: nobody@sourceforge.net (nobody) Date: Wed, 28 Feb 2001 08:31:34 -0800 Subject: [Patches] [ python-Patches-404928 ] Support for next Cygwin gcc (2.95.2-8) Message-ID: Patches #404928, was updated on 2001-02-28 08:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404928&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Jason Tishler Assigned to: Nobody/Anonymous Summary: Support for next Cygwin gcc (2.95.2-8) Initial Comment: This (minor) patch prepares the Python source to cope with the next Cygwin gcc release (2.95.2-8) and later. Unfortunately, Cygwin gcc is becoming a "Unix bigot" meaning that it will no longer #def WINNT, _WIN32, etc. and look in the standard place for Windows header files. Cygwin packagers will also have to configure using the following: CC='gcc -mwin32' configure ... I will submit a patch to automate adding "-mwin32" after Cygwin gcc 2.95.2-8 is released. ---------------------------------------------------------------------- Comment By: Jason Tishler Date: 2001-02-28 08:31 Message: Logged In: YES user_id=86216 To apply: $ # cd to the top of your CVS working directory $ patch -p0 Patches #404928, was updated on 2001-02-28 08:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404928&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Jason Tishler Assigned to: Tim Peters Summary: Support for next Cygwin gcc (2.95.2-8) Initial Comment: This (minor) patch prepares the Python source to cope with the next Cygwin gcc release (2.95.2-8) and later. Unfortunately, Cygwin gcc is becoming a "Unix bigot" meaning that it will no longer #def WINNT, _WIN32, etc. and look in the standard place for Windows header files. Cygwin packagers will also have to configure using the following: CC='gcc -mwin32' configure ... I will submit a patch to automate adding "-mwin32" after Cygwin gcc 2.95.2-8 is released. ---------------------------------------------------------------------- Comment By: Tim Peters Date: 2001-02-28 08:34 Message: Logged In: YES user_id=31435 Assigned to me. ---------------------------------------------------------------------- Comment By: Jason Tishler Date: 2001-02-28 08:31 Message: Logged In: YES user_id=86216 To apply: $ # cd to the top of your CVS working directory $ patch -p0 Patches #404928, was updated on 2001-02-28 08:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404928&group_id=5470 Category: Build Group: None Status: Deleted Priority: 5 Submitted By: Jason Tishler Assigned to: Tim Peters Summary: Support for next Cygwin gcc (2.95.2-8) Initial Comment: This (minor) patch prepares the Python source to cope with the next Cygwin gcc release (2.95.2-8) and later. Unfortunately, Cygwin gcc is becoming a "Unix bigot" meaning that it will no longer #def WINNT, _WIN32, etc. and look in the standard place for Windows header files. Cygwin packagers will also have to configure using the following: CC='gcc -mwin32' configure ... I will submit a patch to automate adding "-mwin32" after Cygwin gcc 2.95.2-8 is released. ---------------------------------------------------------------------- Comment By: Tim Peters Date: 2001-02-28 08:46 Message: Logged In: YES user_id=31435 Checked in. _sre.c new revision: 2.53 gdbmmodule.c new revision: 2.29 exceptions.c new revision: 1.21 ---------------------------------------------------------------------- Comment By: Tim Peters Date: 2001-02-28 08:34 Message: Logged In: YES user_id=31435 Assigned to me. ---------------------------------------------------------------------- Comment By: Jason Tishler Date: 2001-02-28 08:31 Message: Logged In: YES user_id=86216 To apply: $ # cd to the top of your CVS working directory $ patch -p0 Patches #404923, was updated on 2001-02-28 08:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404923&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Jason Tishler Assigned to: David Ascher Summary: Cygwin termios module patch Initial Comment: The attached patch re-enables clean compilation of the termios module under Cygwin. Unfortunately this patch is Cygwin specific, so hopefully someone more knowledgeable with other platforms (e.g. IRIX) can generalize it to cover more platforms. To apply: $ cd Modules $ patch Patches #404924, was updated on 2001-02-28 08:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404924&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Jason Tishler Assigned to: Fred L. Drake, Jr. Summary: Cygwin termios module patch Initial Comment: The attached patch re-enables clean compilation of the termios module under Cygwin. Unfortunately this patch is Cygwin specific, so hopefully someone more knowledgeable with other platforms (e.g. IRIX) can generalize it to cover more platforms. To apply: $ cd Modules $ patch Patches #404924, was updated on 2001-02-28 08:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404924&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Jason Tishler Assigned to: Fred L. Drake, Jr. Summary: Cygwin termios module patch Initial Comment: The attached patch re-enables clean compilation of the termios module under Cygwin. Unfortunately this patch is Cygwin specific, so hopefully someone more knowledgeable with other platforms (e.g. IRIX) can generalize it to cover more platforms. To apply: $ cd Modules $ patch Patches #403276, was updated on 2001-01-16 13:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403276&group_id=5470 Category: library Group: None Status: Closed Priority: 5 Submitted By: Jens Quade Assigned to: Fred L. Drake, Jr. Summary: zipfile.py - file header size calculation fixed Initial Comment: In zipfile.py, the file header's size will be calculated by using header size information from the zip's central dir. But infozip creates file with different (and correct) header size information in the file header itself. The file header size should be calculated using the local file header's information. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. Date: 2001-02-28 09:59 Message: Logged In: YES user_id=3066 Wow! It's amazing how much understanding of the ZIP format is emboddied in this little patch. I've added comments to the source file that explain why it works this way. (And am I ever glad I added a reference to the file format spec to the documentation for zipfile!) Checked in a much(!) less cryptic version of this as Lib/zipfile.py revision 1.7. ---------------------------------------------------------------------- Comment By: Guido van Rossum Date: 2001-01-16 20:31 Message: Assigned to Fred. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403276&group_id=5470 From nobody@sourceforge.net Wed Feb 28 18:14:15 2001 From: nobody@sourceforge.net (nobody) Date: Wed, 28 Feb 2001 10:14:15 -0800 Subject: [Patches] [ python-Patches-404924 ] Cygwin termios module patch Message-ID: Patches #404924, was updated on 2001-02-28 08:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404924&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Jason Tishler Assigned to: Fred L. Drake, Jr. Summary: Cygwin termios module patch Initial Comment: The attached patch re-enables clean compilation of the termios module under Cygwin. Unfortunately this patch is Cygwin specific, so hopefully someone more knowledgeable with other platforms (e.g. IRIX) can generalize it to cover more platforms. To apply: $ cd Modules $ patch Patches #404923, was updated on 2001-02-28 08:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404923&group_id=5470 Category: Modules Group: None Status: Closed Priority: 5 Submitted By: Jason Tishler Assigned to: Fred L. Drake, Jr. Summary: Cygwin termios module patch Initial Comment: The attached patch re-enables clean compilation of the termios module under Cygwin. Unfortunately this patch is Cygwin specific, so hopefully someone more knowledgeable with other platforms (e.g. IRIX) can generalize it to cover more platforms. To apply: $ cd Modules $ patch Patches #404826, was updated on 2001-02-28 01:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404826&group_id=5470 Category: library Group: None Status: Open Priority: 3 Submitted By: Moshe Zadka Assigned to: Moshe Zadka Summary: urllib2 enhancements Initial Comment: This are some enhancements and bug fixes to urllib2: * Documentation * Better proxy support, including authentication * HTTPS support ---------------------------------------------------------------------- Comment By: Jeremy Hylton Date: 2001-02-28 12:00 Message: Logged In: YES user_id=31392 I did a cursory review of the patch and it looks good, particularly the documentation! I would prefer to see this included in the beta. Since there was no documentation before, I don't think there's any problem changing the code. ---------------------------------------------------------------------- Comment By: Moshe Zadka Date: 2001-02-28 02:31 Message: Logged In: YES user_id=11645 I'm having troubles attaching a file, I've put it up at http://www.lerner.co.il/~moshez/urllib2.py.patch (If anyone manages to attach it, I'll be greateful) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404826&group_id=5470 From nobody@sourceforge.net Wed Feb 28 20:17:59 2001 From: nobody@sourceforge.net (nobody) Date: Wed, 28 Feb 2001 12:17:59 -0800 Subject: [Patches] [ python-Patches-403948 ] uninstaller for bdist_wininst Message-ID: Patches #403948, was updated on 2001-02-22 08:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403948&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Thomas Heller Assigned to: A.M. Kuchling Summary: uninstaller for bdist_wininst Initial Comment: Uninstaller for bdist_wininst. Has been described fairly extensively in http://mail.python.org/pipermail/distutils-sig/2001-February/001991.html. This version differs from the posted beta-version in better error checking. The patch is not complete: distutils/command/bdist_wininst.py has to be regenerated after the C-code has been compiled. I'm requesting permission to check this in. ---------------------------------------------------------------------- Comment By: Thomas Heller Date: 2001-02-28 12:17 Message: Logged In: YES user_id=11105 Andrew, I'm undecided what to do. I have some improvements to the uninstaller in mind, which should be done before. I have, however, not the time to do it this week. Can we release a separate distutils version AFTER 2.1 beta 1? ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-02-27 11:01 Message: Logged In: YES user_id=11375 You have permission from me, though I can't really comment on the approach. No one else on python-dev seemed interested in inspecting it, and you're the Windows/Distutils installer expert, so go ahead. ---------------------------------------------------------------------- Comment By: Thomas Heller Date: 2001-02-22 08:28 Message: Uninstaller for bdist_wininst. Has been described detailed in http://mail.python.org/pipermail/distutils-sig/2001-February/001991.html. This version differs from the posted beta-version in better error checking. The patch is not complete: distutils/command/bdist_wininst.py has to be regenerated after the C-code has been compiled. I'm requesting permission to check this in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403948&group_id=5470 From nobody@sourceforge.net Wed Feb 28 20:27:19 2001 From: nobody@sourceforge.net (nobody) Date: Wed, 28 Feb 2001 12:27:19 -0800 Subject: [Patches] [ python-Patches-403948 ] uninstaller for bdist_wininst Message-ID: Patches #403948, was updated on 2001-02-22 08:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403948&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Thomas Heller Assigned to: A.M. Kuchling Summary: uninstaller for bdist_wininst Initial Comment: Uninstaller for bdist_wininst. Has been described fairly extensively in http://mail.python.org/pipermail/distutils-sig/2001-February/001991.html. This version differs from the posted beta-version in better error checking. The patch is not complete: distutils/command/bdist_wininst.py has to be regenerated after the C-code has been compiled. I'm requesting permission to check this in. ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-02-28 12:27 Message: Logged In: YES user_id=11375 Sure. There's also probably going to be a beta2, so it could be checked in for that release. ---------------------------------------------------------------------- Comment By: Thomas Heller Date: 2001-02-28 12:17 Message: Logged In: YES user_id=11105 Andrew, I'm undecided what to do. I have some improvements to the uninstaller in mind, which should be done before. I have, however, not the time to do it this week. Can we release a separate distutils version AFTER 2.1 beta 1? ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-02-27 11:01 Message: Logged In: YES user_id=11375 You have permission from me, though I can't really comment on the approach. No one else on python-dev seemed interested in inspecting it, and you're the Windows/Distutils installer expert, so go ahead. ---------------------------------------------------------------------- Comment By: Thomas Heller Date: 2001-02-22 08:28 Message: Uninstaller for bdist_wininst. Has been described detailed in http://mail.python.org/pipermail/distutils-sig/2001-February/001991.html. This version differs from the posted beta-version in better error checking. The patch is not complete: distutils/command/bdist_wininst.py has to be regenerated after the C-code has been compiled. I'm requesting permission to check this in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403948&group_id=5470 From nobody@sourceforge.net Wed Feb 28 20:37:55 2001 From: nobody@sourceforge.net (nobody) Date: Wed, 28 Feb 2001 12:37:55 -0800 Subject: [Patches] [ python-Patches-403948 ] uninstaller for bdist_wininst Message-ID: Patches #403948, was updated on 2001-02-22 08:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403948&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Thomas Heller Assigned to: Thomas Heller Summary: uninstaller for bdist_wininst Initial Comment: Uninstaller for bdist_wininst. Has been described fairly extensively in http://mail.python.org/pipermail/distutils-sig/2001-February/001991.html. This version differs from the posted beta-version in better error checking. The patch is not complete: distutils/command/bdist_wininst.py has to be regenerated after the C-code has been compiled. I'm requesting permission to check this in. ---------------------------------------------------------------------- Comment By: Thomas Heller Date: 2001-02-28 12:37 Message: Logged In: YES user_id=11105 Assigned back to myself for further work :-) ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-02-28 12:27 Message: Logged In: YES user_id=11375 Sure. There's also probably going to be a beta2, so it could be checked in for that release. ---------------------------------------------------------------------- Comment By: Thomas Heller Date: 2001-02-28 12:17 Message: Logged In: YES user_id=11105 Andrew, I'm undecided what to do. I have some improvements to the uninstaller in mind, which should be done before. I have, however, not the time to do it this week. Can we release a separate distutils version AFTER 2.1 beta 1? ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-02-27 11:01 Message: Logged In: YES user_id=11375 You have permission from me, though I can't really comment on the approach. No one else on python-dev seemed interested in inspecting it, and you're the Windows/Distutils installer expert, so go ahead. ---------------------------------------------------------------------- Comment By: Thomas Heller Date: 2001-02-22 08:28 Message: Uninstaller for bdist_wininst. Has been described detailed in http://mail.python.org/pipermail/distutils-sig/2001-February/001991.html. This version differs from the posted beta-version in better error checking. The patch is not complete: distutils/command/bdist_wininst.py has to be regenerated after the C-code has been compiled. I'm requesting permission to check this in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403948&group_id=5470 From nobody@sourceforge.net Wed Feb 28 21:57:24 2001 From: nobody@sourceforge.net (nobody) Date: Wed, 28 Feb 2001 13:57:24 -0800 Subject: [Patches] [ python-Patches-404997 ] Alternative to __future__ imports Message-ID: Patches #404997, was updated on 2001-02-28 13:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 Category: Parser/Compiler Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis Assigned to: Nobody/Anonymous Summary: Alternative to __future__ imports Initial Comment: This patch adds an alternative notation for selecting nested scopes on the module level, by means of a directive nested_scopes declaration. This is a declaration, and it may only appear at the "beginning" of a module. Even though it adds a keyword "directive", this is only a keyword if it appears as the first keyword in the file; as a result, def directive(): directive = 1 is still accepted (even without warning, but that could be changed if desired). The patch currently only accepts the directives that are also __future__ imports, although it can be extended to allow other things, e.g. directive source_encoding "latin-1" This is possible since the syntax allows an optional atom after the directive's name. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=404997&group_id=5470 From nobody@sourceforge.net Wed Feb 28 22:36:32 2001 From: nobody@sourceforge.net (nobody) Date: Wed, 28 Feb 2001 14:36:32 -0800 Subject: [Patches] [ python-Patches-405007 ] Script install fails for build in subdir Message-ID: Patches #405007, was updated on 2001-02-28 14:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405007&group_id=5470 Category: Build Group: None Status: Open Priority: 7 Submitted By: Jeremy Hylton Assigned to: A.M. Kuchling Summary: Script install fails for build in subdir Initial Comment: mkdir build cd build ../configure make [...] running build_scripts error: file 'Tools/scripts/pydoc' does not exist make: *** [sharedmods] Error 1 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405007&group_id=5470 From nobody@sourceforge.net Wed Feb 28 22:49:52 2001 From: nobody@sourceforge.net (nobody) Date: Wed, 28 Feb 2001 14:49:52 -0800 Subject: [Patches] [ python-Patches-405007 ] Script install fails for build in subdir Message-ID: Patches #405007, was updated on 2001-02-28 14:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405007&group_id=5470 Category: Build Group: None Status: Closed Priority: 7 Submitted By: Jeremy Hylton Assigned to: A.M. Kuchling Summary: Script install fails for build in subdir Initial Comment: mkdir build cd build ../configure make [...] running build_scripts error: file 'Tools/scripts/pydoc' does not exist make: *** [sharedmods] Error 1 ---------------------------------------------------------------------- Comment By: A.M. Kuchling Date: 2001-02-28 14:49 Message: Logged In: YES user_id=11375 Fixed in revision 1.34 of setup.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405007&group_id=5470 From nobody@sourceforge.net Wed Feb 28 23:09:47 2001 From: nobody@sourceforge.net (nobody) Date: Wed, 28 Feb 2001 15:09:47 -0800 Subject: [Patches] [ python-Patches-405016 ] small setup.py patch for VPATH build Message-ID: Patches #405016, was updated on 2001-02-28 15:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405016&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Markus F.X.J. Oberhumer Assigned to: Nobody/Anonymous Summary: small setup.py patch for VPATH build Initial Comment: This patch against the current CVS prepends `srcdir' to the `scripts' variable. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405016&group_id=5470 From nobody@sourceforge.net Wed Feb 28 23:11:54 2001 From: nobody@sourceforge.net (nobody) Date: Wed, 28 Feb 2001 15:11:54 -0800 Subject: [Patches] [ python-Patches-405016 ] small setup.py patch for VPATH build Message-ID: Patches #405016, was updated on 2001-02-28 15:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405016&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Markus F.X.J. Oberhumer Assigned to: Nobody/Anonymous Summary: small setup.py patch for VPATH build Initial Comment: This patch against the current CVS prepends `srcdir' to the `scripts' variable. ---------------------------------------------------------------------- Comment By: Markus F.X.J. Oberhumer Date: 2001-02-28 15:11 Message: Logged In: YES user_id=12151 (the new sourceforge code is confusing me...) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405016&group_id=5470 From nobody@sourceforge.net Wed Feb 28 23:13:15 2001 From: nobody@sourceforge.net (nobody) Date: Wed, 28 Feb 2001 15:13:15 -0800 Subject: [Patches] [ python-Patches-405016 ] small setup.py patch for VPATH build Message-ID: Patches #405016, was updated on 2001-02-28 15:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405016&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Markus F.X.J. Oberhumer Assigned to: Nobody/Anonymous Summary: small setup.py patch for VPATH build Initial Comment: This patch against the current CVS prepends `srcdir' to the `scripts' variable. ---------------------------------------------------------------------- Comment By: Markus F.X.J. Oberhumer Date: 2001-02-28 15:13 Message: Logged In: YES user_id=12151 Index: dist/src/setup.py =================================================================== RCS file: /cvsroot/python/python/dist/src/setup.py,v retrieving revision 1.33 diff -r1.33 setup.py 597a598 > (srcdir,) = sysconfig.get_config_vars('srcdir') 606c607 < scripts = ['Tools/scripts/pydoc'] --- > scripts = [os.path.join(srcdir, 'Tools/scripts/pydoc')] ---------------------------------------------------------------------- Comment By: Markus F.X.J. Oberhumer Date: 2001-02-28 15:11 Message: Logged In: YES user_id=12151 (the new sourceforge code is confusing me...) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405016&group_id=5470