From noreply@sourceforge.net  Wed Nov  1 11:32:33 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 03:32:33 -0800
Subject: [Patches] [Patch #100938] [Draft] libpython as shared library (.so) on Linux
Message-ID: <200011011132.DAA20826@sf-web2.i.sourceforge.net>

Patch #100938 has been updated. 

Project: python
Category: None
Status: Open
Summary: [Draft] libpython as shared library (.so) on Linux

Follow-Ups:

Date: 2000-Jul-19 14:10
By: flight

Comment:
This is what it used in product to build libpython as shared library(.so) for Debian.

Note: This patch is not ready for inclusion in the upstream Python distribution. Anyway, I think this might be a start. The Python 1.5 executable in Debian GNU/Linux is built against a shared libpython1.5.so since April 1999, and I haven't yet heard about any problems.

Using a shared library should have an advantage if you're running multiple instances of Python (be it standalone interpreter or embedded applications).

-------------------------------------------------------

Date: 2000-Aug-15 10:52
By: tim_one

Comment:
Assigned to Barry because he's a Linux weenie.  Barry, if you think there's something here that should go into 2.0, please pursue it now, else change the status to Postponed.
-------------------------------------------------------

Date: 2000-Aug-16 00:40
By: moshez

Comment:
I suggest we postpone it. It isn't really complete (only works on real distributions <wink>), and the complete solution should work on all unices. If Tcl/Perl can do it, there is no reason Python can't -- and a half hearted solution isn't that good. flight, you should use this
for the Python in woody in the mean time -- I doubt woody
will be stable before Python 2.1 comes out, so 2.1 sounds
like a good timeframe to do it.
-------------------------------------------------------

Date: 2000-Aug-23 09:26
By: jhylton

Comment:
In the absence of anyone arguing for inclusion of this patch and a one-week idle period, it is postponed.
-------------------------------------------------------

Date: 2000-Oct-26 14:13
By: gvanrossum

Comment:
Let's give this to Jeremy instead, because he seems to know more about build issues. Jeremy, it would be good to look into getting this to work with your RPM suite. Flight's argument (has been used without complaints in Debian Python 1.5.2 since 1999) is good.
-------------------------------------------------------

Date: 2000-Nov-01 03:32
By: moshez

Comment:
I've had a look at the patch, and it seems it has
two orthogonal parts. One is adding the infrastructure
for compiling another version for the Python library, which can be more or less integrated as-is, and one is hard-coding the particular way, in Linux, of building shared objects. Since we discover how to build shared objects in the configure script anyway (otherwise we could not have built modules as shared objects), we should embed that information there, not the Linux flags.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100938&group_id=5470


From noreply@sourceforge.net  Wed Nov  1 12:14:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 04:14:44 -0800
Subject: [Patches] [Patch #101313] New builtin function doc
Message-ID: <200011011214.EAA14394@sf-web1.i.sourceforge.net>

Patch #101313 has been updated. 

Project: python
Category: library
Status: Open
Summary: New builtin function doc

Follow-Ups:

Date: 2000-Aug-26 11:36
By: twouters

Comment:
Someone (Vladimir, I think ?) was working on a help() function, which was a docstring-prettyprinter as well as helpful in many other ways. I also think doc() should only be defined in interactive mode, but that's personal.

-------------------------------------------------------

Date: 2000-Aug-27 02:13
By: moshez

Comment:
Assigned to Jeremy, so he can postpone it.
It's definitely not-for-2.0 stuff.
-------------------------------------------------------

Date: 2000-Aug-28 00:43
By: tim_one

Comment:
Postponed it as requested (why didn't you do that yourself?).  Left assigned to Jeremy for post-2.0 resurrection.
-------------------------------------------------------

Date: 2000-Nov-01 04:14
By: moshez

Comment:
I don't like the fact that it either returns a string or prints it. Furthermore, nobody needs the function to return a string in the builtins, IMHO.
My suggestion: have a function doc_translate in gettext.py, which does the translation, and have doc in the builtins (exactly like you did it, laziness and all) which does, basically, print doc_translate(obj)

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101313&group_id=5470


From noreply@sourceforge.net  Wed Nov  1 12:18:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 04:18:06 -0800
Subject: [Patches] [Patch #101320] Translate doc strings
Message-ID: <200011011218.EAA14427@sf-web1.i.sourceforge.net>

Patch #101320 has been updated. 

Project: python
Category: library
Status: Open
Summary: Translate doc strings

Follow-Ups:

Date: 2000-Aug-28 00:46
By: tim_one

Comment:
Assigned to Barry since it seems related to gettext.

-------------------------------------------------------

Date: 2000-Aug-30 12:38
By: gvanrossum

Comment:
Barry will comment on this and then postpone it.
-------------------------------------------------------

Date: 2000-Aug-31 14:22
By: bwarsaw

Comment:
We're postponing this patch for 2.0 for a couple of reasons. First, it seems that more discussion about exactly how to distribute translations of docstrings should take place on the i18n-sig.  Second, these files are fairly large so they probably shouldn't go into the core Python distribution, although some infrastructure is need to get these to translators, and back to end users.
-------------------------------------------------------

Date: 2000-Nov-01 04:18
By: moshez

Comment:
What is the relationship between this patch and 101313?
It seems to me both of them should be assigned to one person, because it seems to me that 101313 assumes a translation exists. Barry? Jeremy? 
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101320&group_id=5470


From noreply@sourceforge.net  Wed Nov  1 12:29:23 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 04:29:23 -0800
Subject: [Patches] [Patch #101352] PyOS_StackCheck for Unix
Message-ID: <200011011229.EAA15905@sf-web3.vaspecialprojects.com>

Patch #101352 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: PyOS_StackCheck for Unix

Follow-Ups:

Date: 2000-Aug-30 02:15
By: lemburg

Comment:
Since getrlimit() might not return useful results on all Unix
platforms, I'd suggest adding a test to the configure script
(the test should check whether getrlimit() returns a non-zero
value for the stack limit).

Also, due to the added call overhead, I'd suggest raising the
modulo value in ceval's hook to call PyOS_CheckStack():

#ifdef USE_STACKCHECK
        if (tstate->recursion_depth%10 == 0 && PyOS_CheckStack()) {
                PyErr_SetString(PyExc_MemoryError, "Stack overflow");
                return NULL;
        }
#endif

to about 100. 

That way the stack check will most likely only be
triggered by programs which actually use recursion, rather than
those which only use shallow function call nesting (10 seems
to low w/r to these).

-------------------------------------------------------

Date: 2000-Aug-30 05:31
By: loewis

Comment:
IMO,  testing could be deferred until some system shows up that indeed returns
zero. As for the frequency of the OS call, it may be useful to cache the result
of getrlimit, on a per-thread basis. That won't catch changes done by the
script itself, or from the outside, but if people do such things, they need to
be careful, anyway.
-------------------------------------------------------

Date: 2000-Aug-30 12:52
By: gvanrossum

Comment:
Given to Jeremy. We don't think we can get PyOS_CheckStack to work reliably and efficiently on Unix. Instead, we're going to make the recursion limit a user settable thing (sys.{set,get}recursionlimit) with a small default, e.g. 1000.
-------------------------------------------------------

Date: 2000-Aug-30 18:33
By: jhylton

Comment:
Postponed, because it is sufficiently complex to fall subject to the feature freeze for 2.0b1.

-------------------------------------------------------

Date: 2000-Nov-01 04:29
By: moshez

Comment:
Two things:

1) For GOD's sake, don't use #if inside #else: #elif
   makes a mess not worse then it has to be
2) I'm not sure this patch is very "honest": Py_Initialize() can be called from a call hierarchy either shallower or deaper then, say, Py_CallObject(..) 
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101352&group_id=5470


From noreply@sourceforge.net  Wed Nov  1 12:45:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 04:45:05 -0800
Subject: [Patches] [Patch #102170] move getopt() to Py_GetOpt() and use it unconditionally
Message-ID: <200011011245.EAA22176@sf-web2.i.sourceforge.net>

Patch #102170 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: move getopt() to Py_GetOpt() and use it unconditionally

Follow-Ups:

Date: 2000-Oct-30 09:48
By: twouters

Comment:
This patch attempts to do what Tim suggested in the python-dev thread about getopt()'s prototype and the difficulties of it. the 'getopt' implementation as provided in Python/getopt.c is renamed to Py_GetOpt(), the exported variables 'opterr', 'optind' and 'optarg' are prefixed with Py_, and all use in the Python sourcetree is adjusted.

The patch is missing the 'pygetopt.h' include file, though :P I'll resubmit a proper patch later. 

There are a couple of issues still open: the name of the getopt.c file, its use of 'fprintf(stderr, ... )', its license, documentation (which this patch lacks) and whether this Py_GetOpt should be an officially exported API at all.


-------------------------------------------------------

Date: 2000-Oct-30 10:08
By: twouters

Comment:
New patch, includes pygetopt.h by hack. (not sure if it patches cleanly, but it's not that exciting a file anyway :) Assigned to.... (spin wheel... Guido. no. spin wheel... Barry. no. spin wheel... Moshe. dang. spin wheel... *nudge*. Ah, finally,) Tim.


-------------------------------------------------------

Date: 2000-Nov-01 04:45
By: moshez

Comment:
Well, as the one who almost got the assignment <wink>, I'm +1 on it. Using native getopt is more trouble then it's worth, especially considering the fact that we've had an implementation of our own for so long. So here's for reinventing the wheel! <wink>
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102170&group_id=5470


From noreply@sourceforge.net  Wed Nov  1 15:25:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 07:25:29 -0800
Subject: [Patches] [Patch #101320] Translate doc strings
Message-ID: <200011011525.HAA18636@sf-web3.vaspecialprojects.com>

Patch #101320 has been updated. 

Project: python
Category: library
Status: Rejected
Summary: Translate doc strings

Follow-Ups:

Date: 2000-Aug-28 00:46
By: tim_one

Comment:
Assigned to Barry since it seems related to gettext.

-------------------------------------------------------

Date: 2000-Aug-30 12:38
By: gvanrossum

Comment:
Barry will comment on this and then postpone it.
-------------------------------------------------------

Date: 2000-Aug-31 14:22
By: bwarsaw

Comment:
We're postponing this patch for 2.0 for a couple of reasons. First, it seems that more discussion about exactly how to distribute translations of docstrings should take place on the i18n-sig.  Second, these files are fairly large so they probably shouldn't go into the core Python distribution, although some infrastructure is need to get these to translators, and back to end users.
-------------------------------------------------------

Date: 2000-Nov-01 04:18
By: moshez

Comment:
What is the relationship between this patch and 101313?
It seems to me both of them should be assigned to one person, because it seems to me that 101313 assumes a translation exists. Barry? Jeremy? 
-------------------------------------------------------

Date: 2000-Nov-01 07:25
By: loewis

Comment:
I withdraw this patch; the message catalog has been checked-in as nondist/i18n/python.pot, and submitted to the GNU translation project. Translation catalogs should be added once they become available.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101320&group_id=5470


From noreply@sourceforge.net  Wed Nov  1 18:28:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 10:28:57 -0800
Subject: [Patches] [Patch #102068] fix for bug #117402 (repr of array)
Message-ID: <200011011828.KAA19190@sf-web1.i.sourceforge.net>

Patch #102068 has been updated. 

Project: python
Category: Modules
Status: Open
Summary: fix for bug #117402 (repr of array)

Follow-Ups:

Date: 2000-Oct-22 09:51
By: mwh

Comment:
before:
>>> import array
>>> array.array('c',"cd")
array('c', 'cd')
>>> repr(_)
Segmentation fault (core dumped)

after:
>>> import array
>>> array.array('c',"dd")
array('c', 'dd')
>>> `_`
"array('c', 'dd')"

Fixes bug #117402, which was introduced in revision 2.51.
-------------------------------------------------------

Date: 2000-Oct-23 06:22
By: nascheme

Comment:
A test case should be added to make sure str() and repr() work on arrays.
-------------------------------------------------------

Date: 2000-Oct-23 08:36
By: fdrake

Comment:
Assigned to Tim since the bug is already assigned to him.
-------------------------------------------------------

Date: 2000-Nov-01 10:28
By: mwh

Comment:
oop!  I wrote a simple test a while back , but sf's web pages were down, so I forgot to upload it...
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102068&group_id=5470


From noreply@sourceforge.net  Wed Nov  1 18:28:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 10:28:57 -0800
Subject: [Patches] [Patch #102068] fix for bug #117402 (repr of array)
Message-ID: <200011011828.KAA19187@sf-web1.i.sourceforge.net>

Patch #102068 has been updated. 

Project: python
Category: Modules
Status: Open
Summary: fix for bug #117402 (repr of array)

Follow-Ups:

Date: 2000-Oct-22 09:51
By: mwh

Comment:
before:
>>> import array
>>> array.array('c',"cd")
array('c', 'cd')
>>> repr(_)
Segmentation fault (core dumped)

after:
>>> import array
>>> array.array('c',"dd")
array('c', 'dd')
>>> `_`
"array('c', 'dd')"

Fixes bug #117402, which was introduced in revision 2.51.
-------------------------------------------------------

Date: 2000-Oct-23 06:22
By: nascheme

Comment:
A test case should be added to make sure str() and repr() work on arrays.
-------------------------------------------------------

Date: 2000-Oct-23 08:36
By: fdrake

Comment:
Assigned to Tim since the bug is already assigned to him.
-------------------------------------------------------

Date: 2000-Nov-01 10:28
By: mwh

Comment:
oop!  I wrote a simple test a while back , but sf's web pages were down, so I forgot to upload it...
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102068&group_id=5470


From noreply@sourceforge.net  Wed Nov  1 21:15:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 13:15:21 -0800
Subject: [Patches] [Patch #102208] Allow jython to use StringIO.py without an errno module.
Message-ID: <200011012115.NAA23875@sf-web3.vaspecialprojects.com>

Patch #102208 has been updated. 

Project: python
Category: library
Status: Open
Summary: Allow jython to use StringIO.py without an errno module.

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102208&group_id=5470


From noreply@sourceforge.net  Thu Nov  2 05:00:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 1 Nov 2000 21:00:43 -0800
Subject: [Patches] [Patch #102170] move getopt() to Py_GetOpt() and use it unconditionally
Message-ID: <200011020500.VAA11872@sf-web2.i.sourceforge.net>

Patch #102170 has been updated. 

Project: python
Category: core (C code)
Status: Accepted
Summary: move getopt() to Py_GetOpt() and use it unconditionally

Follow-Ups:

Date: 2000-Oct-30 09:48
By: twouters

Comment:
This patch attempts to do what Tim suggested in the python-dev thread about getopt()'s prototype and the difficulties of it. the 'getopt' implementation as provided in Python/getopt.c is renamed to Py_GetOpt(), the exported variables 'opterr', 'optind' and 'optarg' are prefixed with Py_, and all use in the Python sourcetree is adjusted.

The patch is missing the 'pygetopt.h' include file, though :P I'll resubmit a proper patch later. 

There are a couple of issues still open: the name of the getopt.c file, its use of 'fprintf(stderr, ... )', its license, documentation (which this patch lacks) and whether this Py_GetOpt should be an officially exported API at all.


-------------------------------------------------------

Date: 2000-Oct-30 10:08
By: twouters

Comment:
New patch, includes pygetopt.h by hack. (not sure if it patches cleanly, but it's not that exciting a file anyway :) Assigned to.... (spin wheel... Guido. no. spin wheel... Barry. no. spin wheel... Moshe. dang. spin wheel... *nudge*. Ah, finally,) Tim.


-------------------------------------------------------

Date: 2000-Nov-01 04:45
By: moshez

Comment:
Well, as the one who almost got the assignment <wink>, I'm +1 on it. Using native getopt is more trouble then it's worth, especially considering the fact that we've had an implementation of our own for so long. So here's for reinventing the wheel! <wink>
-------------------------------------------------------

Date: 2000-Nov-01 21:00
By: tim_one

Comment:
Accepted and assigned back to Thomas.

Guido approved of this "in theory" before, so go for it!  I would like to see the function renamed to _PyOS_GetOpt(), because we always stick "OS" in the name of an OS substitute function, and the leading underscore keeps it out of the public API (thus answering one of your open issues:  if people clamor for a public getopt replacement, we can add that later; but if we make it public from the start, it can never go away).

About the license, we can't change it, but it certainly allows us to modify the code and distribute your changes.  Under copyright law, I don't believe the changes are substantial enough that we could legitimately claim a new copyright for the new version.  So the whole license thing seems a non-issue to me.

Documentation?  If it's in the private API, it doesn't need any <wink>.

fprintf(stderr, ...)?  Sure.  Python barely exists by the time this code is called, and there's really nothing better to do (note that Py_Main calls fprintf(stderr, ...) itself later in a couple of other startup error cases).
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102170&group_id=5470


From noreply@sourceforge.net  Thu Nov  2 11:06:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 03:06:51 -0800
Subject: [Patches] [Patch #102223] --default-domain fix for Tools/i18n/pygettext.py
Message-ID: <200011021106.DAA18906@sf-web2.i.sourceforge.net>

Patch #102223 has been updated. 

Project: python
Category: demos and tools
Status: Open
Summary: --default-domain fix for Tools/i18n/pygettext.py

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102223&group_id=5470


From noreply@sourceforge.net  Thu Nov  2 14:27:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 06:27:16 -0800
Subject: [Patches] [Patch #102226] freeze/modulefinder.py should use _winreg, not win32api
Message-ID: <200011021427.GAA04641@sf-web3.vaspecialprojects.com>

Patch #102226 has been updated. 

Project: python
Category: demos and tools
Status: Open
Summary: freeze/modulefinder.py should use _winreg, not win32api

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102226&group_id=5470


From noreply@sourceforge.net  Thu Nov  2 16:56:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 08:56:08 -0800
Subject: [Patches] [Patch #102227] make BUILD_MAP use it's argument
Message-ID: <200011021656.IAA27375@sf-web2.i.sourceforge.net>

Patch #102227 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: make BUILD_MAP use it's argument

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102227&group_id=5470


From noreply@sourceforge.net  Thu Nov  2 17:00:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 09:00:12 -0800
Subject: [Patches] [Patch #102227] make BUILD_MAP use it's argument
Message-ID: <200011021700.JAA27542@sf-web2.i.sourceforge.net>

Patch #102227 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: make BUILD_MAP use it's argument

Follow-Ups:

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...
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102227&group_id=5470


From noreply@sourceforge.net  Thu Nov  2 17:00:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 09:00:12 -0800
Subject: [Patches] [Patch #102227] make BUILD_MAP use it's argument
Message-ID: <200011021700.JAA27545@sf-web2.i.sourceforge.net>

Patch #102227 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: make BUILD_MAP use it's argument

Follow-Ups:

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...
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102227&group_id=5470


From noreply@sourceforge.net  Thu Nov  2 17:36:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 09:36:26 -0800
Subject: [Patches] [Patch #102229] a better robotparser.py module
Message-ID: <200011021736.JAA04518@sf-web1.i.sourceforge.net>

Patch #102229 has been updated. 

Project: python
Category: Modules
Status: Open
Summary: a better robotparser.py module

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102229&group_id=5470


From noreply@sourceforge.net  Thu Nov  2 17:40:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 09:40:27 -0800
Subject: [Patches] [Patch #102229] a better robotparser.py module
Message-ID: <200011021740.JAA04566@sf-web1.i.sourceforge.net>

Patch #102229 has been updated. 

Project: python
Category: Modules
Status: Open
Summary: a better robotparser.py module

Follow-Ups:

Date: 2000-Nov-02 09:40
By: calvin

Comment:
I have written a new RobotParser module 'robotparser2.py'.

This module is

o backward compatible with the old one

o makes correct useragent matching (is buggy in
  robotparser.py)

o strips comments correctly (is buggy in robotparser.py)

o uses httplib instead of urllib.urlopen() to catch HTTP
  connect errors correctly (is buggy in robotparser.py)
  
o implements not only the draft at

http://info.webcrawler.com/mak/projects/robots/norobots.html
  but also the new one at
  http://info.webcrawler.com/mak/projects/robots/norobots-rfc.html


Bastian Kleineidam

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102229&group_id=5470


From noreply@sourceforge.net  Thu Nov  2 17:40:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 09:40:27 -0800
Subject: [Patches] [Patch #102229] a better robotparser.py module
Message-ID: <200011021740.JAA04569@sf-web1.i.sourceforge.net>

Patch #102229 has been updated. 

Project: python
Category: Modules
Status: Open
Summary: a better robotparser.py module

Follow-Ups:

Date: 2000-Nov-02 09:40
By: calvin

Comment:
I have written a new RobotParser module 'robotparser2.py'.

This module is

o backward compatible with the old one

o makes correct useragent matching (is buggy in
  robotparser.py)

o strips comments correctly (is buggy in robotparser.py)

o uses httplib instead of urllib.urlopen() to catch HTTP
  connect errors correctly (is buggy in robotparser.py)
  
o implements not only the draft at

http://info.webcrawler.com/mak/projects/robots/norobots.html
  but also the new one at
  http://info.webcrawler.com/mak/projects/robots/norobots-rfc.html


Bastian Kleineidam

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102229&group_id=5470


From noreply@sourceforge.net  Thu Nov  2 18:12:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 10:12:57 -0800
Subject: [Patches] [Patch #102231] Dynamic loading on Solaris does not work (bug #121121)
Message-ID: <200011021812.KAA29320@sf-web2.i.sourceforge.net>

Patch #102231 has been updated. 

Project: python
Category: Build
Status: Open
Summary: Dynamic loading on Solaris does not work (bug #121121)

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102231&group_id=5470


From noreply@sourceforge.net  Thu Nov  2 18:23:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 10:23:59 -0800
Subject: [Patches] [Patch #102169] Additional docs for __iadd__ hooks
Message-ID: <200011021823.KAA29580@sf-web2.i.sourceforge.net>

Patch #102169 has been updated. 

Project: python
Category: documentation
Status: Open
Summary: Additional docs for __iadd__ hooks

Follow-Ups:

Date: 2000-Oct-30 05:02
By: twouters

Comment:
'Fix' for 'bug' #117178: add description of the in-place hooks to the Reference manual, section 3.3. Untested TeX code, but likely to be correct (mostly copy-and-paste work.)

-------------------------------------------------------

Date: 2000-Nov-02 10:23
By: fdrake

Comment:
You really need to provide more specific description of how these methods are supposed to behave (about returning self meaning in-place operation occurred, a new object means replace self with new object (in context), etc.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102169&group_id=5470


From noreply@sourceforge.net  Thu Nov  2 18:37:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 10:37:26 -0800
Subject: [Patches] [Patch #102185] reclaim fds in smtplib.py on connect failures
Message-ID: <200011021837.KAA05446@sf-web1.i.sourceforge.net>

Patch #102185 has been updated. 

Project: python
Category: library
Status: Accepted
Summary: reclaim fds in smtplib.py on connect failures

Follow-Ups:

Date: 2000-Oct-31 08:38
By: bwarsaw

Comment:
This patch fixes bug #119883 where failures in SMTP.connect() during the socket.connect() will leak file descriptors.
-------------------------------------------------------

Date: 2000-Nov-02 10:37
By: fdrake

Comment:
Please check in and close the bug.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102185&group_id=5470


From noreply@sourceforge.net  Thu Nov  2 19:14:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 11:14:37 -0800
Subject: [Patches] [Patch #102229] a better robotparser.py module
Message-ID: <200011021914.LAA06015@sf-web1.i.sourceforge.net>

Patch #102229 has been updated. 

Project: python
Category: Modules
Status: Open
Summary: a better robotparser.py module

Follow-Ups:

Date: 2000-Nov-02 09:40
By: calvin

Comment:
I have written a new RobotParser module 'robotparser2.py'.

This module is

o backward compatible with the old one

o makes correct useragent matching (is buggy in
  robotparser.py)

o strips comments correctly (is buggy in robotparser.py)

o uses httplib instead of urllib.urlopen() to catch HTTP
  connect errors correctly (is buggy in robotparser.py)
  
o implements not only the draft at

http://info.webcrawler.com/mak/projects/robots/norobots.html
  but also the new one at
  http://info.webcrawler.com/mak/projects/robots/norobots-rfc.html


Bastian Kleineidam

-------------------------------------------------------

Date: 2000-Nov-02 11:14
By: gvanrossum

Comment:
Skip, can you comment on this?  
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102229&group_id=5470


From noreply@sourceforge.net  Fri Nov  3 02:30:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 18:30:00 -0800
Subject: [Patches] [Patch #102208] Allow jython to use StringIO.py without an errno module.
Message-ID: <200011030230.SAA14792@sf-web3.vaspecialprojects.com>

Patch #102208 has been updated. 

Project: python
Category: library
Status: Open
Summary: Allow jython to use StringIO.py without an errno module.

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102208&group_id=5470


From noreply@sourceforge.net  Fri Nov  3 02:30:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 18:30:00 -0800
Subject: [Patches] [Patch #102223] --default-domain fix for Tools/i18n/pygettext.py
Message-ID: <200011030230.SAA14795@sf-web3.vaspecialprojects.com>

Patch #102223 has been updated. 

Project: python
Category: demos and tools
Status: Open
Summary: --default-domain fix for Tools/i18n/pygettext.py

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102223&group_id=5470


From noreply@sourceforge.net  Fri Nov  3 02:32:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 18:32:22 -0800
Subject: [Patches] [Patch #102227] make BUILD_MAP use it's argument
Message-ID: <200011030232.SAA14833@sf-web3.vaspecialprojects.com>

Patch #102227 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: make BUILD_MAP use it's argument

Follow-Ups:

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...
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102227&group_id=5470


From noreply@sourceforge.net  Fri Nov  3 02:33:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 18:33:10 -0800
Subject: [Patches] [Patch #102226] freeze/modulefinder.py should use _winreg, not win32api
Message-ID: <200011030233.SAA14852@sf-web3.vaspecialprojects.com>

Patch #102226 has been updated. 

Project: python
Category: demos and tools
Status: Open
Summary: freeze/modulefinder.py should use _winreg, not win32api

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102226&group_id=5470


From noreply@sourceforge.net  Fri Nov  3 02:34:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 18:34:46 -0800
Subject: [Patches] [Patch #102231] Dynamic loading on Solaris does not work (bug #121121)
Message-ID: <200011030234.SAA14872@sf-web3.vaspecialprojects.com>

Patch #102231 has been updated. 

Project: python
Category: Build
Status: Open
Summary: Dynamic loading on Solaris does not work (bug #121121)

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102231&group_id=5470


From noreply@sourceforge.net  Fri Nov  3 02:35:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 2 Nov 2000 18:35:31 -0800
Subject: [Patches] [Patch #101022] Removal of SET_LINENO (experimental)
Message-ID: <200011030235.SAA14893@sf-web3.vaspecialprojects.com>

Patch #101022 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: Removal of SET_LINENO (experimental)

Follow-Ups:

Date: 2000-Jul-30 16:12
By: marangoz

Comment:
For testing, as discussed on python-dev. For a gentle summary, see:
http://www.python.org/pipermail/python-dev/2000-July/014364.html

-------------------------------------------------------

Date: 2000-Jul-30 18:16
By: marangoz

Comment:
A nit: inline the argfetch in CALL_TRACE and goto the switch,
instead of jumping to get_oparg which splits the sequence
[fetch opcode, fetch oparg] -- this can slow things down.

-------------------------------------------------------

Date: 2000-Jul-31 06:40
By: gvanrossum

Comment:
Status set to postponed to indicate that this is still experimental.
-------------------------------------------------------

Date: 2000-Jul-31 07:57
By: marangoz

Comment:
Another rewrite, making this whole strategy b/w compatible according to
the 1st incompatibility point a) described in: http://www.python.org/pipermail/python-dev/2000-July/014364.html

Changes:

1. f.f_lineno is computed and updated on f_lineno attribute requests for
   f, given f.f_lasti. Correctness is ensured because f.f_lasti is updated
   on *all* attribute accesses (in LOAD_ATTR in the main loop).

2. The standard setup does not generate SET_LINENO, but uses
   co_lnotab for computing the source line number (e.g. tracebacks)
   This is equivalent to the actual "python -O".

3. With "python -d", we fall back to the current version of the
   interpreter (with SET_LINENO) thus making it easy to test whether
   this patch fully replaces SET_LINENO's behavior.
   (modulo f->f_lineno accesses from legacy C code, but this is insane).

IMO, this version already worths the pain to be truly tested and improved.

One improvement is to define a nicer public C API for breakpoints:
 - PyCode_SetBreakPointAtLine(line)
 - PyCode_SetBreakPointAtAddr(addr)
or similar, which would install a CALL_TRACE opcode in the appropriate
location of the copy of co_code.

Another idea is to avoid duplicating the entire co_code just for storing
the CALL_TRACE opcodes. We can store them in the original and keep
a table of breakpoints. Setting the breakpoints would occur whenever
the sys.settrace hook is set.
-------------------------------------------------------

Date: 2000-Jul-31 10:50
By: marangoz

Comment:
A last tiny fix of the SET_LINENO opcode for better b/w compatibility.
Stopping here and entering standby mode for reactions & feedback.

PS: the last idea about not duplicating co_code and tweaking the
original with CALL_TRACE is a bad one. I remember Guido being
against it because co_code could be used elsewhere (copied, written
to disk, whatever) and he's right! Better operate on an internal copy
created in ceval.
-------------------------------------------------------

Date: 2000-Aug-03 12:22
By: marangoz

Comment:
Fix missing DECREF on error condition in start_tracing()
+ some renaming.
-------------------------------------------------------

Date: 2000-Oct-25 13:56
By: gvanrossum

Comment:
Vladimir, are you there?

The patch doesn't apply cleanly to the current CVS tree any more...
-------------------------------------------------------

Date: 2000-Oct-25 17:42
By: marangoz

Comment:
noreply@sourceforge.net wrote:
>
> Date: 2000-Oct-25 13:56
> By: gvanrossum
> 
> Comment:
> Vladimir, are you there?

So-so :) I'm a moving target, checking my mail occasionally these days.
Luckily, today is one of these days.

> 
> The patch doesn't apply cleanly to the current CVS tree any more...

Ah, this one's easy. Here's an update relative to 2.0 final, not CVS.
I got some r/w access error trying to update my CVS copy from SF
that I have no time to investigate right now... The Web interface still
works though :)
-------------------------------------------------------

Date: 2000-Oct-27 04:08
By: marangoz

Comment:
Oops, the last patch update does not contain the f.f_lineno
computation in frame_getattr. This is necessary, cf. the
following messages:
http://www.python.org/pipermail/python-dev/2000-July/014395.html
http://www.python.org/pipermail/python-dev/2000-July/014401.html

Patch assigned to Guido, for review or further assignment.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101022&group_id=5470


From noreply@sourceforge.net  Sun Nov  5 17:49:36 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 5 Nov 2000 09:49:36 -0800
Subject: [Patches] [Patch #102278] add tparm to _cursesmodule
Message-ID: <200011051749.JAA24661@sf-web2.i.sourceforge.net>

Patch #102278 has been updated. 

Project: python
Category: Modules
Status: Open
Summary: add tparm to _cursesmodule

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102278&group_id=5470


From noreply@sourceforge.net  Sun Nov  5 18:19:33 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 5 Nov 2000 10:19:33 -0800
Subject: [Patches] [Patch #102278] add tparm to _cursesmodule
Message-ID: <200011051819.KAA28492@sf-web3.vaspecialprojects.com>

Patch #102278 has been updated. 

Project: python
Category: Modules
Status: Open
Summary: add tparm to _cursesmodule

Follow-Ups:

Date: 2000-Nov-05 10:19
By: mwh

Comment:
This patch adds the "tparm" function to the curses module.  No more,
no less (and this new patch also updates the docs).

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102278&group_id=5470


From noreply@sourceforge.net  Sun Nov  5 18:19:33 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 5 Nov 2000 10:19:33 -0800
Subject: [Patches] [Patch #102278] add tparm to _cursesmodule
Message-ID: <200011051819.KAA28489@sf-web3.vaspecialprojects.com>

Patch #102278 has been updated. 

Project: python
Category: Modules
Status: Open
Summary: add tparm to _cursesmodule

Follow-Ups:

Date: 2000-Nov-05 10:19
By: mwh

Comment:
This patch adds the "tparm" function to the curses module.  No more,
no less (and this new patch also updates the docs).

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102278&group_id=5470


From noreply@sourceforge.net  Sun Nov  5 18:26:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 5 Nov 2000 10:26:11 -0800
Subject: [Patches] [Patch #102278] add tparm to _cursesmodule
Message-ID: <200011051826.KAA28582@sf-web3.vaspecialprojects.com>

Patch #102278 has been updated. 

Project: python
Category: Modules
Status: Open
Summary: add tparm to _cursesmodule

Follow-Ups:

Date: 2000-Nov-05 10:19
By: mwh

Comment:
This patch adds the "tparm" function to the curses module.  No more,
no less (and this new patch also updates the docs).

-------------------------------------------------------

Date: 2000-Nov-05 10:26
By: mwh

Comment:
fix a warning.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102278&group_id=5470


From noreply@sourceforge.net  Sun Nov  5 18:26:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 5 Nov 2000 10:26:11 -0800
Subject: [Patches] [Patch #102278] add tparm to _cursesmodule
Message-ID: <200011051826.KAA28579@sf-web3.vaspecialprojects.com>

Patch #102278 has been updated. 

Project: python
Category: Modules
Status: Open
Summary: add tparm to _cursesmodule

Follow-Ups:

Date: 2000-Nov-05 10:19
By: mwh

Comment:
This patch adds the "tparm" function to the curses module.  No more,
no less (and this new patch also updates the docs).

-------------------------------------------------------

Date: 2000-Nov-05 10:26
By: mwh

Comment:
fix a warning.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102278&group_id=5470


From noreply@sourceforge.net  Mon Nov  6 02:52:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 5 Nov 2000 18:52:48 -0800
Subject: [Patches] [Patch #102226] freeze/modulefinder.py should use _winreg, not win32api
Message-ID: <200011060252.SAA02319@sf-web3.vaspecialprojects.com>

Patch #102226 has been updated. 

Project: python
Category: demos and tools
Status: Closed
Summary: freeze/modulefinder.py should use _winreg, not win32api

Follow-Ups:

Date: 2000-Nov-05 18:52
By: mhammond

Comment:
Applied in rev 1.15 of modulefinder.py
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102226&group_id=5470


From noreply@sourceforge.net  Tue Nov  7 03:35:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 6 Nov 2000 19:35:39 -0800
Subject: [Patches] [Patch #102278] add tparm to _cursesmodule
Message-ID: <200011070335.TAA21930@sf-web1.i.sourceforge.net>

Patch #102278 has been updated. 

Project: python
Category: Modules
Status: Closed
Summary: add tparm to _cursesmodule

Follow-Ups:

Date: 2000-Nov-05 10:19
By: mwh

Comment:
This patch adds the "tparm" function to the curses module.  No more,
no less (and this new patch also updates the docs).

-------------------------------------------------------

Date: 2000-Nov-05 10:26
By: mwh

Comment:
fix a warning.
-------------------------------------------------------

Date: 2000-Nov-06 19:35
By: akuchling

Comment:
Applied.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102278&group_id=5470


From noreply@sourceforge.net  Tue Nov  7 19:16:15 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 7 Nov 2000 11:16:15 -0800
Subject: [Patches] [Patch #102313] shar output support
Message-ID: <200011071916.LAA02548@sf-web3.vaspecialprojects.com>

Patch #102313 has been updated. 

Project: python
Category: distutils
Status: Open
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 Nov  7 19:16:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 7 Nov 2000 11:16:52 -0800
Subject: [Patches] [Patch #102313] shar output support
Message-ID: <200011071916.LAA02555@sf-web3.vaspecialprojects.com>

Patch #102313 has been updated. 

Project: python
Category: distutils
Status: Open
Summary: shar output support

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102313&group_id=5470


From noreply@sourceforge.net  Wed Nov  8 22:23:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 8 Nov 2000 14:23:08 -0800
Subject: [Patches] [Patch #102185] reclaim fds in smtplib.py on connect failures
Message-ID: <200011082223.OAA24499@sf-web3.vaspecialprojects.com>

Patch #102185 has been updated. 

Project: python
Category: library
Status: Closed
Summary: reclaim fds in smtplib.py on connect failures

Follow-Ups:

Date: 2000-Oct-31 08:38
By: bwarsaw

Comment:
This patch fixes bug #119883 where failures in SMTP.connect() during the socket.connect() will leak file descriptors.
-------------------------------------------------------

Date: 2000-Nov-02 10:37
By: fdrake

Comment:
Please check in and close the bug.
-------------------------------------------------------

Date: 2000-Nov-08 14:23
By: bwarsaw

Comment:
Patch applied to smtplib.py 1.30
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102185&group_id=5470


From noreply@sourceforge.net  Wed Nov  8 22:53:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 8 Nov 2000 14:53:43 -0800
Subject: [Patches] [Patch #102170] move getopt() to Py_GetOpt() and use it unconditionally
Message-ID: <200011082253.OAA20970@sf-web2.i.sourceforge.net>

Patch #102170 has been updated. 

Project: python
Category: core (C code)
Status: Closed
Summary: move getopt() to Py_GetOpt() and use it unconditionally

Follow-Ups:

Date: 2000-Oct-30 09:48
By: twouters

Comment:
This patch attempts to do what Tim suggested in the python-dev thread about getopt()'s prototype and the difficulties of it. the 'getopt' implementation as provided in Python/getopt.c is renamed to Py_GetOpt(), the exported variables 'opterr', 'optind' and 'optarg' are prefixed with Py_, and all use in the Python sourcetree is adjusted.

The patch is missing the 'pygetopt.h' include file, though :P I'll resubmit a proper patch later. 

There are a couple of issues still open: the name of the getopt.c file, its use of 'fprintf(stderr, ... )', its license, documentation (which this patch lacks) and whether this Py_GetOpt should be an officially exported API at all.


-------------------------------------------------------

Date: 2000-Oct-30 10:08
By: twouters

Comment:
New patch, includes pygetopt.h by hack. (not sure if it patches cleanly, but it's not that exciting a file anyway :) Assigned to.... (spin wheel... Guido. no. spin wheel... Barry. no. spin wheel... Moshe. dang. spin wheel... *nudge*. Ah, finally,) Tim.


-------------------------------------------------------

Date: 2000-Nov-01 04:45
By: moshez

Comment:
Well, as the one who almost got the assignment <wink>, I'm +1 on it. Using native getopt is more trouble then it's worth, especially considering the fact that we've had an implementation of our own for so long. So here's for reinventing the wheel! <wink>
-------------------------------------------------------

Date: 2000-Nov-01 21:00
By: tim_one

Comment:
Accepted and assigned back to Thomas.

Guido approved of this "in theory" before, so go for it!  I would like to see the function renamed to _PyOS_GetOpt(), because we always stick "OS" in the name of an OS substitute function, and the leading underscore keeps it out of the public API (thus answering one of your open issues:  if people clamor for a public getopt replacement, we can add that later; but if we make it public from the start, it can never go away).

About the license, we can't change it, but it certainly allows us to modify the code and distribute your changes.  Under copyright law, I don't believe the changes are substantial enough that we could legitimately claim a new copyright for the new version.  So the whole license thing seems a non-issue to me.

Documentation?  If it's in the private API, it doesn't need any <wink>.

fprintf(stderr, ...)?  Sure.  Python barely exists by the time this code is called, and there's really nothing better to do (note that Py_Main calls fprintf(stderr, ...) itself later in a couple of other startup error cases).
-------------------------------------------------------

Date: 2000-Nov-08 14:53
By: fdrake

Comment:
Already checked in, so I'll close this for Thomas.

Thanks, Thomas!
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102170&group_id=5470


From noreply@sourceforge.net  Wed Nov  8 22:57:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 8 Nov 2000 14:57:27 -0800
Subject: [Patches] [Patch #100803] puremodule: ANSI-fication (UNTESTED!)
Message-ID: <200011082257.OAA23488@sf-web1.i.sourceforge.net>

Patch #100803 has been updated. 

Project: python
Category: Modules
Status: Closed
Summary: puremodule: ANSI-fication (UNTESTED!)

Follow-Ups:

Date: 2000-Jul-10 10:16
By: nowonder

Comment:
cannot test this, maybe Barry can
-------------------------------------------------------

Date: 2000-Jul-31 01:46
By: nowonder

Comment:
should I just check it in? Did you get around to review it?
-------------------------------------------------------

Date: 2000-Jul-31 09:30
By: bwarsaw

Comment:
There's one typo in nowonder's patch.  Here's a fixed version of the patch (unified).  This compiles but doesn't link.  I can't tell if this is caused by a problem with the purify stub libraries.

Meta note: because this is a commercial product which it seems no one has access to anymore, should we continue to support it in the standard distribution?
-------------------------------------------------------

Date: 2000-Jul-31 10:30
By: gvanrossum

Comment:
Since no-one can test this, let's be conservative and not check it in.
There's no absolute requirement to move *everything* to ANSI.
Since we know the old version worked, we should leave it alone.
I vote to keep this in the distribution -- maybe someone else can use it.

If someone else can confirm that it in fact works (or make it work) I'd be happy to accept the patch at that point.
-------------------------------------------------------

Date: 2000-Oct-26 13:51
By: gvanrossum

Comment:
Barry, why don't you check this in. In the next half year, we'll go through enough alpha and beta tests for 2.1 to make sure that someone will test the new module; and if nobody does, it's likely that nobody ever uses it, so then it doesn't matter. :-)
-------------------------------------------------------

Date: 2000-Nov-08 14:57
By: bwarsaw

Comment:
Heh, this was already applied and checked into version 2.4 of puremodule.c.  I guess I forgot to close this patch. :(
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=100803&group_id=5470


From noreply@sourceforge.net  Wed Nov  8 23:57:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 8 Nov 2000 15:57:55 -0800
Subject: [Patches] [Patch #102337] revised CALL_FUNCTION implementation
Message-ID: <200011082357.PAA21854@sf-web2.i.sourceforge.net>

Patch #102337 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: revised CALL_FUNCTION implementation

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102337&group_id=5470


From noreply@sourceforge.net  Thu Nov  9 00:08:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 8 Nov 2000 16:08:26 -0800
Subject: [Patches] [Patch #102337] revised CALL_FUNCTION implementation
Message-ID: <200011090008.QAA22011@sf-web2.i.sourceforge.net>

Patch #102337 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: revised CALL_FUNCTION implementation

Follow-Ups:

Date: 2000-Nov-08 16:08
By: jhylton

Comment:
This is a first draft patch that revises the CALL_FUNCTION implementation.  The first part of the revision breaks the long inline implementation into a series of function calls.  Each of the function calls has some small local optimizations (e.g. PyMethod_GET_SELF instead of PyMethod_GetSelf).

One problem that needs to be figured out is how these functions can cleanly access the stack_pointer local var of eval_code2.  The current approach is a bit messy.


-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102337&group_id=5470


From noreply@sourceforge.net  Thu Nov  9 00:29:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 8 Nov 2000 16:29:40 -0800
Subject: [Patches] [Patch #102337] revised CALL_FUNCTION implementation
Message-ID: <200011090029.QAA22282@sf-web2.i.sourceforge.net>

Patch #102337 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: revised CALL_FUNCTION implementation

Follow-Ups:

Date: 2000-Nov-08 16:08
By: jhylton

Comment:
This is a first draft patch that revises the CALL_FUNCTION implementation.  The first part of the revision breaks the long inline implementation into a series of function calls.  Each of the function calls has some small local optimizations (e.g. PyMethod_GET_SELF instead of PyMethod_GetSelf).

One problem that needs to be figured out is how these functions can cleanly access the stack_pointer local var of eval_code2.  The current approach is a bit messy.


-------------------------------------------------------

Date: 2000-Nov-08 16:29
By: jhylton

Comment:
A trivial fix to the logic keeps keyword arguments fast.

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102337&group_id=5470


From noreply@sourceforge.net  Thu Nov  9 03:52:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 8 Nov 2000 19:52:55 -0800
Subject: [Patches] [Patch #101993] Fix prepare_input_stream bug
Message-ID: <200011090352.TAA24452@sf-web2.i.sourceforge.net>

Patch #101993 has been updated. 

Project: python
Category: XML
Status: Accepted
Summary: Fix prepare_input_stream bug

Follow-Ups:

Date: 2000-Nov-08 19:52
By: fdrake

Comment:
This was accepted by Lars but not assigned back to Paul.

Paul, if this is still needed, please check it in and close the patch.  Thanks!
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101993&group_id=5470


From noreply@sourceforge.net  Thu Nov  9 09:50:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 9 Nov 2000 01:50:46 -0800
Subject: [Patches] [Patch #102337] revised CALL_FUNCTION implementation
Message-ID: <200011090950.BAA00335@sf-web3.vaspecialprojects.com>

Patch #102337 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: revised CALL_FUNCTION implementation

Follow-Ups:

Date: 2000-Nov-08 16:08
By: jhylton

Comment:
This is a first draft patch that revises the CALL_FUNCTION implementation.  The first part of the revision breaks the long inline implementation into a series of function calls.  Each of the function calls has some small local optimizations (e.g. PyMethod_GET_SELF instead of PyMethod_GetSelf).

One problem that needs to be figured out is how these functions can cleanly access the stack_pointer local var of eval_code2.  The current approach is a bit messy.


-------------------------------------------------------

Date: 2000-Nov-08 16:29
By: jhylton

Comment:
A trivial fix to the logic keeps keyword arguments fast.

-------------------------------------------------------

Date: 2000-Nov-09 01:50
By: lemburg

Comment:
The patch looks ok, but I'm still missing the cleanup of the
PyEval_CallXXX() APIs which the patch I sent you included.

Some cosmetic issues:
1. your new APIs should be static and start with an underscore
  (e.g. _Py_CallFunctions)
2. you should add some "register" markers to the function call
  definitions -- this helps compilers such as gcc when inlining functions

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102337&group_id=5470


From noreply@sourceforge.net  Thu Nov  9 13:59:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 9 Nov 2000 05:59:30 -0800
Subject: [Patches] [Patch #102337] revised CALL_FUNCTION implementation
Message-ID: <200011091359.FAA31484@sf-web2.i.sourceforge.net>

Patch #102337 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: revised CALL_FUNCTION implementation

Follow-Ups:

Date: 2000-Nov-08 16:08
By: jhylton

Comment:
This is a first draft patch that revises the CALL_FUNCTION implementation.  The first part of the revision breaks the long inline implementation into a series of function calls.  Each of the function calls has some small local optimizations (e.g. PyMethod_GET_SELF instead of PyMethod_GetSelf).

One problem that needs to be figured out is how these functions can cleanly access the stack_pointer local var of eval_code2.  The current approach is a bit messy.


-------------------------------------------------------

Date: 2000-Nov-08 16:29
By: jhylton

Comment:
A trivial fix to the logic keeps keyword arguments fast.

-------------------------------------------------------

Date: 2000-Nov-09 01:50
By: lemburg

Comment:
The patch looks ok, but I'm still missing the cleanup of the
PyEval_CallXXX() APIs which the patch I sent you included.

Some cosmetic issues:
1. your new APIs should be static and start with an underscore
  (e.g. _Py_CallFunctions)
2. you should add some "register" markers to the function call
  definitions -- this helps compilers such as gcc when inlining functions

-------------------------------------------------------

Date: 2000-Nov-09 05:59
By: none

Comment:
Haven't seen the patch yet, but one remark on static functions: these should *not* have an underscore and *not* have a _Py_ prefix.

The _Py_ prefix is for stuff that cannot be static, because it needs to be called from another file, but is not intended to be a public API (so it could disappear or change in a future version without breaking user code).

There are a few exceptions (_Py_ functions that are part of the public API); these are either historical accidents or need to be used with great care only by wizards.

--Guido
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102337&group_id=5470


From noreply@sourceforge.net  Thu Nov  9 13:59:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 9 Nov 2000 05:59:30 -0800
Subject: [Patches] [Patch #102337] revised CALL_FUNCTION implementation
Message-ID: <200011091359.FAA31487@sf-web2.i.sourceforge.net>

Patch #102337 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: revised CALL_FUNCTION implementation

Follow-Ups:

Date: 2000-Nov-08 16:08
By: jhylton

Comment:
This is a first draft patch that revises the CALL_FUNCTION implementation.  The first part of the revision breaks the long inline implementation into a series of function calls.  Each of the function calls has some small local optimizations (e.g. PyMethod_GET_SELF instead of PyMethod_GetSelf).

One problem that needs to be figured out is how these functions can cleanly access the stack_pointer local var of eval_code2.  The current approach is a bit messy.


-------------------------------------------------------

Date: 2000-Nov-08 16:29
By: jhylton

Comment:
A trivial fix to the logic keeps keyword arguments fast.

-------------------------------------------------------

Date: 2000-Nov-09 01:50
By: lemburg

Comment:
The patch looks ok, but I'm still missing the cleanup of the
PyEval_CallXXX() APIs which the patch I sent you included.

Some cosmetic issues:
1. your new APIs should be static and start with an underscore
  (e.g. _Py_CallFunctions)
2. you should add some "register" markers to the function call
  definitions -- this helps compilers such as gcc when inlining functions

-------------------------------------------------------

Date: 2000-Nov-09 05:59
By: none

Comment:
Haven't seen the patch yet, but one remark on static functions: these should *not* have an underscore and *not* have a _Py_ prefix.

The _Py_ prefix is for stuff that cannot be static, because it needs to be called from another file, but is not intended to be a public API (so it could disappear or change in a future version without breaking user code).

There are a few exceptions (_Py_ functions that are part of the public API); these are either historical accidents or need to be used with great care only by wizards.

--Guido
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102337&group_id=5470


From noreply@sourceforge.net  Sat Nov 11 08:01:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 11 Nov 2000 00:01:32 -0800
Subject: [Patches] [Patch #102354] Fix dynamic module linking on Mac OSX/OSXS
Message-ID: <200011110801.AAA00772@sf-web1.i.sourceforge.net>

Patch #102354 has been updated. 

Project: python
Category: Build
Status: Open
Summary: Fix dynamic module linking on Mac OSX/OSXS

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102354&group_id=5470


From noreply@sourceforge.net  Sat Nov 11 08:03:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 11 Nov 2000 00:03:48 -0800
Subject: [Patches] [Patch #102355] Fix fileobject.c on Mac OS X Server (possibly Darwin/OSX, also?)
Message-ID: <200011110803.AAA00805@sf-web1.i.sourceforge.net>

Patch #102355 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: Fix fileobject.c on Mac OS X Server (possibly Darwin/OSX, also?)

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102355&group_id=5470


From noreply@sourceforge.net  Sat Nov 11 08:04:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 11 Nov 2000 00:04:24 -0800
Subject: [Patches] [Patch #102356] Fix cthread support on Mac OS X Server
Message-ID: <200011110804.AAA00816@sf-web1.i.sourceforge.net>

Patch #102356 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: Fix cthread support on Mac OS X Server

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102356&group_id=5470


From noreply@sourceforge.net  Sat Nov 11 08:31:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 11 Nov 2000 00:31:31 -0800
Subject: [Patches] [Patch #102357] Add support for frameworks and objective-c source.  Uesful for both GnuStep and for OSXS/OSX/Darwin.
Message-ID: <200011110831.AAA31767@sf-web2.i.sourceforge.net>

Patch #102357 has been updated. 

Project: python
Category: Modules
Status: Open
Summary: Add support for frameworks and objective-c source.  Uesful for both GnuStep and for OSXS/OSX/Darwin.

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102357&group_id=5470


From noreply@sourceforge.net  Sat Nov 11 19:05:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 11 Nov 2000 11:05:47 -0800
Subject: [Patches] [Patch #102354] Fix dynamic module linking on Mac OSX/OSXS
Message-ID: <200011111905.LAA09701@sf-web3.vaspecialprojects.com>

Patch #102354 has been updated. 

Project: python
Category: Build
Status: Open
Summary: Fix dynamic module linking on Mac OSX/OSXS

Follow-Ups:

Date: 2000-Nov-11 11:05
By: bbum

Comment:
*** /tmp/Python-2.0/configure.in        Mon Oct 16 17:50:06 2000
--- configure.in        Sat Nov 11 13:54:43 2000
***************
*** 573,581 ****
          Darwin/*|next/*) 
                if test "$ns_dyld"
                then 
!                 if test "$ac_sys_system" = Darwin
!                 then LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress'
!                 else LDSHARED='$(CC) $(LDFLAGS) -bundle -prebind'
                  fi
                else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r';
                fi
--- 573,579 ----
          Darwin/*|next/*) 
                if test "$ns_dyld"
                then 
!                 LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress'
                  fi
                else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r';
                fi
***************
*** 646,652 ****
        # in System.framework; otherwise, __objcInit (referenced in
        # crt1.o) gets erroneously defined as common, which breaks dynamic
        # loading of any modules which reference it in System.framework
!       next/4*|next/5*) LINKFORSHARED="-u __dummy -framework System" ;;
        Darwin/*) LINKFORSHARED="-framework System" ;;
        SCO_SV*) LINKFORSHARED="-Bdynamic -dy -Wl,-Bexport";;
        ReliantUNIX*) LINKFORSHARED="-W1 -Blargedynsym";;
--- 644,650 ----
        # in System.framework; otherwise, __objcInit (referenced in
        # crt1.o) gets erroneously defined as common, which breaks dynamic
        # loading of any modules which reference it in System.framework
!       next/4*|next/5*) LINKFORSHARED="-u __dummy -framework System -framework Foundation" ;;
        Darwin/*) LINKFORSHARED="-framework System" ;;
        SCO_SV*) LINKFORSHARED="-Bdynamic -dy -Wl,-Bexport";;
        ReliantUNIX*) LINKFORSHARED="-W1 -Blargedynsym";;

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102354&group_id=5470


From noreply@sourceforge.net  Sat Nov 11 19:07:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 11 Nov 2000 11:07:32 -0800
Subject: [Patches] [Patch #102354] Fix dynamic module linking on Mac OSX/OSXS
Message-ID: <200011111907.LAA09716@sf-web3.vaspecialprojects.com>

Patch #102354 has been updated. 

Project: python
Category: Build
Status: Open
Summary: Fix dynamic module linking on Mac OSX/OSXS

Follow-Ups:

Date: 2000-Nov-11 11:05
By: bbum

Comment:
*** /tmp/Python-2.0/configure.in        Mon Oct 16 17:50:06 2000
--- configure.in        Sat Nov 11 13:54:43 2000
***************
*** 573,581 ****
          Darwin/*|next/*) 
                if test "$ns_dyld"
                then 
!                 if test "$ac_sys_system" = Darwin
!                 then LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress'
!                 else LDSHARED='$(CC) $(LDFLAGS) -bundle -prebind'
                  fi
                else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r';
                fi
--- 573,579 ----
          Darwin/*|next/*) 
                if test "$ns_dyld"
                then 
!                 LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress'
                  fi
                else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r';
                fi
***************
*** 646,652 ****
        # in System.framework; otherwise, __objcInit (referenced in
        # crt1.o) gets erroneously defined as common, which breaks dynamic
        # loading of any modules which reference it in System.framework
!       next/4*|next/5*) LINKFORSHARED="-u __dummy -framework System" ;;
        Darwin/*) LINKFORSHARED="-framework System" ;;
        SCO_SV*) LINKFORSHARED="-Bdynamic -dy -Wl,-Bexport";;
        ReliantUNIX*) LINKFORSHARED="-W1 -Blargedynsym";;
--- 644,650 ----
        # in System.framework; otherwise, __objcInit (referenced in
        # crt1.o) gets erroneously defined as common, which breaks dynamic
        # loading of any modules which reference it in System.framework
!       next/4*|next/5*) LINKFORSHARED="-u __dummy -framework System -framework Foundation" ;;
        Darwin/*) LINKFORSHARED="-framework System" ;;
        SCO_SV*) LINKFORSHARED="-Bdynamic -dy -Wl,-Bexport";;
        ReliantUNIX*) LINKFORSHARED="-W1 -Blargedynsym";;

-------------------------------------------------------

Date: 2000-Nov-11 11:07
By: bbum

Comment:
The addition of -framework Foundation is required to allow dynamically loaded modules to have access to the Objective-C runtiem under OSXS.

This *may* also be required under Darwin/OSX, but-- if that is the case-- it will be submitted as a separate patch once I restore my OSX work environment and can verify that it is the case.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102354&group_id=5470


From noreply@sourceforge.net  Sat Nov 11 19:07:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 11 Nov 2000 11:07:32 -0800
Subject: [Patches] [Patch #102354] Fix dynamic module linking on Mac OSX/OSXS
Message-ID: <200011111907.LAA09713@sf-web3.vaspecialprojects.com>

Patch #102354 has been updated. 

Project: python
Category: Build
Status: Open
Summary: Fix dynamic module linking on Mac OSX/OSXS

Follow-Ups:

Date: 2000-Nov-11 11:05
By: bbum

Comment:
*** /tmp/Python-2.0/configure.in        Mon Oct 16 17:50:06 2000
--- configure.in        Sat Nov 11 13:54:43 2000
***************
*** 573,581 ****
          Darwin/*|next/*) 
                if test "$ns_dyld"
                then 
!                 if test "$ac_sys_system" = Darwin
!                 then LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress'
!                 else LDSHARED='$(CC) $(LDFLAGS) -bundle -prebind'
                  fi
                else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r';
                fi
--- 573,579 ----
          Darwin/*|next/*) 
                if test "$ns_dyld"
                then 
!                 LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress'
                  fi
                else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r';
                fi
***************
*** 646,652 ****
        # in System.framework; otherwise, __objcInit (referenced in
        # crt1.o) gets erroneously defined as common, which breaks dynamic
        # loading of any modules which reference it in System.framework
!       next/4*|next/5*) LINKFORSHARED="-u __dummy -framework System" ;;
        Darwin/*) LINKFORSHARED="-framework System" ;;
        SCO_SV*) LINKFORSHARED="-Bdynamic -dy -Wl,-Bexport";;
        ReliantUNIX*) LINKFORSHARED="-W1 -Blargedynsym";;
--- 644,650 ----
        # in System.framework; otherwise, __objcInit (referenced in
        # crt1.o) gets erroneously defined as common, which breaks dynamic
        # loading of any modules which reference it in System.framework
!       next/4*|next/5*) LINKFORSHARED="-u __dummy -framework System -framework Foundation" ;;
        Darwin/*) LINKFORSHARED="-framework System" ;;
        SCO_SV*) LINKFORSHARED="-Bdynamic -dy -Wl,-Bexport";;
        ReliantUNIX*) LINKFORSHARED="-W1 -Blargedynsym";;

-------------------------------------------------------

Date: 2000-Nov-11 11:07
By: bbum

Comment:
The addition of -framework Foundation is required to allow dynamically loaded modules to have access to the Objective-C runtiem under OSXS.

This *may* also be required under Darwin/OSX, but-- if that is the case-- it will be submitted as a separate patch once I restore my OSX work environment and can verify that it is the case.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102354&group_id=5470


From noreply@sourceforge.net  Sun Nov 12 04:33:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 11 Nov 2000 20:33:21 -0800
Subject: [Patches] [Patch #102355] Fix fileobject.c on Mac OS X Server (possibly Darwin/OSX, also?)
Message-ID: <200011120433.UAA12805@sf-web2.i.sourceforge.net>

Patch #102355 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: Fix fileobject.c on Mac OS X Server (possibly Darwin/OSX, also?)

Follow-Ups:

Date: 2000-Nov-11 20:33
By: bbum

Comment:
This patch proves not to be necessary on Mac OS X.

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102355&group_id=5470


From noreply@sourceforge.net  Sun Nov 12 04:33:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 11 Nov 2000 20:33:21 -0800
Subject: [Patches] [Patch #102355] Fix fileobject.c on Mac OS X Server (possibly Darwin/OSX, also?)
Message-ID: <200011120433.UAA12808@sf-web2.i.sourceforge.net>

Patch #102355 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: Fix fileobject.c on Mac OS X Server (possibly Darwin/OSX, also?)

Follow-Ups:

Date: 2000-Nov-11 20:33
By: bbum

Comment:
This patch proves not to be necessary on Mac OS X.

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102355&group_id=5470


From noreply@sourceforge.net  Sun Nov 12 07:31:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 11 Nov 2000 23:31:12 -0800
Subject: [Patches] [Patch #102362] Support dynamic module loading under OSX [including support for modules w/Objective-C]
Message-ID: <200011120731.XAA15468@sf-web1.i.sourceforge.net>

Patch #102362 has been updated. 

Project: python
Category: None
Status: Open
Summary: Support dynamic module loading under OSX [including support for modules w/Objective-C]

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102362&group_id=5470


From noreply@sourceforge.net  Sun Nov 12 10:03:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 Nov 2000 02:03:10 -0800
Subject: [Patches] [Patch #102231] Dynamic loading on Solaris does not work (bug #121121)
Message-ID: <200011121003.CAA19027@sf-web3.vaspecialprojects.com>

Patch #102231 has been updated. 

Project: python
Category: Build
Status: Open
Summary: Dynamic loading on Solaris does not work (bug #121121)

Follow-Ups:

Date: 2000-Nov-12 02:03
By: loewis

Comment:
This patch doesn't look right to me. Furthermore, on my system
(Solaris 2.6 with gcc), configure perfectly determines to use 
dynload_shlib. That is because of the line

# the dlopen() function means we might want to use dynload_shlib.o. some
# platforms, such as AIX, have dlopen(), but don't want to use it.
AC_CHECK_FUNCS(dlopen)

which is executed before the DYNLOADFILE variable is set.

Can you please try to analyse why the first attempt to determine
presence of dlopen fails?

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102231&group_id=5470


From noreply@sourceforge.net  Sun Nov 12 10:07:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 Nov 2000 02:07:00 -0800
Subject: [Patches] [Patch #102354] Fix dynamic module linking on Mac OSX/OSXS
Message-ID: <200011121007.CAA15639@sf-web2.i.sourceforge.net>

Patch #102354 has been updated. 

Project: python
Category: Build
Status: Open
Summary: Fix dynamic module linking on Mac OSX/OSXS

Follow-Ups:

Date: 2000-Nov-11 11:05
By: bbum

Comment:
*** /tmp/Python-2.0/configure.in        Mon Oct 16 17:50:06 2000
--- configure.in        Sat Nov 11 13:54:43 2000
***************
*** 573,581 ****
          Darwin/*|next/*) 
                if test "$ns_dyld"
                then 
!                 if test "$ac_sys_system" = Darwin
!                 then LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress'
!                 else LDSHARED='$(CC) $(LDFLAGS) -bundle -prebind'
                  fi
                else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r';
                fi
--- 573,579 ----
          Darwin/*|next/*) 
                if test "$ns_dyld"
                then 
!                 LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress'
                  fi
                else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r';
                fi
***************
*** 646,652 ****
        # in System.framework; otherwise, __objcInit (referenced in
        # crt1.o) gets erroneously defined as common, which breaks dynamic
        # loading of any modules which reference it in System.framework
!       next/4*|next/5*) LINKFORSHARED="-u __dummy -framework System" ;;
        Darwin/*) LINKFORSHARED="-framework System" ;;
        SCO_SV*) LINKFORSHARED="-Bdynamic -dy -Wl,-Bexport";;
        ReliantUNIX*) LINKFORSHARED="-W1 -Blargedynsym";;
--- 644,650 ----
        # in System.framework; otherwise, __objcInit (referenced in
        # crt1.o) gets erroneously defined as common, which breaks dynamic
        # loading of any modules which reference it in System.framework
!       next/4*|next/5*) LINKFORSHARED="-u __dummy -framework System -framework Foundation" ;;
        Darwin/*) LINKFORSHARED="-framework System" ;;
        SCO_SV*) LINKFORSHARED="-Bdynamic -dy -Wl,-Bexport";;
        ReliantUNIX*) LINKFORSHARED="-W1 -Blargedynsym";;

-------------------------------------------------------

Date: 2000-Nov-11 11:07
By: bbum

Comment:
The addition of -framework Foundation is required to allow dynamically loaded modules to have access to the Objective-C runtiem under OSXS.

This *may* also be required under Darwin/OSX, but-- if that is the case-- it will be submitted as a separate patch once I restore my OSX work environment and can verify that it is the case.
-------------------------------------------------------

Date: 2000-Nov-12 02:07
By: loewis

Comment:
If you add an option that is required for something, then it would be good to add a comment to indicate what the something is. Also, are you sure that linking with the Foundation framework is absolutely necessary? Would it be possible for extension modules to link with the framework themselves if they need it?
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102354&group_id=5470


From noreply@sourceforge.net  Sun Nov 12 10:17:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 Nov 2000 02:17:42 -0800
Subject: [Patches] [Patch #102356] Fix cthread support on Mac OS X Server
Message-ID: <200011121017.CAA19150@sf-web3.vaspecialprojects.com>

Patch #102356 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: Fix cthread support on Mac OS X Server

Follow-Ups:

Date: 2000-Nov-12 02:17
By: loewis

Comment:
That patch appears to be a duplicate of 102355, I cannot see any relationship to cthreads.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102356&group_id=5470


From noreply@sourceforge.net  Sun Nov 12 10:19:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 Nov 2000 02:19:48 -0800
Subject: [Patches] [Patch #101651] Gracefully detect usage of old extension module
Message-ID: <200011121019.CAA16947@sf-web1.i.sourceforge.net>

Patch #101651 has been updated. 

Project: python
Category: Windows
Status: Rejected
Summary: Gracefully detect usage of old extension module

Follow-Ups:

Date: 2000-Sep-25 12:49
By: loewis

Comment:
Also see commentary inside the patch.
-------------------------------------------------------

Date: 2000-Sep-25 16:46
By: tim_one

Comment:
Assigned to MarkH.  Mark, if you've got the bandwidth to think about this immediately, and like it, say so within the next couple of hours and I'll sneak it into 2.0b2.  Else Postpone it.
-------------------------------------------------------

Date: 2000-Sep-25 19:16
By: mhammond

Comment:
My theoretical objection to this is that it may be possible for a single process to have both Python 1.5 and Python 2.0 embedded - eg, a Web server.

The issue is "does the extension I just loaded reference Python15.dll", rather than simply "is python15.dll used by anyone in this process"

Like I said, mainly theoretical, but there is no reason I can think of why this would not work today for people, so we can only assume it is!

Marked as postponed.
-------------------------------------------------------

Date: 2000-Sep-25 19:24
By: tim_one

Comment:
Thank you, Mark.  I made enough crisis-mode work for myself by championing other last-second changes that I can't afford to argue with you now even if I wanted to <wink>.

But I don't want to, so Postponing was the right thing all around.
-------------------------------------------------------

Date: 2000-Nov-12 02:19
By: loewis

Comment:
That patch is superseded by the patch adding GetPythonImport, so I think it is no longer needed.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101651&group_id=5470


From noreply@sourceforge.net  Sun Nov 12 11:06:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 Nov 2000 03:06:01 -0800
Subject: [Patches] [Patch #102363] Allow Unicode in urllib
Message-ID: <200011121106.DAA16201@sf-web2.i.sourceforge.net>

Patch #102363 has been updated. 

Project: python
Category: library
Status: Open
Summary: Allow Unicode in urllib

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102363&group_id=5470


From noreply@sourceforge.net  Sun Nov 12 11:06:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 Nov 2000 03:06:20 -0800
Subject: [Patches] [Patch #102364] Fix for119822:  Allow Unicode in urllib
Message-ID: <200011121106.DAA17414@sf-web1.i.sourceforge.net>

Patch #102364 has been updated. 

Project: python
Category: library
Status: Open
Summary: Fix for119822:  Allow Unicode in urllib

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102364&group_id=5470


From noreply@sourceforge.net  Sun Nov 12 11:06:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 Nov 2000 03:06:54 -0800
Subject: [Patches] [Patch #102363] Allow Unicode in urllib
Message-ID: <200011121106.DAA17424@sf-web1.i.sourceforge.net>

Patch #102363 has been updated. 

Project: python
Category: library
Status: Deleted
Summary: Allow Unicode in urllib

Follow-Ups:

Date: 2000-Nov-12 03:06
By: loewis

Comment:
Duplicate of 102364
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102363&group_id=5470


From noreply@sourceforge.net  Sun Nov 12 11:09:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 Nov 2000 03:09:18 -0800
Subject: [Patches] [Patch #102364] Fix for119822:  Allow Unicode in urllib
Message-ID: <200011121109.DAA17458@sf-web1.i.sourceforge.net>

Patch #102364 has been updated. 

Project: python
Category: library
Status: Open
Summary: Fix for119822:  Allow Unicode in urllib

Follow-Ups:

Date: 2000-Nov-12 03:09
By: loewis

Comment:
This fixes the bug by explicitly converting Unicode strings to ASCII. I could find no indication in the RFCs that anything but ASCII is allowed in URLs.

The size of the patch primarily originates from the renaming of the type local variable to urltype, so that the builtin type function is available.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102364&group_id=5470


From noreply@sourceforge.net  Sun Nov 12 13:11:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 Nov 2000 05:11:10 -0800
Subject: [Patches] [Patch #102364] Fix for119822:  Allow Unicode in urllib
Message-ID: <200011121311.FAA17516@sf-web2.i.sourceforge.net>

Patch #102364 has been updated. 

Project: python
Category: library
Status: Open
Summary: Fix for119822:  Allow Unicode in urllib

Follow-Ups:

Date: 2000-Nov-12 03:09
By: loewis

Comment:
This fixes the bug by explicitly converting Unicode strings to ASCII. I could find no indication in the RFCs that anything but ASCII is allowed in URLs.

The size of the patch primarily originates from the renaming of the type local variable to urltype, so that the builtin type function is available.
-------------------------------------------------------

Date: 2000-Nov-12 05:11
By: lemburg

Comment:
There are movements which want to add UTF-8 support to URLs.
I don't know if there already are RTFs on this, but since even
MS Explorer supports this, I guess the movement must be strong ;-)

It does seem to be the natural coice and DNS is moving in that
direction too.

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102364&group_id=5470


From noreply@sourceforge.net  Sun Nov 12 13:11:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 Nov 2000 05:11:10 -0800
Subject: [Patches] [Patch #102364] Fix for119822:  Allow Unicode in urllib
Message-ID: <200011121311.FAA17519@sf-web2.i.sourceforge.net>

Patch #102364 has been updated. 

Project: python
Category: library
Status: Open
Summary: Fix for119822:  Allow Unicode in urllib

Follow-Ups:

Date: 2000-Nov-12 03:09
By: loewis

Comment:
This fixes the bug by explicitly converting Unicode strings to ASCII. I could find no indication in the RFCs that anything but ASCII is allowed in URLs.

The size of the patch primarily originates from the renaming of the type local variable to urltype, so that the builtin type function is available.
-------------------------------------------------------

Date: 2000-Nov-12 05:11
By: lemburg

Comment:
There are movements which want to add UTF-8 support to URLs.
I don't know if there already are RTFs on this, but since even
MS Explorer supports this, I guess the movement must be strong ;-)

It does seem to be the natural coice and DNS is moving in that
direction too.

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102364&group_id=5470


From noreply@sourceforge.net  Sun Nov 12 16:22:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 Nov 2000 08:22:10 -0800
Subject: [Patches] [Patch #102354] Fix dynamic module linking on Mac OSX/OSXS
Message-ID: <200011121622.IAA24133@sf-web1.i.sourceforge.net>

Patch #102354 has been updated. 

Project: python
Category: Build
Status: Open
Summary: Fix dynamic module linking on Mac OSX/OSXS

Follow-Ups:

Date: 2000-Nov-11 11:05
By: bbum

Comment:
*** /tmp/Python-2.0/configure.in        Mon Oct 16 17:50:06 2000
--- configure.in        Sat Nov 11 13:54:43 2000
***************
*** 573,581 ****
          Darwin/*|next/*) 
                if test "$ns_dyld"
                then 
!                 if test "$ac_sys_system" = Darwin
!                 then LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress'
!                 else LDSHARED='$(CC) $(LDFLAGS) -bundle -prebind'
                  fi
                else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r';
                fi
--- 573,579 ----
          Darwin/*|next/*) 
                if test "$ns_dyld"
                then 
!                 LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress'
                  fi
                else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r';
                fi
***************
*** 646,652 ****
        # in System.framework; otherwise, __objcInit (referenced in
        # crt1.o) gets erroneously defined as common, which breaks dynamic
        # loading of any modules which reference it in System.framework
!       next/4*|next/5*) LINKFORSHARED="-u __dummy -framework System" ;;
        Darwin/*) LINKFORSHARED="-framework System" ;;
        SCO_SV*) LINKFORSHARED="-Bdynamic -dy -Wl,-Bexport";;
        ReliantUNIX*) LINKFORSHARED="-W1 -Blargedynsym";;
--- 644,650 ----
        # in System.framework; otherwise, __objcInit (referenced in
        # crt1.o) gets erroneously defined as common, which breaks dynamic
        # loading of any modules which reference it in System.framework
!       next/4*|next/5*) LINKFORSHARED="-u __dummy -framework System -framework Foundation" ;;
        Darwin/*) LINKFORSHARED="-framework System" ;;
        SCO_SV*) LINKFORSHARED="-Bdynamic -dy -Wl,-Bexport";;
        ReliantUNIX*) LINKFORSHARED="-W1 -Blargedynsym";;

-------------------------------------------------------

Date: 2000-Nov-11 11:07
By: bbum

Comment:
The addition of -framework Foundation is required to allow dynamically loaded modules to have access to the Objective-C runtiem under OSXS.

This *may* also be required under Darwin/OSX, but-- if that is the case-- it will be submitted as a separate patch once I restore my OSX work environment and can verify that it is the case.
-------------------------------------------------------

Date: 2000-Nov-12 02:07
By: loewis

Comment:
If you add an option that is required for something, then it would be good to add a comment to indicate what the something is. Also, are you sure that linking with the Foundation framework is absolutely necessary? Would it be possible for extension modules to link with the framework themselves if they need it?
-------------------------------------------------------

Date: 2000-Nov-12 08:22
By: bbum

Comment:
(It isn't clear where one can actually document a patch when uploading the first version.   I'll have to make sure and add a comment after the initial upload-- or document the code better.  Sorry about that.)

The Foundation framework must be linked into the python executable if any dynamically loaded module is to ever use the Objective-C runtime.   At least, I haven't found a workaround that allows one to link it into the loadable module.

If it isn't, then the load dies with one of two erros depending on platform:

OSX:   dies with a duplicate symbol error on __objcInit.

OSXS:  dies with a "objc: link required classes into application"



-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102354&group_id=5470


From noreply@sourceforge.net  Sun Nov 12 16:22:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 Nov 2000 08:22:10 -0800
Subject: [Patches] [Patch #102354] Fix dynamic module linking on Mac OSX/OSXS
Message-ID: <200011121622.IAA24130@sf-web1.i.sourceforge.net>

Patch #102354 has been updated. 

Project: python
Category: Build
Status: Open
Summary: Fix dynamic module linking on Mac OSX/OSXS

Follow-Ups:

Date: 2000-Nov-11 11:05
By: bbum

Comment:
*** /tmp/Python-2.0/configure.in        Mon Oct 16 17:50:06 2000
--- configure.in        Sat Nov 11 13:54:43 2000
***************
*** 573,581 ****
          Darwin/*|next/*) 
                if test "$ns_dyld"
                then 
!                 if test "$ac_sys_system" = Darwin
!                 then LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress'
!                 else LDSHARED='$(CC) $(LDFLAGS) -bundle -prebind'
                  fi
                else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r';
                fi
--- 573,579 ----
          Darwin/*|next/*) 
                if test "$ns_dyld"
                then 
!                 LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress'
                  fi
                else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r';
                fi
***************
*** 646,652 ****
        # in System.framework; otherwise, __objcInit (referenced in
        # crt1.o) gets erroneously defined as common, which breaks dynamic
        # loading of any modules which reference it in System.framework
!       next/4*|next/5*) LINKFORSHARED="-u __dummy -framework System" ;;
        Darwin/*) LINKFORSHARED="-framework System" ;;
        SCO_SV*) LINKFORSHARED="-Bdynamic -dy -Wl,-Bexport";;
        ReliantUNIX*) LINKFORSHARED="-W1 -Blargedynsym";;
--- 644,650 ----
        # in System.framework; otherwise, __objcInit (referenced in
        # crt1.o) gets erroneously defined as common, which breaks dynamic
        # loading of any modules which reference it in System.framework
!       next/4*|next/5*) LINKFORSHARED="-u __dummy -framework System -framework Foundation" ;;
        Darwin/*) LINKFORSHARED="-framework System" ;;
        SCO_SV*) LINKFORSHARED="-Bdynamic -dy -Wl,-Bexport";;
        ReliantUNIX*) LINKFORSHARED="-W1 -Blargedynsym";;

-------------------------------------------------------

Date: 2000-Nov-11 11:07
By: bbum

Comment:
The addition of -framework Foundation is required to allow dynamically loaded modules to have access to the Objective-C runtiem under OSXS.

This *may* also be required under Darwin/OSX, but-- if that is the case-- it will be submitted as a separate patch once I restore my OSX work environment and can verify that it is the case.
-------------------------------------------------------

Date: 2000-Nov-12 02:07
By: loewis

Comment:
If you add an option that is required for something, then it would be good to add a comment to indicate what the something is. Also, are you sure that linking with the Foundation framework is absolutely necessary? Would it be possible for extension modules to link with the framework themselves if they need it?
-------------------------------------------------------

Date: 2000-Nov-12 08:22
By: bbum

Comment:
(It isn't clear where one can actually document a patch when uploading the first version.   I'll have to make sure and add a comment after the initial upload-- or document the code better.  Sorry about that.)

The Foundation framework must be linked into the python executable if any dynamically loaded module is to ever use the Objective-C runtime.   At least, I haven't found a workaround that allows one to link it into the loadable module.

If it isn't, then the load dies with one of two erros depending on platform:

OSX:   dies with a duplicate symbol error on __objcInit.

OSXS:  dies with a "objc: link required classes into application"



-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102354&group_id=5470


From noreply@sourceforge.net  Sun Nov 12 16:27:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 Nov 2000 08:27:40 -0800
Subject: [Patches] [Patch #102356] Fix cthread support on Mac OS X Server
Message-ID: <200011121627.IAA24216@sf-web1.i.sourceforge.net>

Patch #102356 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: Fix cthread support on Mac OS X Server

Follow-Ups:

Date: 2000-Nov-12 02:17
By: loewis

Comment:
That patch appears to be a duplicate of 102355, I cannot see any relationship to cthreads.
-------------------------------------------------------

Date: 2000-Nov-12 08:27
By: bbum

Comment:
Damnit.  Wrong patch.  My first experience with SourceForge is not going well.

The declaration of the PyThread_start_new_thread() function has a syntax error in the cthreads module.  Changing it from:

PyThread_start_new_thread(func, void (*func)(void *), void *arg)

to:

PyThread_start_new_thread(void (*func)(void *), void *arg)

Fixes the problem (and the thread test passes during 'make test').



-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102356&group_id=5470


From noreply@sourceforge.net  Sun Nov 12 16:27:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 Nov 2000 08:27:40 -0800
Subject: [Patches] [Patch #102356] Fix cthread support on Mac OS X Server
Message-ID: <200011121627.IAA24219@sf-web1.i.sourceforge.net>

Patch #102356 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: Fix cthread support on Mac OS X Server

Follow-Ups:

Date: 2000-Nov-12 02:17
By: loewis

Comment:
That patch appears to be a duplicate of 102355, I cannot see any relationship to cthreads.
-------------------------------------------------------

Date: 2000-Nov-12 08:27
By: bbum

Comment:
Damnit.  Wrong patch.  My first experience with SourceForge is not going well.

The declaration of the PyThread_start_new_thread() function has a syntax error in the cthreads module.  Changing it from:

PyThread_start_new_thread(func, void (*func)(void *), void *arg)

to:

PyThread_start_new_thread(void (*func)(void *), void *arg)

Fixes the problem (and the thread test passes during 'make test').



-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102356&group_id=5470


From noreply@sourceforge.net  Mon Nov 13 08:41:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 Nov 2000 00:41:04 -0800
Subject: [Patches] [Patch #102364] Fix for119822:  Allow Unicode in urllib
Message-ID: <200011130841.AAA02674@sf-web2.i.sourceforge.net>

Patch #102364 has been updated. 

Project: python
Category: library
Status: Open
Summary: Fix for119822:  Allow Unicode in urllib

Follow-Ups:

Date: 2000-Nov-12 03:09
By: loewis

Comment:
This fixes the bug by explicitly converting Unicode strings to ASCII. I could find no indication in the RFCs that anything but ASCII is allowed in URLs.

The size of the patch primarily originates from the renaming of the type local variable to urltype, so that the builtin type function is available.
-------------------------------------------------------

Date: 2000-Nov-12 05:11
By: lemburg

Comment:
There are movements which want to add UTF-8 support to URLs.
I don't know if there already are RTFs on this, but since even
MS Explorer supports this, I guess the movement must be strong ;-)

It does seem to be the natural coice and DNS is moving in that
direction too.

-------------------------------------------------------

Date: 2000-Nov-13 00:41
By: loewis

Comment:
Looking at http://www.ietf.org/ids.by.wg/idn.html, there is hardly any consensus on how to do internationalized domain names.

As for Unicode in URLs, there is not even an Internet Draft proposing usage of UTF-8. So I'd propose to follow established standards, until drafts for new standards come available.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102364&group_id=5470


From noreply@sourceforge.net  Tue Nov 14 21:36:23 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 Nov 2000 13:36:23 -0800
Subject: [Patches] [Patch #102068] fix for bug #117402 (repr of array)
Message-ID: <200011142136.NAA28726@sf-web1.i.sourceforge.net>

Patch #102068 has been updated. 

Project: python
Category: Modules
Status: Closed
Summary: fix for bug #117402 (repr of array)

Follow-Ups:

Date: 2000-Oct-22 09:51
By: mwh

Comment:
before:
>>> import array
>>> array.array('c',"cd")
array('c', 'cd')
>>> repr(_)
Segmentation fault (core dumped)

after:
>>> import array
>>> array.array('c',"dd")
array('c', 'dd')
>>> `_`
"array('c', 'dd')"

Fixes bug #117402, which was introduced in revision 2.51.
-------------------------------------------------------

Date: 2000-Oct-23 06:22
By: nascheme

Comment:
A test case should be added to make sure str() and repr() work on arrays.
-------------------------------------------------------

Date: 2000-Oct-23 08:36
By: fdrake

Comment:
Assigned to Tim since the bug is already assigned to him.
-------------------------------------------------------

Date: 2000-Nov-01 10:28
By: mwh

Comment:
oop!  I wrote a simple test a while back , but sf's web pages were down, so I forgot to upload it...
-------------------------------------------------------

Date: 2000-Nov-14 13:36
By: tim_one

Comment:
Closed.

Oops!  I had already checked in a fix for arraymodule.c 
(very much the same as this one).

Now I added a minor variant of the test_array.py patch.

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102068&group_id=5470


From information@technojobs.co.uk  Wed Nov 15 18:33:14 2000
From: information@technojobs.co.uk (Technojobs Limited)
Date: Wed, 15 Nov 2000 18:33:14 -0000
Subject: [Patches] Search the recruitment agencies for technical jobs on-line.
Message-ID: <E13w7Ns-00034k-00@clustermail.minx.net.uk>

Search the recruitment agencies for technical jobs on-line.

at:       http://www.technojobs.co.uk

Hundreds of new technical jobs posted every day...............

Technojobs New Advanced Site Now On-Line

Dear Job Seeker

Searching the recruitment agencies for technical jobs on-line has never been easier; our new site interface is now on line. Your new look new feel technojobs has been
updated with some top job-hunting tools. www.technojobs.co.uk

Search The Agencies
Our new advanced intelligent search tool is fast as it is accurate. Once you have used our CV centre to register your CV, simply click the link in a job add, and technojobs will automatically send your CV with a covering letter directly to that agency in reply to their job add.

CV Centre
Upload your CV via our secure site, logon at any time with your personal ID to update your CV, Activate it de-activate it, or if you're in work and looking to further your career use the Head Hunter Mode.

Jobs By Email
Our jobs by email keyword filter system, now employees the same technology that drives our main search.

Agencies
Technojobs hosts jobs for over 400 agencies, including some of the world top names in IT recruitment. We receive around 300 new technology jobs a day. If you have registered your CV with our CV centre then our agencies can search for you, we also distribute your CV when activated to agencies automatically, what's more your CV is scanned and sent to consultants that are specifically looking for candidates with your skill set.

Technojobs.co.uk Limited

Remove yourself from this mail list
Send a blank email to mailto:remove_097463@technojobs.co.uk , and place the word remove in the subject field.


From noreply@sourceforge.net  Thu Nov 16 15:28:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Nov 2000 07:28:45 -0800
Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch
Message-ID: <200011161528.HAA09747@sf-web2.i.sourceforge.net>

Patch #102409 has been updated. 

Project: python
Category: Build
Status: Open
Summary: Cygwin Python DLL and Shared Extension Patch

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470


From noreply@sourceforge.net  Thu Nov 16 15:40:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Nov 2000 07:40:09 -0800
Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch
Message-ID: <200011161540.HAA01848@sf-web1.i.sourceforge.net>

Patch #102409 has been updated. 

Project: python
Category: Build
Status: Open
Summary: Cygwin Python DLL and Shared Extension Patch

Follow-Ups:

Date: 2000-Nov-16 07:40
By: jlt63

Comment:
This patch builds Cygwin Python with its core as a DLL -- similar to
the way that Win32 Python is built.  Once Cygwin Python is built as a
"shared library" (i.e., DLL), the procedure for building extensions is
the same as on UNIX platforms that support shared libraries.  It's as
easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f
Makefile.pre.in boot, make.

The following is the procedure to apply the patch and build Cygwin Python:

	$ patch -p0 <Cygwin-1.1.5-Python-2.0.patch
	$ autoheader
	$ autoconf
	$ configure --with-threads=no --with-libm= --with-suffix=.exe
	$ make
	$ make install

To test out shared extensions, try the following:

	$ cd Demo/extend
	$ make_shared
	$ python
	Python 2.0 (#1, Nov  1 2000, 08:51:39)
	[GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01
	Type "copyright", "credits" or "license" for more information.
	>>> import xx
	>>> dir(xx)
	['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj']
	>>> xx.foo(2, 3)
	5

As a more realistic example, I was able to build python-ldap 1.10alpha3
(http://sourceforge.net/projects/python-ldap) with the following minimal
changes:

	1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__)
	   as described in http://www.python.org/doc/FAQ.html#3.24
	2. added DL_EXPORT to init_ldap()

Note that there were no changes of any kind to the build files (i.e,
configure.in, Makefile.in, and Modules/Setup.in) or functionality changes
to the C source.

The following is an annotated ChangeLog for the patch:

Thu Nov 16 10:38:20 2000  Jason Tishler <jt@dothill.com>

	* Makefile.in: Add autoconf variable SET_DLLLIBRARY.
	* Makefile.in (altbininstall): Enhance altbininstall rule to also
	install the Cygwin Python DLL.
	* Makefile.in (libainstall): Change libainstall rule to install
	LDLIBRARY instead of LIBRARY.

	Will installing LDLIBRARY instead of LIBRARY break other
	platforms?  The terse description of LDLIBRARY in configure.in
	seems to indicate that possibly the original build procedure
	should be been installing it instead of LIBRARY.  Anyway, I am
	very willing to change the patch to install both LDLIBRARY and
	LIBRARY (if they are different) or some other suitable solution.

	* Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY.
	* Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build
	the Cygwin Python DLL.

	Should the body of this rule be hidden in a shell script?  I have 
	stumbled across various platform specific scripts like BeOS/ar-fake
	that has me thinking that this may be desirable.

	* Modules/makesetup: Add shell variable module and default its value
	to "module".
	* Modules/makesetup: Add Cygwin specific definitions to set shell
	variables module, CygwinFlags, and CygwinLibs appropriately.

	Is it undesirable to put platform specific code in makesetup?

	* Modules/makesetup: Add .def to the list of known file types.
	* Modules/makesetup: Change object rule to include CygwinFlags.
	* Modules/makesetup: Change to use shell variable module instead of
	hardcoded "module".
	* Modules/makesetup: Change shared extension rule to include
	CygwinLibs.
	* acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and
	DL_EXPORT.

	Is there a better way of accomplishing this without affecting config.h
	on all other autoconf supported platforms too?

	* configure.in: Add autoconf variable SET_DLLLIBRARY.
	* configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY
	appropriately.

	I have chosen to call the import library libpython$(VERSION).dll.a
	and the DLL libpython$(VERSION).dll.  Recently there has been a
	proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html)
	to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order
	to avoid clashing with Win32 versions of the same DLL.  I have stayed
	with libpython2.0.dll because it is more consistent with the UNIX
	naming convention and because there is no (current) possibility of
	clashing with the Win32 Python DLL, python20.dll.  Nevertheless, I
	am willing to change the name of the Cygwin Python DLL, if desired.

	* configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately.
	* configure.in: Add Cygwin case to set LN appropriately.
	* configure.in: Add Cygwin case to set OPT appropriately.
	* configure.in: Add Cygwin case to set SO appropriately.
	* configure.in: Add Cygwin case to set LDSHARED appropriately.

	Should LDSHARED contain more flags?  For example,
	-Wl,--enable-auto-image-base, etc.?
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470


From noreply@sourceforge.net  Thu Nov 16 15:40:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Nov 2000 07:40:08 -0800
Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch
Message-ID: <200011161540.HAA01845@sf-web1.i.sourceforge.net>

Patch #102409 has been updated. 

Project: python
Category: Build
Status: Open
Summary: Cygwin Python DLL and Shared Extension Patch

Follow-Ups:

Date: 2000-Nov-16 07:40
By: jlt63

Comment:
This patch builds Cygwin Python with its core as a DLL -- similar to
the way that Win32 Python is built.  Once Cygwin Python is built as a
"shared library" (i.e., DLL), the procedure for building extensions is
the same as on UNIX platforms that support shared libraries.  It's as
easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f
Makefile.pre.in boot, make.

The following is the procedure to apply the patch and build Cygwin Python:

	$ patch -p0 <Cygwin-1.1.5-Python-2.0.patch
	$ autoheader
	$ autoconf
	$ configure --with-threads=no --with-libm= --with-suffix=.exe
	$ make
	$ make install

To test out shared extensions, try the following:

	$ cd Demo/extend
	$ make_shared
	$ python
	Python 2.0 (#1, Nov  1 2000, 08:51:39)
	[GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01
	Type "copyright", "credits" or "license" for more information.
	>>> import xx
	>>> dir(xx)
	['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj']
	>>> xx.foo(2, 3)
	5

As a more realistic example, I was able to build python-ldap 1.10alpha3
(http://sourceforge.net/projects/python-ldap) with the following minimal
changes:

	1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__)
	   as described in http://www.python.org/doc/FAQ.html#3.24
	2. added DL_EXPORT to init_ldap()

Note that there were no changes of any kind to the build files (i.e,
configure.in, Makefile.in, and Modules/Setup.in) or functionality changes
to the C source.

The following is an annotated ChangeLog for the patch:

Thu Nov 16 10:38:20 2000  Jason Tishler <jt@dothill.com>

	* Makefile.in: Add autoconf variable SET_DLLLIBRARY.
	* Makefile.in (altbininstall): Enhance altbininstall rule to also
	install the Cygwin Python DLL.
	* Makefile.in (libainstall): Change libainstall rule to install
	LDLIBRARY instead of LIBRARY.

	Will installing LDLIBRARY instead of LIBRARY break other
	platforms?  The terse description of LDLIBRARY in configure.in
	seems to indicate that possibly the original build procedure
	should be been installing it instead of LIBRARY.  Anyway, I am
	very willing to change the patch to install both LDLIBRARY and
	LIBRARY (if they are different) or some other suitable solution.

	* Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY.
	* Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build
	the Cygwin Python DLL.

	Should the body of this rule be hidden in a shell script?  I have 
	stumbled across various platform specific scripts like BeOS/ar-fake
	that has me thinking that this may be desirable.

	* Modules/makesetup: Add shell variable module and default its value
	to "module".
	* Modules/makesetup: Add Cygwin specific definitions to set shell
	variables module, CygwinFlags, and CygwinLibs appropriately.

	Is it undesirable to put platform specific code in makesetup?

	* Modules/makesetup: Add .def to the list of known file types.
	* Modules/makesetup: Change object rule to include CygwinFlags.
	* Modules/makesetup: Change to use shell variable module instead of
	hardcoded "module".
	* Modules/makesetup: Change shared extension rule to include
	CygwinLibs.
	* acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and
	DL_EXPORT.

	Is there a better way of accomplishing this without affecting config.h
	on all other autoconf supported platforms too?

	* configure.in: Add autoconf variable SET_DLLLIBRARY.
	* configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY
	appropriately.

	I have chosen to call the import library libpython$(VERSION).dll.a
	and the DLL libpython$(VERSION).dll.  Recently there has been a
	proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html)
	to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order
	to avoid clashing with Win32 versions of the same DLL.  I have stayed
	with libpython2.0.dll because it is more consistent with the UNIX
	naming convention and because there is no (current) possibility of
	clashing with the Win32 Python DLL, python20.dll.  Nevertheless, I
	am willing to change the name of the Cygwin Python DLL, if desired.

	* configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately.
	* configure.in: Add Cygwin case to set LN appropriately.
	* configure.in: Add Cygwin case to set OPT appropriately.
	* configure.in: Add Cygwin case to set SO appropriately.
	* configure.in: Add Cygwin case to set LDSHARED appropriately.

	Should LDSHARED contain more flags?  For example,
	-Wl,--enable-auto-image-base, etc.?
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470


From noreply@sourceforge.net  Thu Nov 16 18:01:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Nov 2000 10:01:28 -0800
Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch
Message-ID: <200011161801.KAA12622@sf-web2.i.sourceforge.net>

Patch #102409 has been updated. 

Project: python
Category: Build
Status: Open
Summary: Cygwin Python DLL and Shared Extension Patch

Follow-Ups:

Date: 2000-Nov-16 07:40
By: jlt63

Comment:
This patch builds Cygwin Python with its core as a DLL -- similar to
the way that Win32 Python is built.  Once Cygwin Python is built as a
"shared library" (i.e., DLL), the procedure for building extensions is
the same as on UNIX platforms that support shared libraries.  It's as
easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f
Makefile.pre.in boot, make.

The following is the procedure to apply the patch and build Cygwin Python:

	$ patch -p0 <Cygwin-1.1.5-Python-2.0.patch
	$ autoheader
	$ autoconf
	$ configure --with-threads=no --with-libm= --with-suffix=.exe
	$ make
	$ make install

To test out shared extensions, try the following:

	$ cd Demo/extend
	$ make_shared
	$ python
	Python 2.0 (#1, Nov  1 2000, 08:51:39)
	[GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01
	Type "copyright", "credits" or "license" for more information.
	>>> import xx
	>>> dir(xx)
	['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj']
	>>> xx.foo(2, 3)
	5

As a more realistic example, I was able to build python-ldap 1.10alpha3
(http://sourceforge.net/projects/python-ldap) with the following minimal
changes:

	1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__)
	   as described in http://www.python.org/doc/FAQ.html#3.24
	2. added DL_EXPORT to init_ldap()

Note that there were no changes of any kind to the build files (i.e,
configure.in, Makefile.in, and Modules/Setup.in) or functionality changes
to the C source.

The following is an annotated ChangeLog for the patch:

Thu Nov 16 10:38:20 2000  Jason Tishler <jt@dothill.com>

	* Makefile.in: Add autoconf variable SET_DLLLIBRARY.
	* Makefile.in (altbininstall): Enhance altbininstall rule to also
	install the Cygwin Python DLL.
	* Makefile.in (libainstall): Change libainstall rule to install
	LDLIBRARY instead of LIBRARY.

	Will installing LDLIBRARY instead of LIBRARY break other
	platforms?  The terse description of LDLIBRARY in configure.in
	seems to indicate that possibly the original build procedure
	should be been installing it instead of LIBRARY.  Anyway, I am
	very willing to change the patch to install both LDLIBRARY and
	LIBRARY (if they are different) or some other suitable solution.

	* Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY.
	* Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build
	the Cygwin Python DLL.

	Should the body of this rule be hidden in a shell script?  I have 
	stumbled across various platform specific scripts like BeOS/ar-fake
	that has me thinking that this may be desirable.

	* Modules/makesetup: Add shell variable module and default its value
	to "module".
	* Modules/makesetup: Add Cygwin specific definitions to set shell
	variables module, CygwinFlags, and CygwinLibs appropriately.

	Is it undesirable to put platform specific code in makesetup?

	* Modules/makesetup: Add .def to the list of known file types.
	* Modules/makesetup: Change object rule to include CygwinFlags.
	* Modules/makesetup: Change to use shell variable module instead of
	hardcoded "module".
	* Modules/makesetup: Change shared extension rule to include
	CygwinLibs.
	* acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and
	DL_EXPORT.

	Is there a better way of accomplishing this without affecting config.h
	on all other autoconf supported platforms too?

	* configure.in: Add autoconf variable SET_DLLLIBRARY.
	* configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY
	appropriately.

	I have chosen to call the import library libpython$(VERSION).dll.a
	and the DLL libpython$(VERSION).dll.  Recently there has been a
	proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html)
	to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order
	to avoid clashing with Win32 versions of the same DLL.  I have stayed
	with libpython2.0.dll because it is more consistent with the UNIX
	naming convention and because there is no (current) possibility of
	clashing with the Win32 Python DLL, python20.dll.  Nevertheless, I
	am willing to change the name of the Cygwin Python DLL, if desired.

	* configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately.
	* configure.in: Add Cygwin case to set LN appropriately.
	* configure.in: Add Cygwin case to set OPT appropriately.
	* configure.in: Add Cygwin case to set SO appropriately.
	* configure.in: Add Cygwin case to set LDSHARED appropriately.

	Should LDSHARED contain more flags?  For example,
	-Wl,--enable-auto-image-base, etc.?
-------------------------------------------------------

Date: 2000-Nov-16 10:01
By: nhv

Comment:
Incorporating this patch will make Cygwin a much
nicer enviroment for Python development.

I have beta tested this and it works as advertised
for me :-)

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470


From noreply@sourceforge.net  Thu Nov 16 21:12:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Nov 2000 13:12:43 -0800
Subject: [Patches] [Patch #102412] suuport for curses.setupterm
Message-ID: <200011162112.NAA04241@sf-web3.vaspecialprojects.com>

Patch #102412 has been updated. 

Project: python
Category: Modules
Status: Open
Summary: suuport for curses.setupterm

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102412&group_id=5470


From noreply@sourceforge.net  Thu Nov 16 21:20:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Nov 2000 13:20:08 -0800
Subject: [Patches] [Patch #102412] suuport for curses.setupterm
Message-ID: <200011162120.NAA04354@sf-web3.vaspecialprojects.com>

Patch #102412 has been updated. 

Project: python
Category: Modules
Status: Open
Summary: suuport for curses.setupterm

Follow-Ups:

Date: 2000-Nov-16 13:20
By: mwh

Comment:
(oh dear; i'll be seeing that typo in my inbox then...)

i recently found myself wanting to use terminfo routines without the rest of curses.  _cursesmodule.c now sprouts tigetstr & friends, but demands you call initscr first (which i don't want to do).

this patch attempts to sort this out.  I'm not convinced that it's 100% the right approach - but I would like to sort this problem out.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102412&group_id=5470


From noreply@sourceforge.net  Thu Nov 16 21:21:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Nov 2000 13:21:59 -0800
Subject: [Patches] [Patch #102412] suuport for curses.setupterm
Message-ID: <200011162121.NAA04401@sf-web3.vaspecialprojects.com>

Patch #102412 has been updated. 

Project: python
Category: Modules
Status: Open
Summary: suuport for curses.setupterm

Follow-Ups:

Date: 2000-Nov-16 13:20
By: mwh

Comment:
(oh dear; i'll be seeing that typo in my inbox then...)

i recently found myself wanting to use terminfo routines without the rest of curses.  _cursesmodule.c now sprouts tigetstr & friends, but demands you call initscr first (which i don't want to do).

this patch attempts to sort this out.  I'm not convinced that it's 100% the right approach - but I would like to sort this problem out.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102412&group_id=5470


From sancho.panza@talk21.com  Fri Nov 17 14:32:54 2000
From: sancho.panza@talk21.com (Mariah)
Date: Fri, 17 Nov 2000 14:32:54
Subject: [Patches] (no subject)
Message-ID: <20001117143614.DDDBE1D001@dinsdale.python.org>

http://www.ssp.co.uk
http://www.tip-ex.com
http://www.betex.com


From noreply@sourceforge.net  Fri Nov 17 23:11:07 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Nov 2000 15:11:07 -0800
Subject: [Patches] [Patch #102412] support for curses.setupterm
Message-ID: <200011172311.PAA31998@sf-web1.i.sourceforge.net>

Patch #102412 has been updated. 

Project: python
Category: Modules
Status: Open
Summary: support for curses.setupterm

Follow-Ups:

Date: 2000-Nov-16 13:20
By: mwh

Comment:
(oh dear; i'll be seeing that typo in my inbox then...)

i recently found myself wanting to use terminfo routines without the rest of curses.  _cursesmodule.c now sprouts tigetstr & friends, but demands you call initscr first (which i don't want to do).

this patch attempts to sort this out.  I'm not convinced that it's 100% the right approach - but I would like to sort this problem out.
-------------------------------------------------------

Date: 2000-Nov-17 15:11
By: akuchling

Comment:
Some comments:

* The setupterm wrapper should use the constants ERR and OK,
  not -1 and 0.

* Minor consistency nit: the rest of the code usually uses 'err' to hold error returns, not 'errret'.  (That's what the curs_terminfo man page uses, but I think I prefer this to be consistent.)

Make those two changes, and I approve the patch.

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102412&group_id=5470


From noreply@sourceforge.net  Sat Nov 18 00:08:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Nov 2000 16:08:21 -0800
Subject: [Patches] [Patch #102412] support for curses.setupterm
Message-ID: <200011180008.QAA09176@sf-web2.i.sourceforge.net>

Patch #102412 has been updated. 

Project: python
Category: Modules
Status: Open
Summary: support for curses.setupterm

Follow-Ups:

Date: 2000-Nov-16 13:20
By: mwh

Comment:
(oh dear; i'll be seeing that typo in my inbox then...)

i recently found myself wanting to use terminfo routines without the rest of curses.  _cursesmodule.c now sprouts tigetstr & friends, but demands you call initscr first (which i don't want to do).

this patch attempts to sort this out.  I'm not convinced that it's 100% the right approach - but I would like to sort this problem out.
-------------------------------------------------------

Date: 2000-Nov-17 15:11
By: akuchling

Comment:
Some comments:

* The setupterm wrapper should use the constants ERR and OK,
  not -1 and 0.

* Minor consistency nit: the rest of the code usually uses 'err' to hold error returns, not 'errret'.  (That's what the curs_terminfo man page uses, but I think I prefer this to be consistent.)

Make those two changes, and I approve the patch.

-------------------------------------------------------

Date: 2000-Nov-17 16:08
By: mwh

Comment:
this patch uses ERR slightly more, but still uses a literal -1 in the places man curs_terminfo does, and changes errret to err.  is that what you meant?

this patch also performs prunage on the list of unimplemented functions.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102412&group_id=5470


From noreply@sourceforge.net  Sat Nov 18 10:48:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 18 Nov 2000 02:48:31 -0800
Subject: [Patches] [Patch #102412] support for curses.setupterm
Message-ID: <200011181048.CAA08636@sf-web1.i.sourceforge.net>

Patch #102412 has been updated. 

Project: python
Category: Modules
Status: Open
Summary: support for curses.setupterm

Follow-Ups:

Date: 2000-Nov-16 13:20
By: mwh

Comment:
(oh dear; i'll be seeing that typo in my inbox then...)

i recently found myself wanting to use terminfo routines without the rest of curses.  _cursesmodule.c now sprouts tigetstr & friends, but demands you call initscr first (which i don't want to do).

this patch attempts to sort this out.  I'm not convinced that it's 100% the right approach - but I would like to sort this problem out.
-------------------------------------------------------

Date: 2000-Nov-17 15:11
By: akuchling

Comment:
Some comments:

* The setupterm wrapper should use the constants ERR and OK,
  not -1 and 0.

* Minor consistency nit: the rest of the code usually uses 'err' to hold error returns, not 'errret'.  (That's what the curs_terminfo man page uses, but I think I prefer this to be consistent.)

Make those two changes, and I approve the patch.

-------------------------------------------------------

Date: 2000-Nov-17 16:08
By: mwh

Comment:
this patch uses ERR slightly more, but still uses a literal -1 in the places man curs_terminfo does, and changes errret to err.  is that what you meant?

this patch also performs prunage on the list of unimplemented functions.
-------------------------------------------------------

Date: 2000-Nov-18 02:48
By: mwh

Comment:
oops - actually upload patch...
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102412&group_id=5470


From noreply@sourceforge.net  Sat Nov 18 17:39:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 18 Nov 2000 09:39:03 -0800
Subject: [Patches] [Patch #102412] support for curses.setupterm
Message-ID: <200011181739.JAA14447@sf-web1.i.sourceforge.net>

Patch #102412 has been updated. 

Project: python
Category: Modules
Status: Accepted
Summary: support for curses.setupterm

Follow-Ups:

Date: 2000-Nov-16 13:20
By: mwh

Comment:
(oh dear; i'll be seeing that typo in my inbox then...)

i recently found myself wanting to use terminfo routines without the rest of curses.  _cursesmodule.c now sprouts tigetstr & friends, but demands you call initscr first (which i don't want to do).

this patch attempts to sort this out.  I'm not convinced that it's 100% the right approach - but I would like to sort this problem out.
-------------------------------------------------------

Date: 2000-Nov-17 15:11
By: akuchling

Comment:
Some comments:

* The setupterm wrapper should use the constants ERR and OK,
  not -1 and 0.

* Minor consistency nit: the rest of the code usually uses 'err' to hold error returns, not 'errret'.  (That's what the curs_terminfo man page uses, but I think I prefer this to be consistent.)

Make those two changes, and I approve the patch.

-------------------------------------------------------

Date: 2000-Nov-17 16:08
By: mwh

Comment:
this patch uses ERR slightly more, but still uses a literal -1 in the places man curs_terminfo does, and changes errret to err.  is that what you meant?

this patch also performs prunage on the list of unimplemented functions.
-------------------------------------------------------

Date: 2000-Nov-18 02:48
By: mwh

Comment:
oops - actually upload patch...
-------------------------------------------------------

Date: 2000-Nov-18 09:39
By: akuchling

Comment:
OK -- looks fine now, so I'll check it in and add setupterm() to the docs
for the curses module.  (err... why don't you have checkin privileges?  I suspect you could readily get them just by asking...)

Why did you prune the list of unimplemented functions?  Are some of them outdated?
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102412&group_id=5470


From noreply@sourceforge.net  Mon Nov 20 15:57:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Nov 2000 07:57:53 -0800
Subject: [Patches] [Patch #102453] Modified urlencode in urllib to accept more types
Message-ID: <200011201557.HAA24988@sf-web1.i.sourceforge.net>

Patch #102453 has been updated. 

Project: python
Category: library
Status: Open
Summary: Modified urlencode in urllib to accept more types

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102453&group_id=5470


From noreply@sourceforge.net  Tue Nov 21 11:18:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Nov 2000 03:18:31 -0800
Subject: [Patches] [Patch #102453] Modified urlencode in urllib to accept more types
Message-ID: <200011211118.DAA11084@sf-web1.i.sourceforge.net>

Patch #102453 has been updated. 

Project: python
Category: library
Status: Open
Summary: Modified urlencode in urllib to accept more types

Follow-Ups:

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 <wink>

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102453&group_id=5470


From noreply@sourceforge.net  Wed Nov 22 03:09:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Nov 2000 19:09:04 -0800
Subject: [Patches] [Patch #102412] support for curses.setupterm
Message-ID: <200011220309.TAA10048@sf-web3.vaspecialprojects.com>

Patch #102412 has been updated. 

Project: python
Category: Modules
Status: Closed
Summary: support for curses.setupterm

Follow-Ups:

Date: 2000-Nov-16 13:20
By: mwh

Comment:
(oh dear; i'll be seeing that typo in my inbox then...)

i recently found myself wanting to use terminfo routines without the rest of curses.  _cursesmodule.c now sprouts tigetstr & friends, but demands you call initscr first (which i don't want to do).

this patch attempts to sort this out.  I'm not convinced that it's 100% the right approach - but I would like to sort this problem out.
-------------------------------------------------------

Date: 2000-Nov-17 15:11
By: akuchling

Comment:
Some comments:

* The setupterm wrapper should use the constants ERR and OK,
  not -1 and 0.

* Minor consistency nit: the rest of the code usually uses 'err' to hold error returns, not 'errret'.  (That's what the curs_terminfo man page uses, but I think I prefer this to be consistent.)

Make those two changes, and I approve the patch.

-------------------------------------------------------

Date: 2000-Nov-17 16:08
By: mwh

Comment:
this patch uses ERR slightly more, but still uses a literal -1 in the places man curs_terminfo does, and changes errret to err.  is that what you meant?

this patch also performs prunage on the list of unimplemented functions.
-------------------------------------------------------

Date: 2000-Nov-18 02:48
By: mwh

Comment:
oops - actually upload patch...
-------------------------------------------------------

Date: 2000-Nov-18 09:39
By: akuchling

Comment:
OK -- looks fine now, so I'll check it in and add setupterm() to the docs
for the curses module.  (err... why don't you have checkin privileges?  I suspect you could readily get them just by asking...)

Why did you prune the list of unimplemented functions?  Are some of them outdated?
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102412&group_id=5470


From noreply@sourceforge.net  Wed Nov 22 03:13:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Nov 2000 19:13:06 -0800
Subject: [Patches] [Patch #102469] Use glibc's getline() extension
Message-ID: <200011220313.TAA10086@sf-web3.vaspecialprojects.com>

Patch #102469 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: Use glibc's getline() extension

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102469&group_id=5470


From noreply@sourceforge.net  Wed Nov 22 03:15:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Nov 2000 19:15:00 -0800
Subject: [Patches] [Patch #102469] Use glibc's getline() extension
Message-ID: <200011220315.TAA10131@sf-web3.vaspecialprojects.com>

Patch #102469 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: Use glibc's getline() extension

Follow-Ups:

Date: 2000-Nov-21 19:15
By: akuchling

Comment:
(Inspired by a suggestion on comp.lang.python.) 

This patch changes the get_line() C function to use getline(),
a GNU libc extension, when it's available.  It does have a significant
impact; on my Linux box, reading the 6779-line quotations.xml
file takes 0.15 sec of CPU time using getline(), 0.45 sec without it.

Anyone know if C99 is adding an equivalent function?

Benchmark script:
import sys, time

f=open(sys.argv[1], 'r')

print 'Timing readline() for all lines'
cs = time.clock() ; start = time.time()
while 1:
    L = f.readline()
    if L == "": break

ce = time.clock() ; end = time.time()
print 'CPU time:', ce-cs, 'sec'
print 'Wall clock:', end-start, 'sec'


-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102469&group_id=5470


From noreply@sourceforge.net  Wed Nov 22 09:30:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 22 Nov 2000 01:30:58 -0800
Subject: [Patches] [Patch #102469] Use glibc's getline() extension
Message-ID: <200011220930.BAA07448@sf-web2.i.sourceforge.net>

Patch #102469 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: Use glibc's getline() extension

Follow-Ups:

Date: 2000-Nov-21 19:15
By: akuchling

Comment:
(Inspired by a suggestion on comp.lang.python.) 

This patch changes the get_line() C function to use getline(),
a GNU libc extension, when it's available.  It does have a significant
impact; on my Linux box, reading the 6779-line quotations.xml
file takes 0.15 sec of CPU time using getline(), 0.45 sec without it.

Anyone know if C99 is adding an equivalent function?

Benchmark script:
import sys, time

f=open(sys.argv[1], 'r')

print 'Timing readline() for all lines'
cs = time.clock() ; start = time.time()
while 1:
    L = f.readline()
    if L == "": break

ce = time.clock() ; end = time.time()
print 'CPU time:', ce-cs, 'sec'
print 'Wall clock:', end-start, 'sec'


-------------------------------------------------------

Date: 2000-Nov-22 01:30
By: moshez

Comment:
In theory, I like this. In actual life, I'm a bit afraid of the implementation. You're just checking for the existence of a function named "getline". What if some other compiler
has such a function, and its semantics or signature differs? There's no pertinent standard on this. Maybe if would be best to enable if only if HAVE_GETLINE and something else
(like some define Glibc gives, if there is one).

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102469&group_id=5470


From noreply@sourceforge.net  Wed Nov 22 11:48:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 22 Nov 2000 03:48:04 -0800
Subject: [Patches] [Patch #102208] Allow jython to use StringIO.py without an errno module.
Message-ID: <200011221148.DAA09406@sf-web2.i.sourceforge.net>

Patch #102208 has been updated. 

Project: python
Category: library
Status: Open
Summary: Allow jython to use StringIO.py without an errno module.

Follow-Ups:

Date: 2000-Nov-22 03:48
By: moshez

Comment:
This seems very reasonable -- it actually eliminates a dependancy which is problematic anyway -- it makes StringIO.py much more platform independant. +1!
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102208&group_id=5470


From noreply@sourceforge.net  Wed Nov 22 21:37:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 22 Nov 2000 13:37:11 -0800
Subject: [Patches] [Patch #102477] Allow xml.dom.pulldom to use alternate DOM implementations
Message-ID: <200011222137.NAA13339@sf-web1.i.sourceforge.net>

Patch #102477 has been updated. 

Project: python
Category: XML
Status: Open
Summary: Allow xml.dom.pulldom to use alternate DOM implementations

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102477&group_id=5470


From noreply@sourceforge.net  Wed Nov 22 21:39:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 22 Nov 2000 13:39:26 -0800
Subject: [Patches] [Patch #102477] Allow xml.dom.pulldom to use alternate DOM implementations
Message-ID: <200011222139.NAA20815@sf-web2.i.sourceforge.net>

Patch #102477 has been updated. 

Project: python
Category: XML
Status: Open
Summary: Allow xml.dom.pulldom to use alternate DOM implementations

Follow-Ups:

Date: 2000-Nov-22 13:39
By: fdrake

Comment:
This modifies PullDOM.__init__() to accept a Document object as a parameter, and changes PullDOM.startDocument() to use that object or create a one using minidom if necessary.  This allows all existing client code to continue to work unchanged, while supporting use of alternate DOM implementations.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102477&group_id=5470


From noreply@sourceforge.net  Thu Nov 23 06:24:07 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 22 Nov 2000 22:24:07 -0800
Subject: [Patches] [Patch #102477] Allow xml.dom.pulldom to use alternate DOM implementations
Message-ID: <200011230624.WAA20087@sf-web1.i.sourceforge.net>

Patch #102477 has been updated. 

Project: python
Category: XML
Status: Open
Summary: Allow xml.dom.pulldom to use alternate DOM implementations

Follow-Ups:

Date: 2000-Nov-22 13:39
By: fdrake

Comment:
This modifies PullDOM.__init__() to accept a Document object as a parameter, and changes PullDOM.startDocument() to use that object or create a one using minidom if necessary.  This allows all existing client code to continue to work unchanged, while supporting use of alternate DOM implementations.
-------------------------------------------------------

Date: 2000-Nov-22 22:24
By: fdrake

Comment:
Revised patch based on Greg Stein's note that the original would not create a new Document instance for each call to startDocument(); this version takes a document factory instead of a document object, and creates a new document with each call to startDocument().

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102477&group_id=5470


From noreply@sourceforge.net  Thu Nov 23 16:06:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Nov 2000 08:06:45 -0800
Subject: [Patches] [Patch #102485] minidom.py: Check for legal children
Message-ID: <200011231606.IAA08008@sf-web3.vaspecialprojects.com>

Patch #102485 has been updated. 

Project: python
Category: XML
Status: Open
Summary: minidom.py: Check for legal children

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102485&group_id=5470


From noreply@sourceforge.net  Thu Nov 23 16:08:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Nov 2000 08:08:20 -0800
Subject: [Patches] [Patch #102485] minidom.py: Check for legal children
Message-ID: <200011231608.IAA08045@sf-web3.vaspecialprojects.com>

Patch #102485 has been updated. 

Project: python
Category: XML
Status: Open
Summary: minidom.py: Check for legal children

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102485&group_id=5470


From noreply@sourceforge.net  Thu Nov 23 16:24:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Nov 2000 08:24:56 -0800
Subject: [Patches] [Patch #102485] minidom.py: Check for legal children
Message-ID: <200011231624.IAA08311@sf-web3.vaspecialprojects.com>

Patch #102485 has been updated. 

Project: python
Category: XML
Status: Open
Summary: minidom.py: Check for legal children

Follow-Ups:

Date: 2000-Nov-23 08:24
By: akuchling

Comment:
Revised version of patch; the first version was generated against a really
old version of minidom.py.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102485&group_id=5470


From noreply@sourceforge.net  Fri Nov 24 02:27:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Nov 2000 18:27:19 -0800
Subject: [Patches] [Patch #102492] minidom/pulldom:  remove nodes already in the tree
Message-ID: <200011240227.SAA05253@sf-web1.i.sourceforge.net>

Patch #102492 has been updated. 

Project: python
Category: XML
Status: Open
Summary: minidom/pulldom:  remove nodes already in the tree

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102492&group_id=5470


From noreply@sourceforge.net  Fri Nov 24 02:32:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Nov 2000 18:32:59 -0800
Subject: [Patches] [Patch #102492] minidom/pulldom:  remove nodes already in the tree
Message-ID: <200011240232.SAA05302@sf-web1.i.sourceforge.net>

Patch #102492 has been updated. 

Project: python
Category: XML
Status: Open
Summary: minidom/pulldom:  remove nodes already in the tree

Follow-Ups:

Date: 2000-Nov-23 18:32
By: akuchling

Comment:
This patch attempts to fix bug #116677:                         "minidom:Node.appendChild() has        wrong semantics".
It changes the appendChild,  insertBefore, etc. methods 
to remove the node being added if it's already in the tree.
The patch also fixes some spots where the previousSibling/nextSibling pointers aren't being properly updated.

Some changes to pulldom.py were required, and I'm unsure
about them.  Mostly they consist of using the published minidom interface instead of directly setting .parentNode.  Judging by my debug printouts, pulldom ends up doing redundant work after this patch -- every node is added to the tree *twice*.  However the resulting tree does
seem to be correct.

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102492&group_id=5470


From noreply@sourceforge.net  Fri Nov 24 10:18:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 Nov 2000 02:18:46 -0800
Subject: [Patches] [Patch #102498] imputil.py: uninstall method & import of .pyc-files
Message-ID: <200011241018.CAA17608@sf-web2.i.sourceforge.net>

Patch #102498 has been updated. 

Project: python
Category: Modules
Status: Open
Summary: imputil.py: uninstall method & import of .pyc-files

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102498&group_id=5470


From noreply@sourceforge.net  Mon Nov 27 15:47:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 07:47:14 -0800
Subject: [Patches] [Patch #101162] a Python/C API testing framework (simple simple)
Message-ID: <200011271547.HAA19008@sf-web2.i.sourceforge.net>

Patch #101162 has been updated. 

Project: python
Category: Build
Status: Open
Summary: a Python/C API testing framework (simple simple)

Follow-Ups:

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. <wink>

-------------------------------------------------------

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  Mon Nov 27 18:09:36 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 10:09:36 -0800
Subject: [Patches] [Patch #102548] fix for bug #121013
Message-ID: <200011271809.KAA16562@sf-web1.i.sourceforge.net>

Patch #102548 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: fix for bug #121013

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102548&group_id=5470


From noreply@sourceforge.net  Mon Nov 27 18:11:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 10:11:47 -0800
Subject: [Patches] [Patch #102548] fix for bug #121013
Message-ID: <200011271811.KAA16606@sf-web1.i.sourceforge.net>

Patch #102548 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: fix for bug #121013

Follow-Ups:

Date: 2000-Nov-27 10:11
By: mwh

Comment:
time to kick yourself!
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102548&group_id=5470


From noreply@sourceforge.net  Mon Nov 27 18:46:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 10:46:37 -0800
Subject: [Patches] [Patch #102548] fix for bug #121013
Message-ID: <200011271846.KAA22457@sf-web2.i.sourceforge.net>

Patch #102548 has been updated. 

Project: python
Category: core (C code)
Status: Closed
Summary: fix for bug #121013

Follow-Ups:

Date: 2000-Nov-27 10:11
By: mwh

Comment:
time to kick yourself!
-------------------------------------------------------

Date: 2000-Nov-27 10:46
By: gvanrossum

Comment:
OK. Checked in.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102548&group_id=5470


From noreply@sourceforge.net  Mon Nov 27 20:37:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 12:37:51 -0800
Subject: [Patches] [Patch #102549] simpler, faster(!) implementation of string.join
Message-ID: <200011272037.MAA19731@sf-web1.i.sourceforge.net>

Patch #102549 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: simpler, faster(!) implementation of string.join

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102549&group_id=5470


From noreply@sourceforge.net  Mon Nov 27 20:40:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 12:40:54 -0800
Subject: [Patches] [Patch #102549] simpler, faster(!) implementation of string.join
Message-ID: <200011272040.MAA19780@sf-web1.i.sourceforge.net>

Patch #102549 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: simpler, faster(!) implementation of string.join

Follow-Ups:

Date: 2000-Nov-27 12:40
By: mwh

Comment:
attempting to fix a but in string.join, I realised that I didn't understand the current implementation.  So I rewrote it.  In doing so, I found the bug, but as my rewrite seems to be a little faster I thought I'd submit it.

The additional clarity is the main point though.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102549&group_id=5470


From noreply@sourceforge.net  Mon Nov 27 21:32:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:32:22 -0800
Subject: [Patches] [Patch #102553] Fix for handling jython's PyStringMap
Message-ID: <200011272132.NAA17980@sf-web3.vaspecialprojects.com>

Patch #102553 has been updated. 

Project: python
Category: None
Status: Open
Summary: Fix for handling jython's PyStringMap

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102553&group_id=5470


From noreply@sourceforge.net  Mon Nov 27 21:26:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:26:34 -0800
Subject: [Patches] [Patch #102354] Fix dynamic module linking on Mac OSX/OSXS
Message-ID: <200011272126.NAA25432@sf-web2.i.sourceforge.net>

Patch #102354 has been updated. 

Project: python
Category: Build
Status: Open
Summary: Fix dynamic module linking on Mac OSX/OSXS

Follow-Ups:

Date: 2000-Nov-11 11:05
By: bbum

Comment:
*** /tmp/Python-2.0/configure.in        Mon Oct 16 17:50:06 2000
--- configure.in        Sat Nov 11 13:54:43 2000
***************
*** 573,581 ****
          Darwin/*|next/*) 
                if test "$ns_dyld"
                then 
!                 if test "$ac_sys_system" = Darwin
!                 then LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress'
!                 else LDSHARED='$(CC) $(LDFLAGS) -bundle -prebind'
                  fi
                else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r';
                fi
--- 573,579 ----
          Darwin/*|next/*) 
                if test "$ns_dyld"
                then 
!                 LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress'
                  fi
                else LDSHARED='$(CC) $(CFLAGS) -nostdlib -r';
                fi
***************
*** 646,652 ****
        # in System.framework; otherwise, __objcInit (referenced in
        # crt1.o) gets erroneously defined as common, which breaks dynamic
        # loading of any modules which reference it in System.framework
!       next/4*|next/5*) LINKFORSHARED="-u __dummy -framework System" ;;
        Darwin/*) LINKFORSHARED="-framework System" ;;
        SCO_SV*) LINKFORSHARED="-Bdynamic -dy -Wl,-Bexport";;
        ReliantUNIX*) LINKFORSHARED="-W1 -Blargedynsym";;
--- 644,650 ----
        # in System.framework; otherwise, __objcInit (referenced in
        # crt1.o) gets erroneously defined as common, which breaks dynamic
        # loading of any modules which reference it in System.framework
!       next/4*|next/5*) LINKFORSHARED="-u __dummy -framework System -framework Foundation" ;;
        Darwin/*) LINKFORSHARED="-framework System" ;;
        SCO_SV*) LINKFORSHARED="-Bdynamic -dy -Wl,-Bexport";;
        ReliantUNIX*) LINKFORSHARED="-W1 -Blargedynsym";;

-------------------------------------------------------

Date: 2000-Nov-11 11:07
By: bbum

Comment:
The addition of -framework Foundation is required to allow dynamically loaded modules to have access to the Objective-C runtiem under OSXS.

This *may* also be required under Darwin/OSX, but-- if that is the case-- it will be submitted as a separate patch once I restore my OSX work environment and can verify that it is the case.
-------------------------------------------------------

Date: 2000-Nov-12 02:07
By: loewis

Comment:
If you add an option that is required for something, then it would be good to add a comment to indicate what the something is. Also, are you sure that linking with the Foundation framework is absolutely necessary? Would it be possible for extension modules to link with the framework themselves if they need it?
-------------------------------------------------------

Date: 2000-Nov-12 08:22
By: bbum

Comment:
(It isn't clear where one can actually document a patch when uploading the first version.   I'll have to make sure and add a comment after the initial upload-- or document the code better.  Sorry about that.)

The Foundation framework must be linked into the python executable if any dynamically loaded module is to ever use the Objective-C runtime.   At least, I haven't found a workaround that allows one to link it into the loadable module.

If it isn't, then the load dies with one of two erros depending on platform:

OSX:   dies with a duplicate symbol error on __objcInit.

OSXS:  dies with a "objc: link required classes into application"



-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102354&group_id=5470


From noreply@sourceforge.net  Mon Nov 27 21:26:41 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:26:41 -0800
Subject: [Patches] [Patch #102357] Add support for frameworks and objective-c source.  Uesful for both GnuStep and for OSXS/OSX/Darwin.
Message-ID: <200011272126.NAA25439@sf-web2.i.sourceforge.net>

Patch #102357 has been updated. 

Project: python
Category: Modules
Status: Open
Summary: Add support for frameworks and objective-c source.  Uesful for both GnuStep and for OSXS/OSX/Darwin.

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102357&group_id=5470


From noreply@sourceforge.net  Mon Nov 27 21:33:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:33:25 -0800
Subject: [Patches] [Patch #102362] Support dynamic module loading under OSX [including support for modules w/Objective-C]
Message-ID: <200011272133.NAA18000@sf-web3.vaspecialprojects.com>

Patch #102362 has been updated. 

Project: python
Category: None
Status: Open
Summary: Support dynamic module loading under OSX [including support for modules w/Objective-C]

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102362&group_id=5470


From noreply@sourceforge.net  Mon Nov 27 21:26:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:26:59 -0800
Subject: [Patches] [Patch #102553] Fix for handling jython's PyStringMap
Message-ID: <200011272126.NAA25447@sf-web2.i.sourceforge.net>

Patch #102553 has been updated. 

Project: python
Category: None
Status: Open
Summary: Fix for handling jython's PyStringMap

Follow-Ups:

Date: 2000-Nov-27 13:26
By: bckfnn

Comment:
This change matches similar code in pickle.py and will allow jython instances to be deepcopied.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102553&group_id=5470


From noreply@sourceforge.net  Mon Nov 27 21:32:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:32:52 -0800
Subject: [Patches] [Patch #102337] revised CALL_FUNCTION implementation
Message-ID: <200011272132.NAA17989@sf-web3.vaspecialprojects.com>

Patch #102337 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: revised CALL_FUNCTION implementation

Follow-Ups:

Date: 2000-Nov-08 16:08
By: jhylton

Comment:
This is a first draft patch that revises the CALL_FUNCTION implementation.  The first part of the revision breaks the long inline implementation into a series of function calls.  Each of the function calls has some small local optimizations (e.g. PyMethod_GET_SELF instead of PyMethod_GetSelf).

One problem that needs to be figured out is how these functions can cleanly access the stack_pointer local var of eval_code2.  The current approach is a bit messy.


-------------------------------------------------------

Date: 2000-Nov-08 16:29
By: jhylton

Comment:
A trivial fix to the logic keeps keyword arguments fast.

-------------------------------------------------------

Date: 2000-Nov-09 01:50
By: lemburg

Comment:
The patch looks ok, but I'm still missing the cleanup of the
PyEval_CallXXX() APIs which the patch I sent you included.

Some cosmetic issues:
1. your new APIs should be static and start with an underscore
  (e.g. _Py_CallFunctions)
2. you should add some "register" markers to the function call
  definitions -- this helps compilers such as gcc when inlining functions

-------------------------------------------------------

Date: 2000-Nov-09 05:59
By: Nobody

Comment:
Haven't seen the patch yet, but one remark on static functions: these should *not* have an underscore and *not* have a _Py_ prefix.

The _Py_ prefix is for stuff that cannot be static, because it needs to be called from another file, but is not intended to be a public API (so it could disappear or change in a future version without breaking user code).

There are a few exceptions (_Py_ functions that are part of the public API); these are either historical accidents or need to be used with great care only by wizards.

--Guido
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102337&group_id=5470


From noreply@sourceforge.net  Mon Nov 27 21:27:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:27:58 -0800
Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch
Message-ID: <200011272127.NAA20759@sf-web1.i.sourceforge.net>

Patch #102409 has been updated. 

Project: python
Category: Build
Status: Open
Summary: Cygwin Python DLL and Shared Extension Patch

Follow-Ups:

Date: 2000-Nov-16 07:40
By: jlt63

Comment:
This patch builds Cygwin Python with its core as a DLL -- similar to
the way that Win32 Python is built.  Once Cygwin Python is built as a
"shared library" (i.e., DLL), the procedure for building extensions is
the same as on UNIX platforms that support shared libraries.  It's as
easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f
Makefile.pre.in boot, make.

The following is the procedure to apply the patch and build Cygwin Python:

	$ patch -p0 <Cygwin-1.1.5-Python-2.0.patch
	$ autoheader
	$ autoconf
	$ configure --with-threads=no --with-libm= --with-suffix=.exe
	$ make
	$ make install

To test out shared extensions, try the following:

	$ cd Demo/extend
	$ make_shared
	$ python
	Python 2.0 (#1, Nov  1 2000, 08:51:39)
	[GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01
	Type "copyright", "credits" or "license" for more information.
	>>> import xx
	>>> dir(xx)
	['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj']
	>>> xx.foo(2, 3)
	5

As a more realistic example, I was able to build python-ldap 1.10alpha3
(http://sourceforge.net/projects/python-ldap) with the following minimal
changes:

	1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__)
	   as described in http://www.python.org/doc/FAQ.html#3.24
	2. added DL_EXPORT to init_ldap()

Note that there were no changes of any kind to the build files (i.e,
configure.in, Makefile.in, and Modules/Setup.in) or functionality changes
to the C source.

The following is an annotated ChangeLog for the patch:

Thu Nov 16 10:38:20 2000  Jason Tishler <jt@dothill.com>

	* Makefile.in: Add autoconf variable SET_DLLLIBRARY.
	* Makefile.in (altbininstall): Enhance altbininstall rule to also
	install the Cygwin Python DLL.
	* Makefile.in (libainstall): Change libainstall rule to install
	LDLIBRARY instead of LIBRARY.

	Will installing LDLIBRARY instead of LIBRARY break other
	platforms?  The terse description of LDLIBRARY in configure.in
	seems to indicate that possibly the original build procedure
	should be been installing it instead of LIBRARY.  Anyway, I am
	very willing to change the patch to install both LDLIBRARY and
	LIBRARY (if they are different) or some other suitable solution.

	* Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY.
	* Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build
	the Cygwin Python DLL.

	Should the body of this rule be hidden in a shell script?  I have 
	stumbled across various platform specific scripts like BeOS/ar-fake
	that has me thinking that this may be desirable.

	* Modules/makesetup: Add shell variable module and default its value
	to "module".
	* Modules/makesetup: Add Cygwin specific definitions to set shell
	variables module, CygwinFlags, and CygwinLibs appropriately.

	Is it undesirable to put platform specific code in makesetup?

	* Modules/makesetup: Add .def to the list of known file types.
	* Modules/makesetup: Change object rule to include CygwinFlags.
	* Modules/makesetup: Change to use shell variable module instead of
	hardcoded "module".
	* Modules/makesetup: Change shared extension rule to include
	CygwinLibs.
	* acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and
	DL_EXPORT.

	Is there a better way of accomplishing this without affecting config.h
	on all other autoconf supported platforms too?

	* configure.in: Add autoconf variable SET_DLLLIBRARY.
	* configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY
	appropriately.

	I have chosen to call the import library libpython$(VERSION).dll.a
	and the DLL libpython$(VERSION).dll.  Recently there has been a
	proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html)
	to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order
	to avoid clashing with Win32 versions of the same DLL.  I have stayed
	with libpython2.0.dll because it is more consistent with the UNIX
	naming convention and because there is no (current) possibility of
	clashing with the Win32 Python DLL, python20.dll.  Nevertheless, I
	am willing to change the name of the Cygwin Python DLL, if desired.

	* configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately.
	* configure.in: Add Cygwin case to set LN appropriately.
	* configure.in: Add Cygwin case to set OPT appropriately.
	* configure.in: Add Cygwin case to set SO appropriately.
	* configure.in: Add Cygwin case to set LDSHARED appropriately.

	Should LDSHARED contain more flags?  For example,
	-Wl,--enable-auto-image-base, etc.?
-------------------------------------------------------

Date: 2000-Nov-16 10:01
By: nhv

Comment:
Incorporating this patch will make Cygwin a much
nicer enviroment for Python development.

I have beta tested this and it works as advertised
for me :-)

-------------------------------------------------------

Date: 2000-Nov-27 13:27
By: gvanrossum

Comment:
Tim...  Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added!
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470


From noreply@sourceforge.net  Mon Nov 27 21:37:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:37:50 -0800
Subject: [Patches] [Patch #102469] Use glibc's getline() extension
Message-ID: <200011272137.NAA18103@sf-web3.vaspecialprojects.com>

Patch #102469 has been updated. 

Project: python
Category: core (C code)
Status: Accepted
Summary: Use glibc's getline() extension

Follow-Ups:

Date: 2000-Nov-21 19:15
By: akuchling

Comment:
(Inspired by a suggestion on comp.lang.python.) 

This patch changes the get_line() C function to use getline(),
a GNU libc extension, when it's available.  It does have a significant
impact; on my Linux box, reading the 6779-line quotations.xml
file takes 0.15 sec of CPU time using getline(), 0.45 sec without it.

Anyone know if C99 is adding an equivalent function?

Benchmark script:
import sys, time

f=open(sys.argv[1], 'r')

print 'Timing readline() for all lines'
cs = time.clock() ; start = time.time()
while 1:
    L = f.readline()
    if L == "": break

ce = time.clock() ; end = time.time()
print 'CPU time:', ce-cs, 'sec'
print 'Wall clock:', end-start, 'sec'


-------------------------------------------------------

Date: 2000-Nov-22 01:30
By: moshez

Comment:
In theory, I like this. In actual life, I'm a bit afraid of the implementation. You're just checking for the existence of a function named "getline". What if some other compiler
has such a function, and its semantics or signature differs? There's no pertinent standard on this. Maybe if would be best to enable if only if HAVE_GETLINE and something else
(like some define Glibc gives, if there is one).

-------------------------------------------------------

Date: 2000-Nov-27 13:37
By: gvanrossum

Comment:
I think Moshe is a little too worried here. Let's enable this. If there's a platform that has a different getline in its libc we'll find out soon enough (at the latest during alpha testing).

Andrew, go ahead and check it in.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102469&group_id=5470


From noreply@sourceforge.net  Mon Nov 27 21:38:33 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:38:33 -0800
Subject: [Patches] [Patch #102477] Allow xml.dom.pulldom to use alternate DOM implementations
Message-ID: <200011272138.NAA18114@sf-web3.vaspecialprojects.com>

Patch #102477 has been updated. 

Project: python
Category: XML
Status: Open
Summary: Allow xml.dom.pulldom to use alternate DOM implementations

Follow-Ups:

Date: 2000-Nov-22 13:39
By: fdrake

Comment:
This modifies PullDOM.__init__() to accept a Document object as a parameter, and changes PullDOM.startDocument() to use that object or create a one using minidom if necessary.  This allows all existing client code to continue to work unchanged, while supporting use of alternate DOM implementations.
-------------------------------------------------------

Date: 2000-Nov-22 22:24
By: fdrake

Comment:
Revised patch based on Greg Stein's note that the original would not create a new Document instance for each call to startDocument(); this version takes a document factory instead of a document object, and creates a new document with each call to startDocument().

-------------------------------------------------------

Date: 2000-Nov-27 13:38
By: gvanrossum

Comment:
Fred, please pick someone to review this and assign it to them.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102477&group_id=5470


From noreply@sourceforge.net  Mon Nov 27 21:32:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:32:52 -0800
Subject: [Patches] [Patch #102549] simpler, faster(!) implementation of string.join
Message-ID: <200011272132.NAA20862@sf-web1.i.sourceforge.net>

Patch #102549 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: simpler, faster(!) implementation of string.join

Follow-Ups:

Date: 2000-Nov-27 12:40
By: mwh

Comment:
attempting to fix a but in string.join, I realised that I didn't understand the current implementation.  So I rewrote it.  In doing so, I found the bug, but as my rewrite seems to be a little faster I thought I'd submit it.

The additional clarity is the main point though.
-------------------------------------------------------

Date: 2000-Nov-27 13:32
By: gvanrossum

Comment:
Tim -- can you review this?
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102549&group_id=5470


From noreply@sourceforge.net  Mon Nov 27 21:39:49 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:39:49 -0800
Subject: [Patches] [Patch #102498] imputil.py: uninstall method & import of .pyc-files
Message-ID: <200011272139.NAA18150@sf-web3.vaspecialprojects.com>

Patch #102498 has been updated. 

Project: python
Category: Modules
Status: Open
Summary: imputil.py: uninstall method & import of .pyc-files

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102498&group_id=5470


From noreply@sourceforge.net  Mon Nov 27 22:00:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 14:00:11 -0800
Subject: [Patches] [Patch #102553] Fix for handling jython's PyStringMap
Message-ID: <200011272200.OAA18534@sf-web3.vaspecialprojects.com>

Patch #102553 has been updated. 

Project: python
Category: None
Status: Closed
Summary: Fix for handling jython's PyStringMap

Follow-Ups:

Date: 2000-Nov-27 13:26
By: bckfnn

Comment:
This change matches similar code in pickle.py and will allow jython instances to be deepcopied.
-------------------------------------------------------

Date: 2000-Nov-27 14:00
By: gvanrossum

Comment:
Done.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102553&group_id=5470


From noreply@sourceforge.net  Mon Nov 27 21:54:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:54:14 -0800
Subject: [Patches] [Patch #102549] simpler, faster(!) implementation of string.join
Message-ID: <200011272154.NAA26053@sf-web2.i.sourceforge.net>

Patch #102549 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: simpler, faster(!) implementation of string.join

Follow-Ups:

Date: 2000-Nov-27 12:40
By: mwh

Comment:
attempting to fix a but in string.join, I realised that I didn't understand the current implementation.  So I rewrote it.  In doing so, I found the bug, but as my rewrite seems to be a little faster I thought I'd submit it.

The additional clarity is the main point though.
-------------------------------------------------------

Date: 2000-Nov-27 13:32
By: gvanrossum

Comment:
Tim -- can you review this?
-------------------------------------------------------

Date: 2000-Nov-27 13:54
By: gvanrossum

Comment:
In Python-dev, /F says:

your patch changes the behaviour of join on non-standard sequences.

if you use join on a long synthetic sequence, your new version may run
out of memory where the old one worked just fine.

not sure that's a good idea.

-0

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102549&group_id=5470


From noreply@sourceforge.net  Mon Nov 27 21:57:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:57:09 -0800
Subject: [Patches] [Patch #102549] simpler, faster(!) implementation of string.join
Message-ID: <200011272157.NAA26112@sf-web2.i.sourceforge.net>

Patch #102549 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: simpler, faster(!) implementation of string.join

Follow-Ups:

Date: 2000-Nov-27 12:40
By: mwh

Comment:
attempting to fix a but in string.join, I realised that I didn't understand the current implementation.  So I rewrote it.  In doing so, I found the bug, but as my rewrite seems to be a little faster I thought I'd submit it.

The additional clarity is the main point though.
-------------------------------------------------------

Date: 2000-Nov-27 13:32
By: gvanrossum

Comment:
Tim -- can you review this?
-------------------------------------------------------

Date: 2000-Nov-27 13:54
By: gvanrossum

Comment:
In Python-dev, /F says:

your patch changes the behaviour of join on non-standard sequences.

if you use join on a long synthetic sequence, your new version may run
out of memory where the old one worked just fine.

not sure that's a good idea.

-0

-------------------------------------------------------

Date: 2000-Nov-27 13:57
By: gvanrossum

Comment:
And then later:

looking again, this was obviously only true for the unicode version
(which uses PySequence_GetItem), not for the 8-bit string version
(which uses the PySequence_Fast API).

maybe we should change the 8-bit implementation instead?

if not, +1.

</F>
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102549&group_id=5470


From noreply@sourceforge.net  Mon Nov 27 21:58:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 13:58:17 -0800
Subject: [Patches] [Patch #102469] Use glibc's getline() extension
Message-ID: <200011272158.NAA21380@sf-web1.i.sourceforge.net>

Patch #102469 has been updated. 

Project: python
Category: core (C code)
Status: Accepted
Summary: Use glibc's getline() extension

Follow-Ups:

Date: 2000-Nov-21 19:15
By: akuchling

Comment:
(Inspired by a suggestion on comp.lang.python.) 

This patch changes the get_line() C function to use getline(),
a GNU libc extension, when it's available.  It does have a significant
impact; on my Linux box, reading the 6779-line quotations.xml
file takes 0.15 sec of CPU time using getline(), 0.45 sec without it.

Anyone know if C99 is adding an equivalent function?

Benchmark script:
import sys, time

f=open(sys.argv[1], 'r')

print 'Timing readline() for all lines'
cs = time.clock() ; start = time.time()
while 1:
    L = f.readline()
    if L == "": break

ce = time.clock() ; end = time.time()
print 'CPU time:', ce-cs, 'sec'
print 'Wall clock:', end-start, 'sec'


-------------------------------------------------------

Date: 2000-Nov-22 01:30
By: moshez

Comment:
In theory, I like this. In actual life, I'm a bit afraid of the implementation. You're just checking for the existence of a function named "getline". What if some other compiler
has such a function, and its semantics or signature differs? There's no pertinent standard on this. Maybe if would be best to enable if only if HAVE_GETLINE and something else
(like some define Glibc gives, if there is one).

-------------------------------------------------------

Date: 2000-Nov-27 13:37
By: gvanrossum

Comment:
I think Moshe is a little too worried here. Let's enable this. If there's a platform that has a different getline in its libc we'll find out soon enough (at the latest during alpha testing).

Andrew, go ahead and check it in.
-------------------------------------------------------

Date: 2000-Nov-27 13:58
By: akuchling

Comment:
OK.  I could add a check for the GNU libc and only use getline() if the compilation is using glibc, as Moshe suggests.  
This assumes that the name getline() or some equivalent isn't being standardized by C99.  


-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102469&group_id=5470


From noreply@sourceforge.net  Mon Nov 27 22:15:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 14:15:56 -0800
Subject: [Patches] [Patch #102469] Use glibc's getline() extension
Message-ID: <200011272215.OAA26482@sf-web2.i.sourceforge.net>

Patch #102469 has been updated. 

Project: python
Category: core (C code)
Status: Accepted
Summary: Use glibc's getline() extension

Follow-Ups:

Date: 2000-Nov-21 19:15
By: akuchling

Comment:
(Inspired by a suggestion on comp.lang.python.) 

This patch changes the get_line() C function to use getline(),
a GNU libc extension, when it's available.  It does have a significant
impact; on my Linux box, reading the 6779-line quotations.xml
file takes 0.15 sec of CPU time using getline(), 0.45 sec without it.

Anyone know if C99 is adding an equivalent function?

Benchmark script:
import sys, time

f=open(sys.argv[1], 'r')

print 'Timing readline() for all lines'
cs = time.clock() ; start = time.time()
while 1:
    L = f.readline()
    if L == "": break

ce = time.clock() ; end = time.time()
print 'CPU time:', ce-cs, 'sec'
print 'Wall clock:', end-start, 'sec'


-------------------------------------------------------

Date: 2000-Nov-22 01:30
By: moshez

Comment:
In theory, I like this. In actual life, I'm a bit afraid of the implementation. You're just checking for the existence of a function named "getline". What if some other compiler
has such a function, and its semantics or signature differs? There's no pertinent standard on this. Maybe if would be best to enable if only if HAVE_GETLINE and something else
(like some define Glibc gives, if there is one).

-------------------------------------------------------

Date: 2000-Nov-27 13:37
By: gvanrossum

Comment:
I think Moshe is a little too worried here. Let's enable this. If there's a platform that has a different getline in its libc we'll find out soon enough (at the latest during alpha testing).

Andrew, go ahead and check it in.
-------------------------------------------------------

Date: 2000-Nov-27 13:58
By: akuchling

Comment:
OK.  I could add a check for the GNU libc and only use getline() if the compilation is using glibc, as Moshe suggests.  
This assumes that the name getline() or some equivalent isn't being standardized by C99.  


-------------------------------------------------------

Date: 2000-Nov-27 14:15
By: gvanrossum

Comment:
OK. Not worht more discussion.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102469&group_id=5470


From noreply@sourceforge.net  Mon Nov 27 22:23:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 14:23:38 -0800
Subject: [Patches] [Patch #102409] Cygwin Python DLL and Shared Extension Patch
Message-ID: <200011272223.OAA26629@sf-web2.i.sourceforge.net>

Patch #102409 has been updated. 

Project: python
Category: Build
Status: Open
Summary: Cygwin Python DLL and Shared Extension Patch

Follow-Ups:

Date: 2000-Nov-16 07:40
By: jlt63

Comment:
This patch builds Cygwin Python with its core as a DLL -- similar to
the way that Win32 Python is built.  Once Cygwin Python is built as a
"shared library" (i.e., DLL), the procedure for building extensions is
the same as on UNIX platforms that support shared libraries.  It's as
easy as copying Misc/Makefile.pre.in, creating a Setup.in file, make -f
Makefile.pre.in boot, make.

The following is the procedure to apply the patch and build Cygwin Python:

	$ patch -p0 <Cygwin-1.1.5-Python-2.0.patch
	$ autoheader
	$ autoconf
	$ configure --with-threads=no --with-libm= --with-suffix=.exe
	$ make
	$ make install

To test out shared extensions, try the following:

	$ cd Demo/extend
	$ make_shared
	$ python
	Python 2.0 (#1, Nov  1 2000, 08:51:39)
	[GCC 2.95.2 19991024 (release-2)] on cygwin_nt-4.01
	Type "copyright", "credits" or "license" for more information.
	>>> import xx
	>>> dir(xx)
	['__doc__', '__file__', '__name__', 'bug', 'error', 'foo', 'new', 'roj']
	>>> xx.foo(2, 3)
	5

As a more realistic example, I was able to build python-ldap 1.10alpha3
(http://sourceforge.net/projects/python-ldap) with the following minimal
changes:

	1. replaced #ifdef WIN32 with #if defined(WIN32) || defined(__CYGWIN__)
	   as described in http://www.python.org/doc/FAQ.html#3.24
	2. added DL_EXPORT to init_ldap()

Note that there were no changes of any kind to the build files (i.e,
configure.in, Makefile.in, and Modules/Setup.in) or functionality changes
to the C source.

The following is an annotated ChangeLog for the patch:

Thu Nov 16 10:38:20 2000  Jason Tishler <jt@dothill.com>

	* Makefile.in: Add autoconf variable SET_DLLLIBRARY.
	* Makefile.in (altbininstall): Enhance altbininstall rule to also
	install the Cygwin Python DLL.
	* Makefile.in (libainstall): Change libainstall rule to install
	LDLIBRARY instead of LIBRARY.

	Will installing LDLIBRARY instead of LIBRARY break other
	platforms?  The terse description of LDLIBRARY in configure.in
	seems to indicate that possibly the original build procedure
	should be been installing it instead of LIBRARY.  Anyway, I am
	very willing to change the patch to install both LDLIBRARY and
	LIBRARY (if they are different) or some other suitable solution.

	* Modules/Makefile.in: Add autoconf variable SET_DLLLIBRARY.
	* Modules/Makefile.in ($(DLLLIBRARY)): Add $(DLLLIBRARY) rule to build
	the Cygwin Python DLL.

	Should the body of this rule be hidden in a shell script?  I have 
	stumbled across various platform specific scripts like BeOS/ar-fake
	that has me thinking that this may be desirable.

	* Modules/makesetup: Add shell variable module and default its value
	to "module".
	* Modules/makesetup: Add Cygwin specific definitions to set shell
	variables module, CygwinFlags, and CygwinLibs appropriately.

	Is it undesirable to put platform specific code in makesetup?

	* Modules/makesetup: Add .def to the list of known file types.
	* Modules/makesetup: Change object rule to include CygwinFlags.
	* Modules/makesetup: Change to use shell variable module instead of
	hardcoded "module".
	* Modules/makesetup: Change shared extension rule to include
	CygwinLibs.
	* acconfig.h: Add __CYGWIN__ guarded #defines for DL_IMPORT and
	DL_EXPORT.

	Is there a better way of accomplishing this without affecting config.h
	on all other autoconf supported platforms too?

	* configure.in: Add autoconf variable SET_DLLLIBRARY.
	* configure.in: Add Cygwin case to set LDLIBRARY and SET_DLLLIBRARY
	appropriately.

	I have chosen to call the import library libpython$(VERSION).dll.a
	and the DLL libpython$(VERSION).dll.  Recently there has been a
	proposal (http://sources.redhat.com/ml/cygwin/2000-10/msg01275.html)
	to name Cygwin DLLs cygfoo.dll instead of libfoo.dll in order
	to avoid clashing with Win32 versions of the same DLL.  I have stayed
	with libpython2.0.dll because it is more consistent with the UNIX
	naming convention and because there is no (current) possibility of
	clashing with the Win32 Python DLL, python20.dll.  Nevertheless, I
	am willing to change the name of the Cygwin Python DLL, if desired.

	* configure.in: Add Cygwin case to set MAKE_LDLIBRARY appropriately.
	* configure.in: Add Cygwin case to set LN appropriately.
	* configure.in: Add Cygwin case to set OPT appropriately.
	* configure.in: Add Cygwin case to set SO appropriately.
	* configure.in: Add Cygwin case to set LDSHARED appropriately.

	Should LDSHARED contain more flags?  For example,
	-Wl,--enable-auto-image-base, etc.?
-------------------------------------------------------

Date: 2000-Nov-16 10:01
By: nhv

Comment:
Incorporating this patch will make Cygwin a much
nicer enviroment for Python development.

I have beta tested this and it works as advertised
for me :-)

-------------------------------------------------------

Date: 2000-Nov-27 13:27
By: gvanrossum

Comment:
Tim...  Please give cygwin another try. Mail nhv or jlt63 for help if it doesn't install properly for you -- they clearly are motivated to have this added!
-------------------------------------------------------

Date: 2000-Nov-27 14:23
By: jlt63

Comment:
Tim, please feel free to contact me regarding any assistance that you may need installing Cygwin, applying my patch, building Cygwin Python, etc. I'm willing to help in any way that I can.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102409&group_id=5470


From noreply@sourceforge.net  Mon Nov 27 22:47:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 14:47:46 -0800
Subject: [Patches] [Patch #102208] Allow jython to use StringIO.py without an errno module.
Message-ID: <200011272247.OAA19321@sf-web3.vaspecialprojects.com>

Patch #102208 has been updated. 

Project: python
Category: library
Status: Accepted
Summary: Allow jython to use StringIO.py without an errno module.

Follow-Ups:

Date: 2000-Nov-22 03:48
By: moshez

Comment:
This seems very reasonable -- it actually eliminates a dependancy which is problematic anyway -- it makes StringIO.py much more platform independant. +1!
-------------------------------------------------------

Date: 2000-Nov-27 14:47
By: gvanrossum

Comment:
Please check it in or if you don't have time assign to me.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102208&group_id=5470


From noreply@sourceforge.net  Mon Nov 27 22:57:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 14:57:01 -0800
Subject: [Patches] [Patch #101477] Fixes of ReadStream.readline() in UTF-16 and -LE codecs
Message-ID: <200011272257.OAA19487@sf-web3.vaspecialprojects.com>

Patch #101477 has been updated. 

Project: python
Category: library
Status: Rejected
Summary: Fixes of ReadStream.readline() in UTF-16 and -LE codecs

Follow-Ups:

Date: 2000-Sep-14 07:09
By: fdrake

Comment:
Marc-Andre, please review this & decide what should happen next.
-------------------------------------------------------

Date: 2000-Sep-18 09:28
By: lemburg

Comment:
I'm not sure whether this is the right fix: Unicode defines many
more line break characters than just LF and the patch will only
work correctly on Unix (also note that UTF-16 can be BE and LE
-- your fix assumes LE).

A true fix would have to also touch the .read() method and
implement a true read-ahead buffer strategy to get this done
right.
-------------------------------------------------------

Date: 2000-Sep-19 03:41
By: lemburg

Comment:
Postponed until after the Python 2.0b2 release.
-------------------------------------------------------

Date: 2000-Nov-27 14:57
By: gvanrossum

Comment:
This version of the patch is clearly bogus. In UTF-16 encodings, \n can occur whenever the low or high byte of a Unicode character is 0x0A. I don't know if Unicode is designed to avoid all such code positions but I can hardly believe it.

A correct readline() method would have to read 2 bytes at a time and check for u"\u000A". (I don't care for all the other Unicode line breaking characters, those are for a different application level presumably.)
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101477&group_id=5470


From noreply@sourceforge.net  Mon Nov 27 23:03:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Nov 2000 15:03:50 -0800
Subject: [Patches] [Patch #102477] DOM enhancements
Message-ID: <200011272303.PAA19595@sf-web3.vaspecialprojects.com>

Patch #102477 has been updated. 

Project: python
Category: XML
Status: Open
Summary: DOM enhancements

Follow-Ups:

Date: 2000-Nov-22 13:39
By: fdrake

Comment:
This modifies PullDOM.__init__() to accept a Document object as a parameter, and changes PullDOM.startDocument() to use that object or create a one using minidom if necessary.  This allows all existing client code to continue to work unchanged, while supporting use of alternate DOM implementations.
-------------------------------------------------------

Date: 2000-Nov-22 22:24
By: fdrake

Comment:
Revised patch based on Greg Stein's note that the original would not create a new Document instance for each call to startDocument(); this version takes a document factory instead of a document object, and creates a new document with each call to startDocument().

-------------------------------------------------------

Date: 2000-Nov-27 13:38
By: gvanrossum

Comment:
Fred, please pick someone to review this and assign it to them.
-------------------------------------------------------

Date: 2000-Nov-27 15:03
By: fdrake

Comment:
[Changed summary line to reflect updated patch.  Assigning to Martin since he cares about this stuff.  ;-)  ]

xml.dom.minidom changes:

This improves the Node.normalize() method based on Martin's suggestions, but does not address all of his concerns (re-linking siblings in particular).  Test suite is updated to test that empty Text nodes are removed.

Minor improvement to an AttributeError that should not normally ever be seen by users.

Adds minimal support for DocumentType and DOMImplementation.

Partially fixes problem that documentElement was not properly supporting remove/replace; this should make it a little better, but sacrifices performance of using .documentElement to get it; the performance loss can be corrected by extending more methods in the Document class and removing the dynamic lookup of the documentElement attribute.

xml.dom.pulldom changes:

The PullDOM class now uses a DOMImplementation for the documentFactory object.  It's not clear that the createDocument method is used correctly, but the DOM Level 2 documentation for DOMImplementation is seriously lacking.

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102477&group_id=5470


From noreply@sourceforge.net  Tue Nov 28 08:26:23 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Nov 2000 00:26:23 -0800
Subject: [Patches] [Patch #102549] simpler, faster(!) implementation of string.join
Message-ID: <200011280826.AAA03521@sf-web2.i.sourceforge.net>

Patch #102549 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: simpler, faster(!) implementation of string.join

Follow-Ups:

Date: 2000-Nov-27 12:40
By: mwh

Comment:
attempting to fix a but in string.join, I realised that I didn't understand the current implementation.  So I rewrote it.  In doing so, I found the bug, but as my rewrite seems to be a little faster I thought I'd submit it.

The additional clarity is the main point though.
-------------------------------------------------------

Date: 2000-Nov-27 13:32
By: gvanrossum

Comment:
Tim -- can you review this?
-------------------------------------------------------

Date: 2000-Nov-27 13:54
By: gvanrossum

Comment:
In Python-dev, /F says:

your patch changes the behaviour of join on non-standard sequences.

if you use join on a long synthetic sequence, your new version may run
out of memory where the old one worked just fine.

not sure that's a good idea.

-0

-------------------------------------------------------

Date: 2000-Nov-27 13:57
By: gvanrossum

Comment:
And then later:

looking again, this was obviously only true for the unicode version
(which uses PySequence_GetItem), not for the 8-bit string version
(which uses the PySequence_Fast API).

maybe we should change the 8-bit implementation instead?

if not, +1.

</F>
-------------------------------------------------------

Date: 2000-Nov-28 00:26
By: mwh

Comment:
oops - my code had a bug.
'sep'.join(['a','b']) would return 'asepbsep'.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102549&group_id=5470


From noreply@sourceforge.net  Tue Nov 28 11:23:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Nov 2000 03:23:31 -0800
Subject: [Patches] [Patch #102563] test for string.join([unicode])
Message-ID: <200011281123.DAA00844@sf-web1.i.sourceforge.net>

Patch #102563 has been updated. 

Project: python
Category: None
Status: Open
Summary: test for string.join([unicode])

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102563&group_id=5470


From noreply@sourceforge.net  Tue Nov 28 17:42:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Nov 2000 09:42:28 -0800
Subject: [Patches] [Patch #102549] simpler, faster(!) implementation of string.join
Message-ID: <200011281742.JAA13272@sf-web2.i.sourceforge.net>

Patch #102549 has been updated. 

Project: python
Category: core (C code)
Status: Open
Summary: simpler, faster(!) implementation of string.join

Follow-Ups:

Date: 2000-Nov-27 12:40
By: mwh

Comment:
attempting to fix a but in string.join, I realised that I didn't understand the current implementation.  So I rewrote it.  In doing so, I found the bug, but as my rewrite seems to be a little faster I thought I'd submit it.

The additional clarity is the main point though.
-------------------------------------------------------

Date: 2000-Nov-27 13:32
By: gvanrossum

Comment:
Tim -- can you review this?
-------------------------------------------------------

Date: 2000-Nov-27 13:54
By: gvanrossum

Comment:
In Python-dev, /F says:

your patch changes the behaviour of join on non-standard sequences.

if you use join on a long synthetic sequence, your new version may run
out of memory where the old one worked just fine.

not sure that's a good idea.

-0

-------------------------------------------------------

Date: 2000-Nov-27 13:57
By: gvanrossum

Comment:
And then later:

looking again, this was obviously only true for the unicode version
(which uses PySequence_GetItem), not for the 8-bit string version
(which uses the PySequence_Fast API).

maybe we should change the 8-bit implementation instead?

if not, +1.

</F>
-------------------------------------------------------

Date: 2000-Nov-28 00:26
By: mwh

Comment:
oops - my code had a bug.
'sep'.join(['a','b']) would return 'asepbsep'.
-------------------------------------------------------

Date: 2000-Nov-28 09:42
By: mwh

Comment:
oops again - this now doesn't dump core with empty sequences...

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102549&group_id=5470


From noreply@sourceforge.net  Wed Nov 29 12:14:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Nov 2000 04:14:24 -0800
Subject: [Patches] [Patch #102563] test for string.join([unicode])
Message-ID: <200011291214.EAA30803@sf-web2.i.sourceforge.net>

Patch #102563 has been updated. 

Project: python
Category: None
Status: Closed
Summary: test for string.join([unicode])

Follow-Ups:

Date: 2000-Nov-29 04:14
By: gvanrossum

Comment:
Thanks. I've checked in a slight variation of this as revision 1.23.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102563&group_id=5470


From noreply@sourceforge.net  Wed Nov 29 15:13:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Nov 2000 07:13:59 -0800
Subject: [Patches] [Patch #102477] DOM enhancements
Message-ID: <200011291513.HAA21282@sf-web3.vaspecialprojects.com>

Patch #102477 has been updated. 

Project: python
Category: XML
Status: Open
Summary: DOM enhancements

Follow-Ups:

Date: 2000-Nov-22 13:39
By: fdrake

Comment:
This modifies PullDOM.__init__() to accept a Document object as a parameter, and changes PullDOM.startDocument() to use that object or create a one using minidom if necessary.  This allows all existing client code to continue to work unchanged, while supporting use of alternate DOM implementations.
-------------------------------------------------------

Date: 2000-Nov-22 22:24
By: fdrake

Comment:
Revised patch based on Greg Stein's note that the original would not create a new Document instance for each call to startDocument(); this version takes a document factory instead of a document object, and creates a new document with each call to startDocument().

-------------------------------------------------------

Date: 2000-Nov-27 13:38
By: gvanrossum

Comment:
Fred, please pick someone to review this and assign it to them.
-------------------------------------------------------

Date: 2000-Nov-27 15:03
By: fdrake

Comment:
[Changed summary line to reflect updated patch.  Assigning to Martin since he cares about this stuff.  ;-)  ]

xml.dom.minidom changes:

This improves the Node.normalize() method based on Martin's suggestions, but does not address all of his concerns (re-linking siblings in particular).  Test suite is updated to test that empty Text nodes are removed.

Minor improvement to an AttributeError that should not normally ever be seen by users.

Adds minimal support for DocumentType and DOMImplementation.

Partially fixes problem that documentElement was not properly supporting remove/replace; this should make it a little better, but sacrifices performance of using .documentElement to get it; the performance loss can be corrected by extending more methods in the Document class and removing the dynamic lookup of the documentElement attribute.

xml.dom.pulldom changes:

The PullDOM class now uses a DOMImplementation for the documentFactory object.  It's not clear that the createDocument method is used correctly, but the DOM Level 2 documentation for DOMImplementation is seriously lacking.

-------------------------------------------------------

Date: 2000-Nov-29 07:13
By: fdrake

Comment:
Uploading fixed patch, since something appearantly went wrong with the last upload.

Removed attempted use of cStringIO; that doesn't work with Unicode that can't be encoded using the default encoding for strings (often 7-bit ASCII), so we always use the original StringIO module.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102477&group_id=5470


From noreply@sourceforge.net  Thu Nov 30 04:14:07 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Nov 2000 20:14:07 -0800
Subject: [Patches] [Patch #102469] Use glibc's getline() extension
Message-ID: <200011300414.UAA02050@sf-web3.vaspecialprojects.com>

Patch #102469 has been updated. 

Project: python
Category: core (C code)
Status: Closed
Summary: Use glibc's getline() extension

Follow-Ups:

Date: 2000-Nov-21 19:15
By: akuchling

Comment:
(Inspired by a suggestion on comp.lang.python.) 

This patch changes the get_line() C function to use getline(),
a GNU libc extension, when it's available.  It does have a significant
impact; on my Linux box, reading the 6779-line quotations.xml
file takes 0.15 sec of CPU time using getline(), 0.45 sec without it.

Anyone know if C99 is adding an equivalent function?

Benchmark script:
import sys, time

f=open(sys.argv[1], 'r')

print 'Timing readline() for all lines'
cs = time.clock() ; start = time.time()
while 1:
    L = f.readline()
    if L == "": break

ce = time.clock() ; end = time.time()
print 'CPU time:', ce-cs, 'sec'
print 'Wall clock:', end-start, 'sec'


-------------------------------------------------------

Date: 2000-Nov-22 01:30
By: moshez

Comment:
In theory, I like this. In actual life, I'm a bit afraid of the implementation. You're just checking for the existence of a function named "getline". What if some other compiler
has such a function, and its semantics or signature differs? There's no pertinent standard on this. Maybe if would be best to enable if only if HAVE_GETLINE and something else
(like some define Glibc gives, if there is one).

-------------------------------------------------------

Date: 2000-Nov-27 13:37
By: gvanrossum

Comment:
I think Moshe is a little too worried here. Let's enable this. If there's a platform that has a different getline in its libc we'll find out soon enough (at the latest during alpha testing).

Andrew, go ahead and check it in.
-------------------------------------------------------

Date: 2000-Nov-27 13:58
By: akuchling

Comment:
OK.  I could add a check for the GNU libc and only use getline() if the compilation is using glibc, as Moshe suggests.  
This assumes that the name getline() or some equivalent isn't being standardized by C99.  


-------------------------------------------------------

Date: 2000-Nov-27 14:15
By: gvanrossum

Comment:
OK. Not worht more discussion.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102469&group_id=5470


From noreply@sourceforge.net  Thu Nov 30 04:14:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Nov 2000 20:14:59 -0800
Subject: [Patches] [Patch #102588] PEP 229: Use Distutils to build
Message-ID: <200011300414.UAA02071@sf-web3.vaspecialprojects.com>

Patch #102588 has been updated. 

Project: python
Category: Build
Status: Open
Summary: PEP 229: Use Distutils to build

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102588&group_id=5470


From noreply@sourceforge.net  Thu Nov 30 04:18:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Nov 2000 20:18:10 -0800
Subject: [Patches] [Patch #102588] PEP 229: Use Distutils to build
Message-ID: <200011300418.UAA02115@sf-web3.vaspecialprojects.com>

Patch #102588 has been updated. 

Project: python
Category: Build
Status: Open
Summary: PEP 229: Use Distutils to build

Follow-Ups:

Date: 2000-Nov-29 20:18
By: akuchling

Comment:
Not ready to be reviewed yet; I'm submitting this patch just to demonstrate some progress.

This version of the patch just removes the use of makesetup in building the interpreter, and hard-codes the presence of strop, posix, and _sre.  
Still to be done: write the top-level setup.py, and handle a few tricky bits such as the signalmodule.

-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102588&group_id=5470


From WebMaster@worldclassalpacas.com  Thu Nov 30 06:15:26 2000
From: WebMaster@worldclassalpacas.com (Dr Greg Nelson)
Date: Thu, 30 Nov 2000 06:15:26
Subject: [Patches] World Class Investment Opportunity
Message-ID: <200011301314.GAA17428@www.utahdawg.com>

<HTML>
<HEAD>
  <META NAME="GENERATOR" CONTENT="Adobe PageMill 3.0 Win">
  <TITLE>World Class Alpacas Buy and Sell</TITLE>
  <LINK REV="made" HREF="mailto:webmaster@infowest.com">
  <META NAME="keywords" CONTENT="alpaca, alpaca auction, alpaca clothing, alpaca fiber, investment, exotic animals, alpaca herd, alpacas for sale, alpaca auction, alpaca investment, alpaca sire, alpaca sires, alpaca trading, alpaca fiber, alpacas, alpaca auction, alpacas for sale, Andean music, Andes, exotic animals, alpaca, Bolivian Alpacas, Chilean alpacas, cria, alpaca, crias, electronic greeting cards, alpaca,  auction, electronic library, exotic animals, alpacas, investment, exotic investment, felt, alpacas  for sale, exotic animals, alpaca auction, fiber, fiber spinning, fleece, alpaca, exotic animals, greeting cards, huacaya, Inca, Incan, alpaca auction, Incan music, investment, alpaca, library, ">
  <META NAME="description" CONTENT="Natures most gentle creatures, cherished by the ancient Incans, a secure investment, remarkable growth, great tax benefits with a lifestyle of peace and serenity for generations.">
  <META NAME="copyright" CONTENT="2000">
  <META NAME="author" CONTENT="Dr Gregory T. Nelson">
  <META NAME="rating" CONTENT="General">
  <META NAME="DC.Title" CONTENT="World Class Alpacas Buy and Sell">
  <META NAME="DC.Creator" CONTENT="Chuck Mollenkopf">
  <META NAME="DC.Description" CONTENT="Natures most gentle creatures, cherished by the ancient Incans, a secure investment, remarkable growth, great tax benefits with a lifestyle of peace and serenity for generations.">
  <META NAME="DC.Publisher" CONTENT="CompuVet">
  <META NAME="DC.Contributors" CONTENT="Greg Nelson and Chuck Mollenkopf">
</HEAD>
<BODY BGCOLOR="#ffffff" BACKGROUND="http://www.worldclassalpacas.com/images/bg3.gif">

<P><CENTER><TABLE WIDTH="508" BORDER="0" CELLPADDING="0" CELLSPACING="0">
  <TR>
    <TD WIDTH="100%">
      <P><CENTER>&nbsp;<A HREF="http://www.worldclassalpacas.com/"><IMG 
      SRC="http://www.worldclassalpacas.com/images/logo4.gif" ALIGN="BOTTOM"
      BORDER="0"></A></CENTER></TD>
  </TR>
  <TR>
    <TD WIDTH="100%"></TD>
  </TR>
</TABLE></CENTER></P>

<P><TABLE WIDTH="723" BORDER="0" CELLSPACING="0" CELLPADDING="0">
  <TR>
    <TD WIDTH="17%"></TD>
    <TD WIDTH="83%" VALIGN="TOP"><TABLE WIDTH="574" BORDER="0" CELLSPACING="0"
      CELLPADDING="0" HEIGHT="603">
        <TR>
          <TD VALIGN="TOP" WIDTH="210" HEIGHT="157">&nbsp;<IMG SRC="http://www.worldclassalpacas.com/images/cria_small.gif"
            ALIGN="BOTTOM" BORDER="0" ALT="Alljandro of World Class Alpaca"></TD> 
          <TD WIDTH="59%" VALIGN="TOP" HEIGHT="157">
            <P><B>Dear Investors,</B></P>

            <P><B>I want to introduce to you the most profitable and rewarding
            investment around. Alpacas. To find out about alpacas, their
            history, investment potential and future, click or copy and paste
            the next link to visit Alpaca 101, a quick but very enlightening
            overview.</B>
          </TD>
        </TR>
        <TR>
          <TD COLSPAN="2" VALIGN="TOP" HEIGHT="346">
            <P><B><A HREF="http://www.worldclassalpacas.com/alpaca101.html">Alpaca
            101</A></B></P>

            <P><B>http://www.worldclassalpacas.com/alpaca101.html</B></P>

            <P><B>For a more in depth review, click on the next link to go
            to World Class Alpacas, where there is a wealth of information
            on Investing, ROI, the alpacas super fiber, herd growth, veterinary
            articles, newsletters, and just for fun, beautiful music, free
            E-Greeting cards and a free screen saver of Machu Picu.<BR>
<BR>
            <A HREF="http://www.worldclassalpacas.com/">World Class Alpacas</A></B></P>

            <P><B>http://www.worldclassalpacas.com/</B></P>

            <P>&nbsp;</P>

            <P><B>Sincerely,</B></P>

            <P><B>Dr. Gregory T. Nelson</B></P>

            <P><CENTER><A HREF="http://www.worldclassalpacas.com/"><B><FONT
             SIZE="+2">World Class Alpacas Home Page</FONT></B></A><B><BR>
            <HR></B></CENTER>
          </TD>
        </TR>
        <TR>
          <TD COLSPAN="2" HEIGHT="99">
            <P>If you have any feedback please email the <A HREF="mailto:webmaster@worldclassalpacas.com">WebMaster</A><BR>
            mailto:webmaster@worldclassalpacas.com</P>

            <P>If you wish to un subscribe at any time, please send a message
            to the <A HREF="mailto:webmaster@worldclassalpacas.com">Webmaster</A><BR>
            mailto:webmaster@worldclassalpacas.com with remove in the subject.
            Thanks</P>

            <P>&nbsp;</P>

            <P><CENTER><B>&COPY; 2000</B></CENTER>
          </TD>
        </TR>
      </TABLE></TD>
  </TR>
</TABLE>

</BODY>
</HTML>