Mailman 3 September 2003 - Python-Dev

Quick: want to give a Python talk at Linuxworld NY?
by Guido van Rossum Sept. 10, 2003

Sept. 10, 2003

I was just approached by Chris DiBona (chris at damagestudios dot com) about talking at the next Linuxworld in New York, in January. There are plenty of PHP and Perl talks but no Python talk yet. Time is of the essence, they are finalizing the program *now*. Reward is a free pass to everything. Spread the word! --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Documenting branch policy
by Greg Ward Sept. 9, 2003

Sept. 9, 2003

[cc'ing pydotorg since this involves a change to web content, but followup to python-dev please] Has anyone taken the time to sit down and document the development process surrounding release and maintenance branches? Speaking as an infrequent contributor to Python, it's never been entirely clear to me how to deal with branches. Seems to me like adding a paragraph or two to this page: http://www.python.org/dev/process.html would be a good start. Here's a first crack, based largely on guesswork, extrapolation from my day job (which also uses maintenance branches), and common sense: """ <h4>CVS Branch Policy</h4> <p>The Python development process uses CVS branches for a couple of purposes: <ul> <li>maintenance branches, for minor Python releases (2.2.3, 2.3.1, etc.) <li>release branches, for the exclusive use of the release manager(s) <li>feature branches, for large, disruptive additions/changes that take a long time to stabilize </ul> <h5>Maintenance branches</h5> <p>Every major Python version (2.1, 2.2, 2.3, etc.) is accompanied by a <em>maintenance branch</em>. Minor Python releases are always made from a maintenance branch -- e.g. Python 2.2.3 was made on the <code>release22-maint</code> branch, and Python 2.3.1 will be made on <code>release23-maint</code>. Maintenance branches are long-lived; they remain open as long as minor releases based on the corresponding major release are a possibility. Maintenance branches are for bug fixes <em>only</em>; maintaining backwards compatibility at every level is imperative. (In particular, all extension modules and bytecode for Python 2.<em>x</em>.<em>y</em> must continue to work with Python 2.<em>x</em>.<em>y+1</em> -- binary compatibility in the C API and bytecode must be maintained.)</p> <p>Any Python developer may checkin bug fixes on a maintenance branch; it is the release manager's responsibility to create the maintenance branch after releasing a new major Python version.</p> <h5>Release branches</h5> <p>Every release up to and including the final release for a new major Python version is accompanied by a <em>release branches</em>. For example, there were release branches for 2.3a1, 2.3a2, 2.3b1, 2.3b2, 2.3c1, and 2.3 itself; there will <em>not</em> be release branches for 2.3.1, 2.3.2, and so forth. Release branches allow the release manager to make small, last-minute changes without being affected by mainline development. It is the release manager's responsibility to merge changes from each release branch back onto the trunk after the release is finished. <p>Unless you are one of the release managers for a new major Python version, you should have nothing to do with release branches.</p> <h5>Feature branches</h5> <p>Occasionally, a new feature will be deemed large and disruptive enough that it will be added on a branch. For example, the "new-style classes" feature of Python 2.2 was added on <code>descr-branch</code> (the non-obvious name stems from <em>descriptors</em>, the new C-level data structure underlying new-style classes), which took several months to stabilize before it was merged onto the trunk. Managing a feature branch is tricky business, and the longer it takes to stabilize the new feature, the trickier it gets. <p>Feature branches are generally created and used by a single developer. Do not create a feature branch without discussing it on python-dev.</p> """ Please let me know how close this is to describing reality! Greg -- Greg Ward <gward(a)python.net> http://www.gerg.ca/ Cheops' Law: Nothing *ever* gets built on schedule or within budget.

17 31

memory related issues in Python - bug??
by Mallick, Pinki Sept. 9, 2003

Sept. 9, 2003

Hi, I have a very big XML file that I am trying to parse using xml.dom and xml.dom.minidom. This file has around 100 nodes. Each of these nodes(say 'child_X') have a number of child nodes and each of these child nodes in turn has a text node as its child. So when I try to retrieve all the data from each 'child_X' node, I use this code, grandChildren = child_X.childNodes() for grandChildNode in grandChildren: equation = equation + str(grandChildNode.firstChild.data) This works properly for all files. But when I am trying to use it on a very large XML file, one of the node's data is incomplete. eg. if grandChildNode.toxml() returns "<mi>y18</mi>" for this node, then "str(grandChildNode.firstChild.data)" returns only "y" instead of "y18". This looks like some memory problem. Is there any workaround for this problem. Thanks for any suggestion or help, Pinki Mallick

3 2

PyPy "Berlin" sprint (29th Sep - 4th Oct 2003)
by holger krekel Sept. 7, 2003

Sept. 7, 2003

hello python developers, the fourth PyPy coding sprint will take place in Berlin (Germany) from (morning of) 29th of September to (evening of) 4th of October 2003. All Python developers are welcome to join the sprint. See below for participation details. What is PyPy? ------------- PyPy is a remimplementation of Python in the Python language itself. Simplicity and flexibilty are the foremost goals. With PyPy we want it to be easy to extend the language or generate a more minimal language implementation. One key technique to making this feasible is to specialize our abstract/general PyPy-Python implementation into native code (e.g. C-code). Eventually the concepts of PSYCO and Stackless are to be integrated into PyPy. There is, of course, much more to it so feel free to consult some documents especially our Oscon-2003 paper on this page: http://codespeak.net/pypy/index.cgi?doc We know that many areas and issues are still somewhat vague although PyPy can already run many python programs [*]. Fortunately, Python is pretty tolerant about expressing ideas in vague ways. After all, hacking at PyPy aims (and already proved!) to preserve the fun of hacking in Python. History, status and Berlin goals -------------------------------- The project started in Jan/Feb 2003 with an initiative from Christian Tismer, Holger Krekel and Armin Rigo. During the course many more developers joined our sprints and there are now between 5 and 15 people involved in developing PyPy. The three sprints resulted in a fully working interpreter, some development infrastructure and the "standard object space" which is an abstraction for operations on standard (CPython) objects. There is no public release yet, you more or less have to install a subversion-client and checkout the trunk. Here is our 'howtosvn' which contains up-to-date clients for multiple platforms along with some instructions how to get started: http://codespeak.net/pypy/index.cgi?doc/devel/howtosvn.html Main goals for the Berlin sprint are - integration/enhancement of a Python parser and the compiler package - generating native code from our Python interpreter/types implementations - enhancing/correcting/completing what we have (various tasks) How to participate in Berlin (29th of Sept. to 4th of October) -------------------------------------------------------------- If you are interested to participate please subscribe at our sprint organization list http://codespeak.net/mailman/pypy-sprint and please list yourself at http://codespeak.net/moin/pypy/moin.cgi/SprintAttendants so that we can organize accomodation and arrange details. Costs should be pretty low (except from travelling costs, of course). Currently nine people are scheduled to come. Btw, the sprint starts early on the 29th of september so it's best to arrive on sunday, 28th. Also we probably want to have one day off during the sprint week to do some sight (or cafe+pub) seeing. Actually it's much better to participate the whole week to better get into it. cheers, holger [*] and currently only 20-40 thousand times slower than CPython! which clearly shows that we are successfully follow the "premature optimization is the root of all evil" maxime.

1 0

Re: [Python-Dev] buffer('abc') == 'abc' is False ?!
by martin＠v.loewis.de Sept. 7, 2003

Sept. 7, 2003

Scott Gilbert <xscottg(a)yahoo.com> writes: > I'm guessing you're doing housekeeping (instead of waiting diligently for > the implementation :-), so if you'd like to mark this PEP as abandoned that > makes sense to me... I was doing housekeeping indeed (of my mailbox); I wouldn't be pushing for a resolution on this PEP though. However, if everybody agrees: PEP editors, can you please mark PEP 296 as Withdrawn? Regards, Martin

2 1

Weekly Python Bug/Patch Summary
by Skip Montanaro Sept. 7, 2003

Sept. 7, 2003

Bug/Patch Summary ----------------- 467 open / 4093 total bugs (-1) 185 open / 2358 total patches (-2) New Bugs -------- absolute import patch breaks external users of test.regrtest (2003-08-31) http://python.org/sf/798274 Clarify trailing comma in func arg list (2003-09-01) http://python.org/sf/798652 windows sys.path contains nonexistant directory (2003-09-01) http://python.org/sf/798876 distutils ignored LDFLAGS in Makefile (2003-09-02) http://python.org/sf/799088 CPPFLAGS should not be aded to ldshard command (2003-09-02) http://python.org/sf/799104 documentation for sys.platform is unclear (2003-09-02) http://python.org/sf/799369 tk_focusNext() fails (2003-09-02) http://python.org/sf/799428 color highlighting not working on EDIT windows (2003-09-04) http://python.org/sf/800432 build fails (2003-09-04) http://python.org/sf/800710 test_dumbdbm failing (2003-09-04) http://python.org/sf/800824 Doc bug in PEP-0278 (2003-09-04) http://python.org/sf/800828 Making "|" directive from REs a bit clearer (2003-09-04) http://python.org/sf/800899 Bad RE in scanf example (2003-09-05) http://python.org/sf/801306 New slice behaviour. Bug or feature? (2003-09-05) http://python.org/sf/801349 New Patches ----------- More urllib2 examples (2003-08-31) http://python.org/sf/798244 imaplib : Add support for the THREAD command (2003-08-31) http://python.org/sf/798297 Improve "veryhigh.tex" API docs (2003-09-01) http://python.org/sf/798638 add HTTPResponse.getheaders() (2003-09-03) http://python.org/sf/800236 Add 'clear_history()' to 'readline' module (2003-09-04) http://python.org/sf/800697 zipimport 64-bit fix (2003-09-06) http://python.org/sf/801821 Adding rsplit() to string and unicode objects. (2003-09-06) http://python.org/sf/801847 Closed Bugs ----------- Fatal Python Error during program shutdown (2001-02-05) http://python.org/sf/231207 filecmp.dircmp case sensitivity bug (2001-08-20) http://python.org/sf/453515 Double underscore needs clarification (2002-02-19) http://python.org/sf/520325 setting file buffer size is unreliable (2002-09-02) http://python.org/sf/603724 __file__ attribute missing from dynamicly loaded module (2003-03-05) http://python.org/sf/698282 WINDOW in py_curses.h needs ncurses-devel (2003-03-11) http://python.org/sf/701751 Documentation formatting bugs (2003-04-25) http://python.org/sf/727692 recent-files defaulted to strange place and bad permissions (2003-07-31) http://python.org/sf/780887 pynche does not start (2003-07-31) http://python.org/sf/780996 urllib output: Worker thread.. (2003-08-08) http://python.org/sf/785584 build fails on Tru64 Unix (osf1V5) (2003-08-13) http://python.org/sf/788183 Unsupported 'locale' setting causes Idle to crash on startup (2003-08-13) http://python.org/sf/788378 sgmllib parser problem (2003-08-23) http://python.org/sf/793753 pyconfig.h defines _POSIX_C_SOURCE, conflicting with feature (2003-08-23) http://python.org/sf/793764 cygwin builds do not embed (2003-08-24) http://python.org/sf/794140 email module param parsing bug (2003-08-24) http://python.org/sf/794466 locale.setlocale(locale.LC_ALL, "de") raises exception (2003-08-29) http://python.org/sf/797447 Closed Patches -------------- Editing of __str__ and __repr__ docs (2003-04-25) http://python.org/sf/727789 curses has_key emulation fix (2003-06-23) http://python.org/sf/759208 Add a stream type and a merge type to itertoolsmodule.c (2003-07-19) http://python.org/sf/774414 os.path.exists should use os.access when possible (2003-08-10) http://python.org/sf/786237 explicitly provide a buffer in PyFile_SetBufSize() (2003-08-13) http://python.org/sf/788249 add SafeConfigParser to __all__ (2003-08-18) http://python.org/sf/790443 inconsistency with implementation(logging) (2003-08-19) http://python.org/sf/791153 timetuple() returns a struct_time (2003-08-20) http://python.org/sf/792338 __file__ attribute missing from dynamicly loaded module (2003-08-25) http://python.org/sf/794826

1 0

Changing select.select to accept iterables
by Brett C. Sept. 7, 2003

Sept. 7, 2003

Bug #798046 basically requests that select.select accept iterables instead of only lists. I took a look at the code and beyond PyList_Check()s and a function called list2set that expects a Python list to be passed that can easily be changed to take in an iterable I see no need to keep the restriction. But this module is old and I suspect it is used a good amount (the thing started at ver. 2.1 by Guido back in 1992). Since it seems to have gone this long without being changed to use the iterator protocol I wanted to double-check that changing it would be okay. The only reason I can think of why it wouldn't be is performance, as suggested by the OP of the bug report. And in general, when something like this that smacks of, "there is no obvious reason to keep it this way", even though it could have been changed a while ago and the CVS log seems to not mention anything against the change, should the change just be made? Or should I just ask like this to be safe? I have a sneaking suspicion the answer is, "just change it, Brett! Use your judgment! Don't be so timid!" But then at least this way I minimize getting chewed out for breaking code. Then again, being yelled at makes you think like a Dutchman faster than anything I know of. =) -Brett

3 7

Why do we flush before truncating?
by Tim Peters Sept. 7, 2003

Sept. 7, 2003

http://www.python.org/sf/801631 gives a failing program on Windows, paraphrased: f = file('test.dat', 'wb') f.write('1234567890') # 10 bytes f.close() f = file('test.dat','rb+') f.read(5) print f.tell() # prints 5, as expected f.truncate() # leaves the file at 10 bytes print f.tell() # prints 10 The problem is that fileobject.c's file_truncate() calls fflush() before truncating. The C standard says that the effect of calling fflush() is undefined if the most recent operation on a stream opened for update was an input operation. The stream is indeed opened for update here, and the most recent operation performed by the *user* was indeed a read. It so happens that MS's fflush() changes the file position then. But the user didn't call fflush(), Python did, so we can't blame the user for relying on undefined behavior here. The problem can be repaired inside file_truncate() by seeking back to the original file position after the fflush() call -- but the original file position isn't always available now, so I'd also have to add another call to _portable_ftell() before the fflush() to find it. So that gets increasingly complicated. Much simpler would be to remove this block of code (which does fix the test program's problem on Windows, by simply getting rid of the undefined operation): /* Flush the file. */ Py_BEGIN_ALLOW_THREADS errno = 0; ret = fflush(f->f_fp); Py_END_ALLOW_THREADS if (ret != 0) goto onioerror; I don't understand why we're flushing the file. ftruncate() isn't a standard C function, so the standard sheds no light on why we might be doing that. AFAICT, POSIX/SUS doesn't give a reason to flush either: http://www.opengroup.org/onlinepubs/007904975/functions/ftruncate.html

3 4

python-dev Summary for 2003-08-16 through 2003-08-31 [draft] [re-send]
by Brett C. Sept. 5, 2003

Sept. 5, 2003

[since the original mailing of this didn't seem to get to the list I am re-sending] This is a rather light summary, so finding my usual grammatical errors shouldn't be too difficult. With so many people on vacation I will probably wait on sending this summary out for a little while. On a personal note, this is my 24th summary. What this means is I have now written enough summaries to cover a year's worth. If you care to see some stats on the list read the "Summary Announcements" section. And if anyone on the list wants the pickled data I have for this or just want to know a specific stat I can look it up for you and tell you. -------------------------------- python-dev Summary for 2003-08-16 through 2003-08-31 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from August 16, 2003 through August 31, 2003. It is intended to inform the wider Python community of on-going developments on the list. To comment on anything mentioned here, just post to python-list(a)python.org or `comp.lang.python`_ with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! This is the twenty-fourth summary written by Brett Cannon (a year's worth of summaries by yours truly now under his belt; does this mean I am certifiably insane?). All summaries are archived at http://www.python.org/dev/summary/ . Please note that this summary is written using reStructuredText_ which can be found at http://docutils.sf.net/rst.html . Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it, although I suggest learning reST; its simple and is accepted for `PEP markup`_ and gives some perks for the HTML output. Also, because of the wonders of programs that like to reformat text, I cannot guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the original text file. .. _PEP Markup: http://www.python.org/peps/pep-0012.html The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation on something mentioned here. Python PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. .. _python-dev: http://www.python.org/dev/ .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470 .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. contents:: .. _last summary: http://www.python.org/dev/summary/2003-08-01_2003-08-15.html ===================== Summary Announcements ===================== This is the twenty-fourth summary written by me. Why am I repeating this fact since it is mentioned above? Well, it is significant because this means I have written enough summaries to cover a year's worth of email traffic on python-dev (had I not taken a summary off back in October this milestone would have been hit for the first half of August which represented a physical year since I started doing the summaries). I have managed to see a lot happen on python-dev from a new release, the first PyCon, and a number of flame wars. I personally have managed to learn a *huge* amount about not just Python the language but how to program in Python, C, and how to handle a large programming project. It has truly been worth the experience. But how much of an experience has it been? Well, for a long time now I have been planning on writing some code to calculate how much email I have read, who wrote most of that email, and what threads made up the most. With my move to San Luis Obispo finished I finally had a chance to write said code in an imperfect manner (names, for instance, are a pain because some people have their name set differently at different computers; "Barry Warsaw" compared to "Barry A. Warsaw"; threads are worse thanks to the changing of subject titles in the middle of a thread) so as to give me some approximate numbers. I have read 9469 emails that have passed through the python-dev mailing list. The top six emailers (out of approx. 433 unique emailers) have been: * Brett Cannon (277 emails when you deal with me just using my last initial; 2.9% of all emails) * Barry Warsaw (305 emails when you also count his middle initial; 3.2%) * Skip Montanaro (481 emails; 5.1%) * Martin v. Löwis (627 emails, when calculated looking for all names that had "Martin" and "wis" in them; 6.6%) * Tim Peters (694 emails; 7.3%) * Guido van Rossum (a whopping 1407 emails; 14.8%) The average person posted 21.9 emails over the emails I covered. But only about 24 people had more than a single percentage (more than 94 emails) worth of emails accredited to them. That means that about 5.5% of the unique posters on python-dev accounted for 66.8% of all email (and I have gotten to know a good amount of those 24. As for threads (of which there were *very* approx. 1252 unique threads), the top five are: * "type categories" (115 emails; 1.2% of all emails) * "PEP239 (Rational Numbers) Reference Implementation and new issues" (123 emails; 1.3%) * "PEP-317" (125 emails: 1.3%) * "python/dist/src/Python import.c,2.210,2.211" (146 emails; 1.5%) * "Extended Function syntax" (263 emails; 2.8%) What does this tell you and me? First, that I contribute to my own pain by more than I thought (I can't believe I emailed that many times!). Second, I must *really* like reading. Third, I have an addiction to Python. Fourth, PEPs really do get discussed. And fifth, Python development is alive and well. OK, enough statistics. As for this summary, it turned out rather light thanks to a couple of things. One is the shutdown of mail delivery by mail.python.org during the SoBig virus' peak. This not only cut back on the number of emails, but also led to me deleting *a lot* of bogus email on my other emails accounts. My blanket deleting may have caught legitimate emails so it is possible I accidently deleted some python-dev stuff, although if I did it was minimal. Another contributing factor to the light summary is that a lot of regulars on python-dev were on vacation. This looks like it will happen again for the first half of September so expect the next summary to be light as well. ========= Summaries ========= ------------------------------------------------------------------------------ Python using Parrot; new code interpreter or strange evolutionary parternship? ------------------------------------------------------------------------------ Pirate_ has now reached version 0.01 alpha. It lacks classes and imports but can run a decent amount of Python code. At least there is now a proof-of-concept that Python running on top of the Parrot_ VM is possible. .. _Pirate: http://pirate.tangentcode.com/ .. _Parrot: http://www.parrotcode.org/ Contributing threads: - `pirate 0.01 alpha! <http://mail.python.org/pipermail/python-dev/2003-August/037684.html>`__ ------------------------ Python 2.3.1 on its way? ------------------------ Raymond Hettinger suggesting pushing for a quick release of Python 2.3.1 so that the 2.3 branch could be established as a stable version. Several bugs and performance enhancements have been committed to the 2.3 maintenance branch. Anthony Baxter stepped forward as release czar with Raymond Hettinger saying he would help and Barry Warsaw volunteering his wisdom as a battle-hardened release czar. This discussion also brought up the question of whether a .chm help file for the Windows distribution would be worth using instead of including the HTML distribution of the documentation as it stands now. It was agreed that it was a good thing to have since it allowed for better searching. Tim Peters also discovered the install went faster since it would not have to copy a ton of individual HTML files. Python 2.3.1 has a "verbal" release date of the third week of September; there has not been a PEP to set the release schedule officially. Help would be appreciated in dealing with bug and patch reports on SourceForge. Even if all you do is add a comment saying "this patch looks fine" or "I can reproduce this bug" it can be a great help. Contributing threads: - `Py2.3.1 <http://mail.python.org/pipermail/python-dev/2003-August/037687.html>`__ - `HTMLHelp for Py2.3.1 <http://mail.python.org/pipermail/python-dev/2003-August/037866.html>`__ - `Fixing Patches and Bugs for Py2.3.1 <http://mail.python.org/pipermail/python-dev/2003-August/037840.html>`__ ---------------------------------------- Making looping generators more efficient ---------------------------------------- Would you like to see deeply nested generators be more efficient in returning their values? Clark Evans would and made such a request. He essentially wanted to have nested generator calls propogate their values to the first non-generator call directly and thus bypass all of the generator maintenance code. There was no direct reaction to this. Shane Holloway followed with the idea of having special syntax for when you yield each value of an iterator. The idea, once again, would be to speed this common case in the interpreter by skipping some bookkeeping overhead. A few syntax versions were offered, but the idea was all the same: special-case ``for item in iterable: yield item`` to something like ``yield *iterable``. Contributing threads: - `cooperative generators <http://mail.python.org/pipermail/python-dev/2003-August/037708.html>`__ - `Graph exploration with generators <http://mail.python.org/pipermail/python-dev/2003-August/037738.html>`__ -------------------------------------------------- Use of the logging package in the standard library -------------------------------------------------- Want to help out the development of Python? Know how to use the logging package? Then python-dev wants you! There are several modules in the stdlib that have home-grown logging code that could (and probably should) be using the logging package instead to simplify life. Read the email that started the contributing thread and see if you can't help out by converting the module over to using the logging package today! Contributing threads: - `Unification of logging in Python's Standard Library <http://mail.python.org/pipermail/python-dev/2003-August/037743.html>`__ ----------------------- Some waxings on PEP 310 ----------------------- PEP 310 proposes the 'with' syntax that came up a while back that sparked an immense discussion on python-dev. The idea was to have a more fool-proof way of having an enter and exit method be called before executing some specified code. The common example was acquiring a lock, executing some code, and then releasing the lock all without having to deal with an explicit try/finally statement. Samuele Pedroni tried to clarify how it should work exactly by requiring __exit__ instead of making it optional (read the PEP to understand what this means). Contributing threads: - `PEP 310(with-syntax): close synonym of __exit__ <http://mail.python.org/pipermail/python-dev/2003-August/037795.html>`__ ------------------------------------------------ Proposed PEP for a 'close' method for generators ------------------------------------------------ Samuele Pedroni has written a pre-PEP on defining a way to have generators grow a way to have a 'close' method that is called when their execution is finished so as to handle resources correctly. This is in response to not being able to contain yield statements within try/finally blocks. Contributing threads: - `pre-PEP: Resource-Release Support for Generators <http://mail.python.org/pipermail/python-dev/2003-August/037803.html>`__ ----------------- email-sig created ----------------- Barry Warsaw has created the `email-sig`_ to steer development of version 3 of the email package in hopes of having it done for Python 2.4 . .. _email-sig: http://www.python.org/sigs/email-sig/ Contributing threads: - `New SIG: email-sig <New SIG: email-sig>`__

1 0

readline.clear_history()
by Phillip J. Eby Sept. 5, 2003

Sept. 5, 2003

I've been working on a set of Python tools that use readline, but want to keep history separate between different interaction modes. Unfortunately, this really needs to be able to access readline's clear_history(), as read_history_file() leaves existing history intact. I'd be happy to whip up a patch to add this (as readline.clear_history()), but I was wondering if perhaps the reason it's not currently exported by the readline module is a compatibility issue for older readline implementations that are officially supported. Thanks.

7 15