Mailman 3 February 2004 - Python-Dev

Fw: logging exceptions
by Vinay Sajip Feb. 20, 2004

Feb. 20, 2004

----- Original Message ----- From: "Vinay Sajip" <vinay_sajip(a)red-dove.com> To: <python-dev(a)python.org> Cc: <jeremy(a)alum.mit.edu> Sent: Friday, February 20, 2004 12:25 AM Subject: Re: logging exceptions > > Zope 2.7 is using the logging package internally as the implementation > > for its old zLOG API. We've run into one problem, probably caused by > > carelessness on our part. > > > > zLOG allows you to pass exc_info to be logged, but logging only allows > > you to specify a flag saying whether the current exception should be > > logged. (I recall that this was discussed at length, but not why the > > current solution was reached.) There are several call sites that depend > > on this feature to capture an exception, try to recover gracefully or > > log a traceback if recovery is impossible. So we depend on this > > feature, but can't get it out of logging very easily. > > > > We've come up with this as a work-around: > ["Gross" workaround snipped] > > I propose to make the following change: > def _log(self, level, msg, args, exc_info=None): > # ... > if exc_info: > if type(exc_info) != types.TupleType: > exc_info = sys.exc_info() > record = self.makeRecord(self.name, level, fn, lno, msg, args, > exc_info) > self.handle(record) > > This should allow passing an exception tuple in the exc_info parameter - in > which case, that's used instead of calling sys.exc_info(). It is a slight > change to the semantics but I can't think of any (non-pathological) code > which will break. Can anyone see any problems with this approach? > > Regards, > > Vinay >

1 0

RE: [Python-Dev] python-dev Summary for 2004-01-01 through 2004-01-31[rough draft]
by Delaney, Timothy C (Timothy) Feb. 20, 2004

Feb. 20, 2004

> From: Josiah Carlson > > I don't know if you want to mention the fact that it was rejected by > Guido. Actually, that's exactly the right thing to mention - it has been rejected after all. There's no problem with including a sample implementation with the final version of the PEP, and there's nothing stopping people using it, but it's important that people know it's been rejected and will not be in the standard library. Especially since the final version of the PEP is not yet up, and it hasn't been moved to the 'Rejected' section yet. Tim Delaney

2 1

Weekly Python Bug/Patch Summary
by Kurt B. Kaiser Feb. 19, 2004

Feb. 19, 2004

Patch / Bug Summary ___________________ Patches : 241 open ( -5) / 2315 closed ( +5) / 2556 total ( +0) Bugs : 711 open ( +6) / 3892 closed ( +5) / 4603 total (+11) RFE : 127 open ( +0) / 118 closed ( +0) / 245 total ( +0) Patches Closed ______________ urllib2 does not allow for absolute ftp paths (2003-10-03) http://python.org/sf/817379 closed by loewis tp_dealloc, threads and garbage collection (2004-02-09) http://python.org/sf/893566 closed by loewis urllib2 doesn't support non-anonymous ftp (2003-03-29) http://python.org/sf/711838 closed by loewis Updated .spec file. (2004-02-08) http://python.org/sf/892673 closed by loewis doctest handles comments incorrectly (2003-01-15) http://python.org/sf/668500 closed by tim_one New / Reopened Bugs ___________________ pyconfig.h is not placed in --includedir (2004-02-13) http://python.org/sf/896330 opened by Göran Uddeborg time.strftime crashes python (2004-02-15) http://python.org/sf/897625 opened by Tom Lynn test_strptime failures on FC2-test (2004-02-16) http://python.org/sf/897817 opened by Anthony Baxter db4 4.2 == :-( (test_anydbm and test_bsddb3) (2004-02-16) http://python.org/sf/897820 opened by Anthony Baxter Unknown color name on HP-UX (2004-02-16) http://python.org/sf/897872 opened by Richard Townsend pty.spawn() leaks file descriptors (2004-02-16) http://python.org/sf/897935 opened by James Henstridge strftime ignores date format on winxp (2004-02-17) http://python.org/sf/898253 opened by Matthew Sherborne symtable module crashes w/ coding declaration (2004-02-16) http://python.org/sf/898271 opened by Peter Åstrand Python 2.3 encoding parsing bug (2004-02-17) http://python.org/sf/898757 opened by Edward K. Ream test_threading (2003-08-19) http://python.org/sf/791542 reopened by bcannon 1==float('nan') (2004-02-17) http://python.org/sf/899109 opened by Arman Bostani Bugs Closed ___________ Inconsistent behavior of compressing the BZip2 format (2003-12-03) http://python.org/sf/853061 closed by niemeyer Unicode problem in os.path.getsize ? (2004-02-13) http://python.org/sf/896236 closed by loewis Core dump problems (2003-12-15) http://python.org/sf/860547 closed by rhettinger FAQ 2.3 slices not used (2004-02-02) http://python.org/sf/888829 closed by loewis test_threading (2003-08-19) http://python.org/sf/791542 closed by sleard1 Python 2.3 encoding parsing bug (2004-02-17) http://python.org/sf/898757 closed by loewis

4 11

Accumulation module
by Raymond Hettinger Feb. 19, 2004

Feb. 19, 2004

I'm working a module with some accumulation/reduction/statistical formulas: average(iterable): stddev(iterable, sample=False) product(iterable) nlargest(iterable, n=1) nsmallest(iterable, n=1) The questions that have arisen so far are: * What to call the module * What else should be in it? * Is "sample" a good keyword to distinguish from population stddev? * There seems to be a speed/space choice on how to implement nlargest/nsmallest. The faster way lists out the entire iterable, heapifies it, and pops off the top n elements. The slower way is less memory intensive: build only a n-length heap and then just do a heapreplace when necessary. Note, heapq is used for both (I use operator.neg to swap between largest and smallest). * Is there a way to compute the standard deviation without multiple passes over the data (one to compute the mean and a second to sum the squares of the differences from the mean? Raymond Hettinger

14 14

Nokia
by David Ascher Feb. 19, 2004

Feb. 19, 2004

I'm at ETech 2004, where the CTO of Nokia talked about how they are _currently_ using Python to develop applications that run on their "66-series" platform (which includes the n-gage IIRC). Nokia shipped 100 million units last year. Interesting, no? --david PS: Yes, I'll be asking him to consider becoming a PSF sponsor member.

3 2

PEP 309 misuses the term "currying"
by David Abrahams Feb. 19, 2004

Feb. 19, 2004

The operation performed by the operator described here is actually called "Partial Application". A good definition of currying can be found in http://tinyurl.com/3d6w6 and http://tinyurl.com/ly29. Several languages have misused the term "curry" this way http://tinyurl.com/2p6gb, http://tinyurl.com/2onya (Python) http://tinyurl.com/36pus (JavaScript) http://tinyurl.com/3dj6j (Dylan) Currying transforms a function taking a single tuple argument into a function taking multiple arguments, and uncurrying reverses the process. >>> def curry(f): ... return lambda *args: f(args) ... >>> def add2(args): # add the first 2 elements of an argument tuple ... return args[0] + args[1] ... >>> curry(add2)(1,2) # make add2 accept multiple args 3 >>> def uncurry(f): ... return lambda x: f(*x) ... >>> uncurry(curry(add2))((1,2)) # reverse currying; pass a tuple 3 -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2

PEP 309 misuses the term "currying"
by David Abrahams Feb. 19, 2004

Feb. 19, 2004

The operation performed by the operator described here is actually called "Partial Application". A good definition of currying can be found in http://tinyurl.com/3d6w6 and http://tinyurl.com/ly29. Several languages have misused the term "curry" this way http://tinyurl.com/2p6gb, http://tinyurl.com/2onya (Python) http://tinyurl.com/36pus (JavaScript) http://tinyurl.com/3dj6j (Dylan) Currying transforms a function taking a single tuple argument into a function taking multiple arguments, and uncurrying reverses the process. >>> def curry(f): ... return lambda *args: f(args) ... >>> def add2(args): # add the first 2 elements of an argument tuple ... return args[0] + args[1] ... >>> curry(add2)(1,2) # make add2 accept multiple args 3 >>> def uncurry(f): ... return lambda x: f(*x) ... >>> uncurry(curry(add2))((1,2)) # reverse currying; pass a tuple 3 -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

python-dev Summary for 2004-01-01 through 2004-01-31 [rough draft]
by Brett C. Feb. 19, 2004

Feb. 19, 2004

As usual, reply to this email with any corrections and such. Plan on getting this out this weekend. As for why this is late, read the Summary Announcements (basically illness and just really busy). And just so I can say I did everything I could, I will repeat myself here as I did in the Summary Announcements and mention I am looking for a summer job/internship. Any leads on any would be greatly appreciated. More details can be found in the Summary Announcements. ------------------- python-dev Summary for 2004-01-01 through 2004-01-31 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from January 1, 2004 through January 31, 2004. 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 `comp.lang.python`_ (or email python-list(a)python.org which is a gateway to the newsgroup) 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 thirty-third and -fourth summaries written by Brett Cannon (who is rather fed up with being sick recently). To contact me, please send email to brett at python.org ; I do not have the time to keep up on comp.lang.python and thus do not always catch follow-ups posted there. 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; it's 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. 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. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to forward the development and use of Python. But the PSF cannot do this without donations. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation (you can donate through PayPal or by check) helps. .. _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 .. _Python Software Foundation: http://python.org/psf/ .. contents:: .. _last summary: http://www.python.org/dev/summary/2003-12-01_2003-12-31.html ===================== Summary Announcements ===================== Quick personal announcement/plea: I am looking for a summer job/internship. If you happen to have a position at your company or happen to know of one somewhere **please** let me know at brett(a)python.org . I obviously know Python rather well, but I do know other languages. I am quite willing to send you my resume and answer any questions you might have about experience, etc. I would truly appreciate any help anyone can provide me in finding something for the summer. I do have housing handled in the Los Angeles area and the Seattle/Bellevue area on top of the San Luis Obispo area, although I am willing to relocate for the summer. Sorry about the lateness of this summary. I realize this is going out when another one is already due. Unfortunately, on top of needing to secure a summer job/internship and trying to get that dealt with, I also got strep throat that was rather horrid. It was not fun to only be officially over pneumonia for a couple of weeks before I got sick again. Rather frustrating since I haven't been this ill so often since I was a little kid. And having to deal with school on top of being sick did not help matters. In actual Python-related news, PyCon's early-bird registration cut-off date has been extended to February 22nd! If you have not registered, go to http://pycon.org/dc2004/register/ and do so now! Last year was a blast and I expect no less from this year (I am actually spending my Spring Break at PyCon and I am quite happy to do so I enjoyed myself so much last year). Papers have been selected and it looks like we are going to have a great line-up of talks that cover the gamut of interests. In other words I highly recommend attending if you can. And even if you can't attend, if you are in the D.C. area, consider at least attending the first two days of the sprints which are the weekend preceding the conference (March 20-21). More info on the sprints can be found at http://www.python.org/cgi-bin/moinmoin/SprintPlan2004 . And now, on with the juicy stuff... ========= Summaries ========= --------------------- Benchmarking is a go! --------------------- After Guido committed the parrotbench code to CVS, various people began to run the benchmark and post their scores. If you are curious to see how your machine compares take a look at the contributing threads. Contributing threadds: - `Pie-thon benchmark code ready <http://mail.python.org/pipermail/python-dev/2004-January/041551.html>`__ - `Re: Are we collecting benchmark results across machines <http://mail.python.org/pipermail/python-dev/2004-January/041553.html>`__ ----------------------------------- Windows compilation moved to VC.NET ----------------------------------- Martin v. L√∂wis converted the project files and anything else needed so that Python can now be compiled using VC.NET . All of the previous files needed for compiling under VC 6 has been moved to PC/VC6 . Contributing threads: - `Switch to VC.NET 7.1 completed <http://mail.python.org/pipermail/python-dev/2004-January/041600.html>`__ -------------------------- Shutting Unicode errors up -------------------------- Enough people have asked for the ability to silence Unicode errors that Martin v. L√∂wis suggested adding a module attribute in sys to specify whether Unicode errors should be ignored or not. M.A. Lemburg, though, thought it was a bad idea and suggested instead that people use a custom codec that relaxed the error-handling. the thread seemed to end with no changes planned. Contributing threads: ` Relaxing Unicode error handling <http://mail.python.org/pipermail/python-dev/2004-January/041605.html>`__ --------------------------------------------------------------------------------------- new PEPs (sorry, nothing witty came to me about PEPs that was not excruciatingly corny) --------------------------------------------------------------------------------------- In all cases, ignore the Created date in terms of posting date; click on the Last Modified link if you care to see when the PEP was officially added. `PEP 324`_ proposes a new module named popen5. As suggested by the name, it hopes to come up with a unified module for process creation. To see Guido's initial response to the PEP and what he thinks is a "category killer" and why any new additions to the stdlib must be one, read http://mail.python.org/pipermail/python-dev/2004-January/041698.html . `PEP 325`_ proposes a 'close' method for generators so as to handle what normally would be handled in a try/finally block (such as closing files and such). `PEP 326`_ wants to add maximum and minimum singletons. `PEP 327`_ is the long-awaited decimal type PEP that has been in the process of being refined for quite a while. Development in the sandbox has been moving forward. `PEP 328`_ is the 'import' PEP in terms of multi-line imports and dealing with relative imports. .. _PEP 324: http://python.org/peps/pep-0324.html .. _PEP 325: http://python.org/peps/pep-0325.html .. _PEP 326: http://python.org/peps/pep-0326.html .. _PEP 327: http://python.org/peps/pep-0327.html .. _PEP 328: http://python.org/peps/pep-0328.html Contributing threads: - `PEP 324: popen5 - New POSIX process module <http://mail.python.org/pipermail/python-dev/2004-January/041606.html>`__ - `New version of installer <http://mail.python.org/pipermail/python-dev/2004-January/041672.html>`__ - `prePEP "Decimal data type" v0.2 <http://mail.python.org/pipermail/python-dev/2004-January/041691.html>`__ - `PEP 326 (quick location possibility) <http://mail.python.org/pipermail/python-dev/2004-January/042303.html>`__ - `PEP 327: Decimal Data Type <http://mail.python.org/pipermail/python-dev/2004-January/042347.html>`__ ------------------------------------- Making Python and HP-UX friends again ------------------------------------- Cameron Laird said he wanted to try to spear-head an attempt to get Python to compiled on HP-UX correctly. In the past threading support has been out of the question and getting Tkinter to go has been an issue as well along with curses. Cameron said he would like to get Python working for HP-UX as far back as version 10.20, although he said he would also be fine with the current 11.x versions. Most of it seems to have to do with requiring tweaks to Configure.in, Modules/Setup, and setup.py . As of this exact second no patches have been added to SourceForge_. You can get a version of Python 2.3.3 compiled for HP-UX at http://hpux.cs.utah.edu/hppd/hpux/Languages/python-2.3.3/ . This also led to a slight discussion of how slightly crufty Configure.in is. Any help bringing it up-to-date or cleaning up would be appreciated. Contributing threads: - `HP-UX clean-up <http://mail.python.org/pipermail/python-dev/2004-January/041607.html>`__ ---------------------------- msi installer for Python 2.4 ---------------------------- Going for the record of the person mentioned the largest number times in a single Summary who is not labeled a BDFL, Martin v. L√∂wis updated his msi installer for Python 2.4 . It can be found at http://www.dcl.hpi.uni-potsdam.de/home/loewis/python2.4.0.12421.msi along with info on the installer at http://www.dcl.hpi.uni-potsdam.de/home/loewis/msipackage.html . Contributing threads: - `New version of installer <http://mail.python.org/pipermail/python-dev/2004-January/041661.html>`__ - `Python MSI <http://mail.python.org/pipermail/python-dev/2004-January/041921.html>`__ ---------------------- New collections module ---------------------- Raymond Hettinger has created a new module called 'collections'. It primary purpose is to be home to "high-performance container datatypes". To start, it only has an implementation of deques. Contributing threads: - `collections module <http://mail.python.org/pipermail/python-dev/2004-January/041829.html>`__ - `collections module (correction) <http://mail.python.org/pipermail/python-dev/2004-January/041899.html>`__ - `Collections <http://mail.python.org/pipermail/python-dev/2004-January/042270.html>`__ ---------------- CJKCodecs in 2.4 ---------------- A perk of having Hye-Shik Chang an official developer of Python is getting his CJKCodecs integrated into Python 2.4 . Contributing threads: - `CJKCodecs integration into Python <http://mail.python.org/pipermail/python-dev/2004-January/041836.html>`__ - `Oodles of warnings in cjkcodecs <http://mail.python.org/pipermail/python-dev/2004-January/042203.html>`__ --------------- Statistics talk --------------- Raymond Hettinger asked for some suggestions on a statistics module he was working on. A whole bunch of stuff from names to algorithms to include came up. There is now a module in the sandbox being worked on to implement what was discussed. Contributing threads: - `Accumulation module <http://mail.python.org/pipermail/python-dev/2004-January/041988.html>`__ ------------------------------------ Installer problems for MacPython-OS9 ------------------------------------ Jack Jansen told python-dev how he has not been able to distribute a version of MacPython-OS9 for Python 2.3.3 because the free license for the installer expired. It was suggested that the PSF_ pay for a license. If you think this is a good idea and you are a PSF member consider bringing the topic up at the general meeting to be held at PyCon_. Contributing threads: - `No more releases of MacPython-OS9? <http://mail.python.org/pipermail/python-dev/2004-January/042022.html>`__ -------------------------------------- Anyone want to maintain MacPython-OS9? -------------------------------------- If anyone would like to take over maintenance of MacPython-OS9 so that it continues to exist beyond the 2.3 branch then contact Jack Jansen. Contributing threads: - `PEP 11 mistake? <http://mail.python.org/pipermail/python-dev/2004-January/042036.html>`__ -------------- Python in 2003 -------------- Go to http://python.org/topics/2003.html to read AM Kuchling's report on what happened to Python in 2003. Contributing threads: - `Python in 2003 summary <http://mail.python.org/pipermail/python-dev/2004-January/042049.html>`__ --------------------------------- Compiling using the free .NET SDK --------------------------------- If you wish to compile Python using the free .NET SDK then read the first email in the contributing thread thanks to someone named Garth. Contributing threads: - `Compiling python with the free .NET SDK <http://mail.python.org/pipermail/python-dev/2004-January/042053.html>`__ -------------------------- No dict.addlist() for you! -------------------------- The idea of adding a method to dict called 'addlist(k,v)' that would act like ``d.setdefault(k, []).append(v)``. It was eventually agreed upon that the perk of having it as a part of dict was not justified since the idiom it was implementing is simple enough so as to not really require adding the method. Contributing threads: - `dict.addlist() <http://mail.python.org/pipermail/python-dev/2004-January/042114.html>`__ -------------------------------------------------------- Want to be able to change Python's name at compile time? -------------------------------------------------------- Jack Jansen asked what people thought of adding the ability of being able to specify the name of Python through 'configure' and have the permeate throughout the code. The main reason for this is to allow people on OS X to be able to have other framework builds of Python that don't interfere with the installed version on OS X 10.3 . The thread ended with no definitive decision as to whether to move ahead or not. Contributing threads: - `Configure option to change Python's name? <http://mail.python.org/pipermail/python-dev/2004-January/042153.html>`__ --------------------------------- You think you are a Hotshot, huh? --------------------------------- Sparked by a question about where the development of the Hotshot profiler was, a new file was added to the scripts directory for making it easier to launch Hotshot for profiling. Contributing threads: - `Hotshot <http://mail.python.org/pipermail/python-dev/2004-January/042222.html>`__ ------------------------------------------------- Happy patch/bug statistics days are back again... ------------------------------------------------- Kurt Kaiser has taken over for Skip Montanaro (thanks to both for continuing and starting this weekly email, respectively) for sending out the "Weekly Python Patch/Bug Summary" email. Contributing threads: - `Weekly Python Patch/Bug Summary <http://mail.python.org/pipermail/python-dev/2004-January/042244.html>`__ --------------------------------------------------- Change in posting rules to python-dev (but barely!) --------------------------------------------------- The posting rules to python-dev have changed so that emails from non-subscribers must be ok'ed by moderators. But joining python-dev is still open to the public and requires no clearance from anyone so it is not a big hurdle to overcome to post to the list. Contributing threads: - `Proposed: change to posting rules for python-dev <http://mail.python.org/pipermail/python-dev/2004-January/042358.html>`__ ----------------------------------- GPL code in Python core is not okay ----------------------------------- Although the question was specific to python-mode.el, the general answer is that GPL code is not allowed into Python. The clash of the GPL with the PSF license since the latter is BSD-style. Contributing threads: - `Would GPL on python-mode.el be a problem? <http://mail.python.org/pipermail/python-dev/2004-January/042311.html>`__

2 1

Re: [Python-checkins] python/dist/src/Lib/lib-tk Tkinter.py, 1.178, 1.179
by Neal Norwitz Feb. 19, 2004

Feb. 19, 2004

David, Thanks for adding a test for _tkinter.c. It's a really good start. Unfortunately, testPackageRequire() fails for me because I don't have Tclx. Is there any way to make the test more robust? I also have a question about the implementation. It looks like useTK is required to be an integer. Is that correct? I would have expected to be able to use any boolean value. Neal -- On Tue, Feb 17, 2004 at 09:59:55PM -0800, david_ascher(a)users.sourceforge.net wrote: > Update of /cvsroot/python/python/dist/src/Lib/lib-tk > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv24617/dist/src/Lib/lib-tk > > Modified Files: > Tkinter.py > Log Message: > Implementation of patch 869468 > > Allow the user to create Tkinter.Tcl objects which are > just like Tkinter.Tk objects except that they do not > initialize Tk. This is useful in circumstances where the > script is being run on machines that do not have an X > server running -- in those cases, Tk initialization fails, > even if no window is ever created. > > Includes documentation change and tests. > > Tested on Linux, Solaris and Windows. > > Reviewed by Martin von Loewis. > > > Index: Tkinter.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/lib-tk/Tkinter.py,v > retrieving revision 1.178 > retrieving revision 1.179 > diff -C2 -d -r1.178 -r1.179 > *** Tkinter.py 12 Feb 2004 17:35:09 -0000 1.178 > --- Tkinter.py 18 Feb 2004 05:59:53 -0000 1.179 > *************** > *** 1547,1551 **** > of an appliation. It has an associated Tcl interpreter.""" > _w = '.' > ! def __init__(self, screenName=None, baseName=None, className='Tk'): > """Return a new Toplevel widget on screen SCREENNAME. A new Tcl interpreter will > be created. BASENAME will be used for the identification of the profile file (see > --- 1547,1551 ---- > of an appliation. It has an associated Tcl interpreter.""" > _w = '.' > ! def __init__(self, screenName=None, baseName=None, className='Tk', useTk=1): > """Return a new Toplevel widget on screen SCREENNAME. A new Tcl interpreter will > be created. BASENAME will be used for the identification of the profile file (see > *************** > *** 1553,1559 **** > It is constructed from sys.argv[0] without extensions if None is given. CLASSNAME > is the name of the widget class.""" > - global _default_root > self.master = None > self.children = {} > if baseName is None: > import sys, os > --- 1553,1562 ---- > It is constructed from sys.argv[0] without extensions if None is given. CLASSNAME > is the name of the widget class.""" > self.master = None > self.children = {} > + self._tkloaded = 0 > + # to avoid recursions in the getattr code in case of failure, we > + # ensure that self.tk is always _something_. > + self.tk = None > if baseName is None: > import sys, os > *************** > *** 1562,1567 **** > if ext not in ('.py', '.pyc', '.pyo'): > baseName = baseName + ext > ! self.tk = _tkinter.create(screenName, baseName, className) > ! self.tk.wantobjects(wantobjects) > if _MacOS and hasattr(_MacOS, 'SchedParams'): > # Disable event scanning except for Command-Period > --- 1565,1580 ---- > if ext not in ('.py', '.pyc', '.pyo'): > baseName = baseName + ext > ! interactive = 0 > ! self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk) > ! if useTk: > ! self._loadtk() > ! self.readprofile(baseName, className) > ! def loadtk(self): > ! if not self._tkloaded: > ! self.tk.loadtk() > ! self._loadtk() > ! def _loadtk(self): > ! self._tkloaded = 1 > ! global _default_root > if _MacOS and hasattr(_MacOS, 'SchedParams'): > # Disable event scanning except for Command-Period > *************** > *** 1588,1592 **** > self.tk.createcommand('tkerror', _tkerror) > self.tk.createcommand('exit', _exit) > - self.readprofile(baseName, className) > if _support_default_root and not _default_root: > _default_root = self > --- 1601,1604 ---- > *************** > *** 1630,1633 **** > --- 1642,1654 ---- > sys.last_traceback = tb > traceback.print_exception(exc, val, tb) > + def __getattr__(self, attr): > + "Delegate attribute access to the interpreter object" > + return getattr(self.tk, attr) > + def __hasattr__(self, attr): > + "Delegate attribute access to the interpreter object" > + return hasattr(self.tk, attr) > + def __delattr__(self, attr): > + "Delegate attribute access to the interpreter object" > + return delattr(self.tk, attr) > > # Ideally, the classes Pack, Place and Grid disappear, the > *************** > *** 1645,1648 **** > --- 1666,1673 ---- > # copied into the Pack, Place or Grid class. > > + > + def Tcl(screenName=None, baseName=None, className='Tk', useTk=0): > + return Tk(screenName, baseName, className, useTk) > + > class Pack: > """Geometry manager Pack. > > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://mail.python.org/mailman/listinfo/python-checkins

2 1

Re: [Python-checkins] python/dist/src/Objects listobject.c, 2.182, 2.183
by Neal Norwitz Feb. 19, 2004

Feb. 19, 2004

On Tue, Feb 17, 2004 at 03:36:19AM -0800, rhettinger(a)users.sourceforge.net wrote: > { > ! PyObject *v; > ! if (!PyArg_ParseTuple(args, "|i:pop", &i)) > return NULL; > --- 773,788 ---- > { > ! PyObject *v, *arg = NULL; > ! > ! if (!PyArg_UnpackTuple(args, "pop", 0, 1, &arg)) > return NULL; > + if (arg != NULL) { > + if (PyInt_Check(arg)) > + i = (int)(PyInt_AS_LONG((PyIntObject*) arg)); > + else { > + PyErr_SetString(PyExc_TypeError, "an integer is required"); > + return NULL; > + } > + } This is a change in behaviour. This used to work: >>> x = [1,2,3] >>> x.pop(1L) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: an integer is required

1 0