Mailman 3 June 2000 - Python-Dev

SF patch manager...
by M.-A. Lemburg 28 Jun '00

28 Jun '00

[Please excuse my ranting... :-)] I've received the first round of notification message from the patch manager and can't really say that I like them. Ok, I understand that the patch manager is still alpha or beta software, but these messages really don't have any usable content at all: """ Patch #100646 has been updated. Visit SourceForge.net for more info. http://sourceforge.net/patch/?func=detailpatch&patch_id=100646&group_id=5470 """ Also, reviewing the patches has become a pain and discussing them is nearly impossible (I don't consider the slashdot like comment mechanism to be of any use: there's simply no audience for discussion). Is there any chance of tee'ing patches from SF to the patches list or some other patch discussion and review forum ? I do understand that the mechanism can help with patch *checkins*, but it's certainly not going to help much with the discussion step needed before conidering any actions. The independent peer review principal doesn't work with this kind of setup. Ok, enough whining, let's get on with business now ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

8 13

SourceForge win32 HOWTO
by Andy Robinson 28 Jun '00

28 Jun '00

Sorry, I've been offline and missed this thread. I could have saved you some time. These are the instructions we've used at ReportLab to work with SourceForge on Win32. No problems so far despite several Unix and CVS newbies, myself included. They are adapted from an article by Jay Andrew Kay somewhere on Sourceforge and are generic rather than specific to the Python source. I have used the ReportLab project and my user name as an example but I'm sure you guys can adapt that.... 1. Get ftp.reportlab.com/tools/cvs-1.10-win.zip and ftp.reportlab.com/tools/ssh-1.2.14-win32bin.zip (copied from somewhere obscure for safety, I forget where) 2. Unzip these to a location on your path. Type 'cvs' or 'shh' from somewhere else to verify. 3. Choose where to keep your CVS projects; let's assume C:\code 4. Create a subdirectory c:\code\.ssh (yes, dot-ssh) 5. Create two environment variables: HOME=C:\CODE CVS_RSH=SSH On Win9x, this can be done in a batch file or autoexec.bat; on NT or 2000, go to Control Panel | System | Environment and set them at either user or machine level. The first must point to the directory above your .ssh directory. 6. If not done so, get a Sourceforge account and a project you can log in to. 7. Test SSH independently by doing SSH -l username myproject.sourceforge.net It should prompt for a password, then tell you that "myproject.sourceforge.net" is added to the list of known hosts; then give you a shell. 8. You will need either a lengthy command line or a batch file for each sourceforge project. I set cvsroot in a batch file in my 'c:\code' directory, and have one such file for each CVS project I use (about ten of them!): ------cvsreportlab.bat-------------- set HOME=C:\CODE set CVS_RSH=SSH set CVSROOT=:ext:my_user_name@cvs.myproject.sourceforge.net:/cvsroot/dirname --------------------------------------- 'dirname' is the top level directory in the CVS tree; a project can have several, but usually there is just one. 9. execute this batch file. You can now go to C:\Code and do cvs -z7 checkout myproject (z7 means 'compress network traffic', handy over dialup lines) 10. From now on, just use CVS normally. I wouldn't survive without Karl Fogel's book "Open Source Development with CVS", Coriolis Press. Footnote: for anonymous checkout, I think you just omit the 'my_user_name@' part from the CVSROOT variable. I hope this helps; let me know if people have any problems with the instructions. - Andy Robinson ReportLab

2 1

C# (new language from Microsoft)
by Greg Wilson 28 Jun '00

28 Jun '00

I'm sure many of you will have seen this announcement already, but for those who haven't, Microsoft is launching a new language to compete with C, C++, and Java: http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp Greg

4 3

testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names)
by Trent Mick 28 Jun '00

28 Jun '00

On Mon, Jun 26, 2000 at 01:18:28PM -0400, Jeremy Hylton wrote: > Ok. I was looking for a test case to include in the test suite. I've > made the change, but it looks like it will have to go without an > accompanying test. I asked the question a while back if it would reasonable/useful/popular to have a mechanism where parts of the Python/C Api could be tested directly. My proposal used an extension module _testmodule (although I made it a core module on UN*X it should not bog down the core) which exported a bunch o' test_* routines that tested specific parts of the Python/C API. A test_internal.py module would be added to the std regression test suite that would import this module and call each of the exported test_* routines in turn. This would allow things like the _GetAttr/_SetAttr behaviour to be tested. Anybody have any opinions? Trent p.s. I have a patch largely (all except the above menntion limitation) ready for this, including some tests that I used for my 64-bit porting stuff. -- Trent Mick trentm(a)activestate.com

6 6

ANN: Release schedule
by Guido van Rossum 28 Jun '00

28 Jun '00

Here at BeOpen we're scrambling to get the release schedule for the rest of Python 1.6 planned. We're now looking at releasing Python 1.6b1 (or maybe it's going to be called 1.6a3 after all) on June 30! This means that if SRE isn't ready, we'll go with an incomplete SRE. Still better than no SRE! Please, PLEASE, if you have pending patches that you think should go into 1.6b1, submit them to SourceForge. We'll do our best to have a look at every patch submitted; but don't wait until the last moment. (Trent Mick, it would be helpful if you assigned each of your patches a potential reviewer from the list of existing developers -- that way we can split up the review load.) --Guido van Rossum (home page: http://www.python.org/~guido/)

6 8

readline history read/write
by Skip Montanaro 28 Jun '00

28 Jun '00

The original thing that motivated me to propose what became atexit.py was my desire to read and write readline history files. The two attached context diffs patch Modules/readline.c and Lib/rlcompleter.py to do that. Two new functions are added to the readline module and rlcompleter is tweaked to read the history file referenced by the PYTHONHISTORY environment variable (if it's defined) and automatically save it when the interpreter exits. I'm looking for a little feedback. Here are a few things that jumped to my mind: 1. Is it okay to add the read and register/write code to rlcompleter.py? Reading and writing readline history files doesn't have anything directly to do with identifier completion, but they both have to do with readline. 2. Assuming that history file read/write is desired, should it be predicated on the presence of an environment variable or (as in bash and other readline-aware programs) should it just happen? 3. Am I correct in assuming that this capability will only be available to Unix/Linux environments, or is readline generally available, thus forcing me to think about cross-platform issues? 4. Is there some mechanism already present in IDLE and/or PythonWin I should be aware of and try to emulate? The two context diffs are both short. You should be able to follow everything just by reading the bits of code. Offering your thoughts on the above questions shouldn't require actually modifying your interpreter. Thx, -- Skip Montanaro, skip(a)mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings." *** /tmp/readline.c.~2.17~SlD5BD Tue Jun 27 21:38:08 2000 --- /tmp/readline.cSlDGMJ Tue Jun 27 21:38:08 2000 *************** *** 94,99 **** --- 94,147 ---- "; + /* Exported function to load a readline history file */ + + static PyObject * + read_history_file(self, args) + PyObject *self; + PyObject *args; + { + char *s = NULL; + if (!PyArg_ParseTuple(args, "|z:read_history_file", &s)) + return NULL; + errno = read_history(s); + if (errno) + return PyErr_SetFromErrno(PyExc_IOError); + Py_INCREF(Py_None); + return Py_None; + } + + static char doc_read_history_file[] = "\ + read_history_file([filename]) -> None\n\ + Load a readline history file.\n\ + The default filename is ~/.history.\ + "; + + + /* Exported function to save a readline history file */ + + static PyObject * + write_history_file(self, args) + PyObject *self; + PyObject *args; + { + char *s = NULL; + if (!PyArg_ParseTuple(args, "|z:write_history_file", &s)) + return NULL; + errno = write_history(s); + if (errno) + return PyErr_SetFromErrno(PyExc_IOError); + Py_INCREF(Py_None); + return Py_None; + } + + static char doc_write_history_file[] = "\ + write_history_file([filename]) -> None\n\ + Save a readline history file.\n\ + The default filename is ~/.history.\ + "; + + /* Exported function to specify a word completer in Python */ static PyObject *completer = NULL; *************** *** 261,266 **** --- 309,316 ---- {"get_line_buffer", get_line_buffer, 0, doc_get_line_buffer}, {"insert_text", insert_text, 1, doc_insert_text}, {"read_init_file", read_init_file, 1, doc_read_init_file}, + {"read_history_file", read_history_file, 1, doc_read_history_file}, + {"write_history_file", write_history_file, 1, doc_write_history_file}, {"set_completer", set_completer, 1, doc_set_completer}, {"get_begidx", get_begidx, 0, doc_get_begidx}, {"get_endidx", get_endidx, 0, doc_get_endidx}, *** /tmp/rlcompleter.py.~1.7~SlDswI Tue Jun 27 21:36:32 2000 --- /tmp/rlcompleter.pySlD56O Tue Jun 27 21:36:32 2000 *************** *** 118,120 **** --- 118,131 ---- return ret readline.set_completer(Completer().complete) + + import os + histfile = os.getenv("PYTHONHISTORY") + if histfile is not None: + try: + readline.read_history_file(histfile) + except IOError: + pass + import atexit + atexit.register(readline.write_history_file, histfile) + del os, histfile

1 0

DOS text files and CVS
by Greg Ward 28 Jun '00

28 Jun '00

Hi all -- can anyone enlighten me on the right way to check in DOS text files to a CVS repository? I have Thomas Heller's C source for his simple graphical installer for Python modules, and it should definitely be in the Distutils CVS tree. But I don't want to check it in if it'll screw up line-endings for anyone. Is there a Right Way to do this? Thanks -- Greg -- Greg Ward - Linux nerd gward(a)python.net http://starship.python.net/~gward/ Just because you're paranoid doesn't mean they *aren't* out to get you.

6 5

Testdrive systems
by Andrew Kuchling 27 Jun '00

27 Jun '00

Portability-related note: I've just fixed a reported compilation problem with the curses module on Tru64 Unix using a machine made available by Compaq. If you go to http://www.testdrive.compaq.com/, you can sign up for a free 30-day account on a variety of machines: Alphas running Tru64, FreeBSD, and Linux, and Intel machines running BSD or Linux. A nice way to fix reported problems quickly... The environment on the systems is a bit Spartan; emacs is there, but no fancy shells and no CVS (which is especially annoying). --amk

1 0

python.org mail unclogged
by Guido van Rossum 27 Jun '00

27 Jun '00

It seems we've removed a major source of email cloggage on python.org -- a site in France was hitting every page in the mailman membership administration using a commercial crawler (Teleport Pro) that didn't honor our robots.txt file, and forking a 4 Mb CGI script for each user in each mailing list. Thanks for Barry and Andrew! This was on top of problems caused when the Ultraseek crawler ran out of memory and caused postfix or mailman to fail. :-( Mail seems to be flowing again, the queues are emptying. Once we're happy, we'll turn on the Ultraseek crawler and search service. --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

semi-subtle atexit gotcha?
by Skip Montanaro 27 Jun '00

27 Jun '00

In thinking about the new atexit module a little more, it occurred to me that I've handled the case where the atexit module gets loaded after another module that wants to set sys.exitfunc (it just incorporates that function into its list of functions), but not if atexit gets loaded before another modules that uses sys.exitfunc. I see two possible choices: 1. Punt and put a bit of verbiage in the atexit section of the library reference manual and the 1.6 release notes. 2. Have atexit.register check each time it's called to see if sys.exitfunc is what it expects. This isn't a perfect solution for a couple reasons. One, there's no guarantee that other sys.exitfunc- modifying code isn't executed after the last call to atexit.register. Two, there's no guarantee that the other code doesn't attempt to be "intelligent" in a fashion similar to atexit (can you say dueling banjos?). I vote for option number one since there appears to be no guaranteed way to make it work, but I'm open to other suggestions. -- Skip Montanaro, skip(a)mojam.com, http://www.mojam.com/, http://www.musi-cal.com/ On Phil Jackson's ability to manage multiple Lakers superstars, Shaquille O'Neal said: "He's got the rings. I listen to the man with the rings."

2 1