Mailman 3 December 2003 - Python-Dev

Re: [Python-Dev] Banishing apply(), buffer(), coerce(), and intern()
by Anthony Baxter Dec. 1, 2003

Dec. 1, 2003

>>> Guido van Rossum wrote > Yes, backticks will be gone in 3.0. But I expect there's no hope of > getting rid of them earlier -- they've been used too much. I suspect Then let's kill all use of backticks in the standard library. There's a lot of them. Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never to late to have a happy childhood.

6 9

Re: [Python-Dev] Tutorial: Brief Introduction to the Standard Library
by Michael Chermside Dec. 1, 2003

Dec. 1, 2003

Raymond> - timeit (because it answers most performance questions in a Raymond> jiffy) Skip> -1. Newbies should probably not be worried about performance too Skip> much. In addition, I think most performance questions are deeper Skip> than those which can be answered by timeit (think naive O(n^2) Skip> algorithms). Skip is right on both counts: newbies DO worry too much about performance, and they WON'T be able to think deeply about performance issues like how an algorithm scales (unless they're new to Python but not to programming). But I still agree with Raymond that timeit should be included. The fact is, newbies ARE going to worry too much about performance, whether we want them to or not. And a VERY frequently asked question on c.l.py is "what's the fastest way to do X". IMHO, learning to answer this kind of question themselves is MORE important than learning not to ask the question when it isn't needed -- just like learning to use the interactive interpreter to answer "does the syntax X work?", it makes them more self sufficient, and therefore more self confident. So I'd say DO include a (brief!) tutorial example on using timeit. But perhaps craft the example so it shows two approaches, one readable and one obscure, and the obscure one is shown to be FASTER but not MUCH faster, and is therefore DROPPED in favor of the more readable. (Hey... rigging the problem set in order to model good practices is an old teacher's trick I've used often.) And having piped up with my own 2c, I'd better pay up. Raymond... if you're working on this and need help, send me an example or two of other modules (so I can try to follow your style) and I'll volunteer to write one for timeit. -- Michael Chermside

2 1

RE: [Python-Dev] possible backward incompatibility in test.regrtest
by Michael Chermside Dec. 1, 2003

Dec. 1, 2003

> Unless I miss something trivial (I hope so), I'd have to give up > using the test.regrtest module. I appreciate any comment. Maybe the thing to do is to change: > if test.startswith('test.'): > abstest = test > else: > # Always import it from the test package > abstest = 'test.' + test > the_package = __import__(abstest, globals(), locals(), []) to this: > if test.startswith('mytest.'): > abstest = test > else: > # Always import it from the test package > abstest = 'mytest.' + test > the_package = __import__(abstest, globals(), locals(), []) in your own copy of regrtest. Converting to unittest would be better, but this is a fix that would at least prevent immediate breakage. -- Michael Chermside

1 0

adding save() and load() function for interactive use
by Gerrit Holl Dec. 1, 2003

Dec. 1, 2003

Hello, I have a proposal to enhance the usefulness of Python for learning purposes. RFE#852222: I think that for learning Python, it would be nice to save the current namespace to a file using a builtin save() function (and corresponding load()). For beginning programmers, it would be nice to be able to tinker interactively with the shell, defining functions and maybe even classes, with which they can continue later on. save() is easily implemented by pickling locals(); load() is easily implemented by updating locals() while unpickling it. The functions would take a filename (string) as an argument. In Idle, they could be in the menu. Like the _ variable, load() and save() are only present in the interactive shell (some global .pythonrc?). Example usage: >>> def foo(): ... raw_input("Do you like it?" ) ... print "Great!" >>> save("~/session") >>> load("~/session") >>> foo() Do you like it? yes Great! Note that this code is untested. I think this would be a nice addition to Python 2.4. yours, Gerrit. -- 105. If the agent is careless, and does not take a receipt for the money which he gave the merchant, he can not consider the unreceipted money as his own. -- 1780 BC, Hammurabi, Code of Law -- Asperger's Syndrome - a personal approach: http://people.nl.linux.org/~gerrit/english/

3 3

PyCon DC 2004 - Registration about to open!
by Steve Holden Dec. 1, 2003

Dec. 1, 2003

Dear Python User: You have probably been wondering why you haven't yet heard that PyCon has opened its doors for registration. Well, we are a volunteer organization, and it often takes more time than anticipated to put things together. Welcome to the world of open source :-) I am happy to be able to tell you that thanks to sterling work by Trevor Toenjes we are now in a position to accept your registrations. All you need to do is navigate to http://dc2004reg.pycon.org/ and make the appropriate entries. This year we all have the opportunity to add a PSF donation to the registration fee, and I hope many of you will follow my example and donate a little extra to assist the Foundation in its goals. There is still lots to be done -- for example, we are *also* late with the system to accept submissions, so the original December 1 deadline will be extended by at least a month to ensure that everyone gets plenty of chance to submit papers telling us what they've been up to with Python. We are also encouraging students to attend the conference by giving them a significant reduction from the standard fee, and we hope that this will result in even wider participation by the educational community. Last year was an exciting departure from the traditional "professional" conference format, and I hope that we will be able to improve on it next time. I look forward to seeing you there! Sincerely Steve Holden Chairman PyCon DC 2004

1 0

possible backward incompatibility in test.regrtest
by Tamito KAJIYAMA Dec. 1, 2003

Dec. 1, 2003

Hi developers, It seems that the test.regrtest module has a possible backward incompatibility with regard to pre-Python 2.3 releases. I have a test suit implemented using the test.regrtest module. In this test suit, my own tests are invoked by a script like this: import os from test import regrtest regrtest.STDTESTS = [] regrtest.main(testdir=os.getcwd()) This script runs fine with 2.2 but does not with 2.3, since regrtest.py in Python 2.3 has the following lines in runtest() (introduced in Revision 1.87.2.1. See [1]): if test.startswith('test.'): abstest = test else: # Always import it from the test package abstest = 'test.' + test the_package = __import__(abstest, globals(), locals(), []) That is, tests must be in a package named "test". However, this package name is already used by the standard library, and AFAIK multiple packages with the same package name cannot exist. In other words, any additional tests (i.e. my own tests) have to be put into the test package in the standard library. Otherwise, the additional tests won't be found. IMHO, this change in 2.3 is not reasonable. Unless I miss something trivial (I hope so), I'd have to give up using the test.regrtest module. I appreciate any comment. Thanks, -- KAJIYAMA, Tamito <kajiyama(a)grad.sccs.chukyo-u.ac.jp> [1] http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Lib/test/regrt…

2 1

Re: [Python-Dev] Banishing apply(), buffer(), coerce(), and intern()
by Anthony Baxter Dec. 1, 2003

Dec. 1, 2003

> [Walter] > > If you're willing to review the patch, I'm going to give it a try. > > The honor of second review should go to Anthony ;-) This is his itch. > If a third review is needed to make it error free, I would be happy to > accommodate. I'll see how I go for time - with the 2.3.3 release coming up, I'm unlikely to have a whole lot of spare cycles. Anthony

1 0

backticks delenda est
by Anthony Baxter Dec. 1, 2003

Dec. 1, 2003

>>> "Raymond Hettinger" wrote > Advisory from a micro-performance hawk: Backticks are faster than > repr() > > >>> from timeit import Timer > >>> min(Timer('`x`', 'x=1').repeat(3)) > 1.4857213496706265 > >>> min(Timer('repr(x)', 'x=1').repeat(3)) > 1.7748914665012876 Presumably because the backtick version doesn't have to look up 'repr', then call it. >>> def f1(a): ... repr(a) ... >>> >>> def f2(a): ... `a` ... >>> import dis >>> dis.dis(f1) 2 0 LOAD_GLOBAL 0 (repr) 3 LOAD_FAST 0 (a) 6 CALL_FUNCTION 1 9 POP_TOP 10 LOAD_CONST 0 (None) 13 RETURN_VALUE >>> dis.dis(f2) 2 0 LOAD_FAST 0 (a) 3 UNARY_CONVERT 4 POP_TOP 5 LOAD_CONST 0 (None) 8 RETURN_VALUE This is presumably something that a future optimiser could "fix", once we have the no-shadowing-builtins rule enforced. I don't think this is a serious enough problem to merit leaving the backticks in the std lib. I find them annoying, and hard to read. In general, the backticks are in debugging and error handling code, so the performance penalty should be negligible. Anthony

1 0