Mailman 3 October 2000 - Python-Dev

Small memory leak in unicodeobject.c
by bwarsaw＠beopen.com 04 Oct '00

04 Oct '00

I've found a small memory leak in unicodeobject.c, in the way _PyUnicode_Fini() shuts down. Take a loop such as: -------------------- snip snip -------------------- #include "Python.h" int main(int argc, char** argv) { int i; while (1) { Py_Initialize(); Py_Finalize(); } return 0; } -------------------- snip snip -------------------- and you'll find that unicode_empty leaks. This is because, while _PyUnicode_Fini() decrefs unicode_empty, it never actually gets freed. Instead it gets placed on the already freed unicode_freelist! See _PyUnicode_Free() for why. I've come up with the following nasty hack to force unicode_empty to really be freed in _PyUnicode_Fini(). Maybe there's a better way to do this. Note that moving the decref of unicode_empty to above the freeing of unicode_freelist didn't plug the memory leak for me (but I'm quite tired so maybe I missed something! ;} ). Below is the proposed patch. -Barry -------------------- snip snip -------------------- Index: unicodeobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/unicodeobject.c,v retrieving revision 2.64 diff -u -r2.64 unicodeobject.c --- unicodeobject.c 2000/09/26 05:46:01 2.64 +++ unicodeobject.c 2000/10/03 16:31:32 @@ -5234,7 +5234,11 @@ PyObject_DEL(v); } unicode_freelist = NULL; - unicode_freelist_size = 0; + /* XXX This is a hack to force the freeing of unicode_empty's memory. + * Otherwise, it'll get placed on the already freed free list. + */ + unicode_freelist_size = MAX_UNICODE_FREELIST_SIZE; Py_XDECREF(unicode_empty); unicode_empty = NULL; + unicode_freelist_size = 0; }

3 5

Release candidate followed by feature freeze?
by Martin von Loewis 04 Oct '00

04 Oct '00

> It would be hard to sell Python for important applications, > e.g. long-running server processes, if there was a small possibility > that the program could crash through no fault of its own. There is always a small possibility that the program could crash through no faults of its own - i.e. I don't believe that Python is bug free without gc. I'd agree that bugs in the gc are more serious than other bugs. If it turns out that there are serious bugs in 2.0 (whether in the gc or elsewhere), I'd hope BeOpen will release 2.0.1 shortly after they get fixed. Regards, Martin

1 0

Suggested change for Setup.in
by bwarsaw＠beopen.com 04 Oct '00

04 Oct '00

I have a small suggestion for Modules/Setup.in. On Linux (RH6.1) with the zlib rpm installed, all I need to enable this module is the following line: zlib zlibmodule.c -lz but Setup.in has this suggestion, which I think is too hard for people to figure out what to do: zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz The standard build options will already include the right -I and -L flags for this to Just Work. I suggest we make the common case (Linux?) simple, and let others figure out what the right -I and -L flags are. I submit that even if they /do/ have to handcraft -I and -L, the defaults in Setup.in are pretty meaningless. A worthy change? For 2.0 final? -Barry

4 3

Re: [Python-checkins] CVS: python/dist/src/Lib/test test_pty.py,1.4,1.5
by Jeremy Hylton 04 Oct '00

04 Oct '00

Thomas, Thanks for taking care of this. One nit on the checkin procedure, pleae reference the SF bug number when you're fixing a bug. Also, report the revision number of the changed file when you close the bug. Thanks, Jeremy

2 1

Canvas.Canvas.bbox() return value
by Guido van Rossum 04 Oct '00

04 Oct '00

Hi Fredrik, Re this bug report: http://sourceforge.net/bugs/?func=detailbug&bug_id=110677&group_id=5470 I can take care of the Canvas issues, but I need your advice on bbox(). He's right that the bbox() method the Canvas class in the Canvas module is different from all other bbox() methods: it returns a tuple of tuples ((x1,y1),(x2,y2)) instead of a flat 4-tuple (x,y1,x2,y2). Do you think it's worth not breaking existing code here??? --Guido van Rossum (home page: http://www.python.org/~guido/)

2 1

Re: [Python-checkins] CVS: python/dist/src/Lib cgi.py,1.53,1.54
by Fredrik Lundh 03 Oct '00

03 Oct '00

> Change first line to #!/usr/bin/env python (really just to test check-in). hmm. cgi.py is a CGI script. according to the Python FAQ, CGI scripts should use an explicit path, not /usr/bin/env: "Note -- *don't* do this for CGI scripts. The $PATH variable for CGI scripts is often very minimal, so you need to use the actual absolute pathname of the interpreter." (since this comes up over and over again, maybe someone should add a comment to the file?) </F>

4 3

ANNOUNCE: Distutils 1.0
by Greg Ward 03 Oct '00

03 Oct '00

Python Distribution Utilities release 1.0 October 2, 2000 The Python Distribution Utilities, or Distutils for short, are a collection of modules that aid in the development, distribution, and installation of Python modules. (It is intended that ultimately the Distutils will grow up into a system for distributing and installing whole Python applications, but for now their scope is limited to module distributions.) The Distutils are a standard part of Python 1.6 and 2.0; if you are running 1.6 or 2.0, you don't need to install the Distutils separately. (However, you might want to upgrade if you're running Python 1.6.) This release is primarily so that you can add the Distutils to a Python 1.5.2 installation -- you will then be able to install modules that require the Distutils, or use the Distutils to distribute your own modules. Distutils 1.0 is the version that will be released with Python 2.0 (unless last-minute bugs pop up). More information is available at the Distutils web page: http://www.python.org/sigs/distutils-sig/ and in the README.txt included in the Distutils source distribution. You can download the Distutils from http://www.python.org/sigs/distutils-sig/download.html Trivial patches can be sent to me (Greg Ward) at gward(a)python.net. Larger patches should be discussed on the Distutils mailing list: distutils-sig(a)python.org. Greg -- Greg Ward gward(a)python.net http://starship.python.net/~gward/ And now for something completely different.

1 0

ANNOUNCE: Distutils 1.0
by Greg Ward 03 Oct '00

03 Oct '00

Python Distribution Utilities release 1.0 October 2, 2000 The Python Distribution Utilities, or Distutils for short, are a collection of modules that aid in the development, distribution, and installation of Python modules. (It is intended that ultimately the Distutils will grow up into a system for distributing and installing whole Python applications, but for now their scope is limited to module distributions.) The Distutils are a standard part of Python 1.6 and 2.0; if you are running 1.6 or 2.0, you don't need to install the Distutils separately. (However, you might want to upgrade if you're running Python 1.6.) This release is primarily so that you can add the Distutils to a Python 1.5.2 installation -- you will then be able to install modules that require the Distutils, or use the Distutils to distribute your own modules. Distutils 1.0 is the version that will be released with Python 2.0 (unless last-minute bugs pop up). More information is available at the Distutils web page: http://www.python.org/sigs/distutils-sig/ and in the README.txt included in the Distutils source distribution. You can download the Distutils from http://www.python.org/sigs/distutils-sig/download.html Trivial patches can be sent to me (Greg Ward) at gward(a)python.net. Larger patches should be discussed on the Distutils mailing list: distutils-sig(a)python.org. Greg -- Greg Ward gward(a)python.net http://starship.python.net/~gward/ And now for something completely different.

1 0

Development HTML docs online
by Fred L. Drake, Jr. 03 Oct '00

03 Oct '00

I've set things up so I can easily "publish" the Python documentation online without actually building a release. It's not entirely automatic, but I can push it online easily, so you'll be able to see what I'm doing. It can include more than just what's in CVS, but I try not to have too much waiting to checkin at once. Check it out: ftp://python.beopen.com/pub/docco/devel/index.html -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member

1 0

Release candidate followed by feature freeze?
by Guido van Rossum 03 Oct '00

03 Oct '00

I'm considering to issue a release candidate before the final 2.0 release. I'd like to poll opinions about this (we haven't had a PythonLabs group meeting about this yet). The importance of a release candidate (RC) is twofold: we announce it widely so it (hopefully) gets a lot of testing -- necessary since a lot of things have changed again since beta2; and we impose a checkin stop once the RC is out, with exceptions only allowed by the release manager to fix showstopper bugs found in the RC. This will hopefully avoid a disaster like we had with the buggy last-minute changes in beta2 (for which I take full responsibility). If the idea of a RC sounds okay, I'd like to propose to release it on October 5. The final release would still be on October 10, or perhaps 1-2 days later. Much less than a week between the RC and the final release is not good because it doesn't give testers enough time to try out the RC; much more than a week is bad because the developers get antsy when they can't check in their changes! This means that any current bug reports and patches that aren't in the RC, WON'T BE FIXED in the final release! Think about it. This is a good thing, so we won't be able to screw up the final release at the last moment. --Guido van Rossum (home page: http://www.python.org/~guido/)

3 2