Mailman 3 September 2005 - Python-Dev

Re: [Python-Dev] Replacement for print in Python 3.0
by Michael Chermside 06 Sep '05

06 Sep '05

Please bear with me if this has already been stated, or if I ought to be directing this to the wiki instead of to python-dev at this point. I've been trying to follow this whole discussion but have only gotten as far as last Saturday. Two things: First of all, I wanted to encourage Guido. There have been lots of people objecting to "fixing" the print statement, but I for one agree that it's a wart which should be addressed if it can be done elegantly. I'm just not speaking up because others (particularly Guido) have already said most of what I am thinking and I don't want to clutter the discussion with "me too!"'s. And one thing which (as far as I've read) _IS_ a new suggestion. I agree that a new built-in function ought to be named 'print'. This poses problems for those who want to write code NOW that runs in Python 2.x (for large values of x) which will also run in 3.0. We could satisfy both people if in Python 2.x we introduced a built-in function named "print30" (for Python 3.0) with the intended new behavior. People could start coding now using the "print30" builtin. When Python 3.0 was released, 'print' would no longer be a keyword, and both 'print' and 'print30' would be built-ins that both refered to the same function. Sure, it's a tiny bit of backward compatibility cruft to have a second name for the builtin, but it may be worth it because the ability to write in the "Python 3.0 style" (all new-style classes, only raise proper exceptions, etc) in the 2.x series is a VERY useful feature. We want to handle the transition better than Perl. -- Michael Chermside

1 0

Re: [Python-Dev] Proof of the pudding: str.partition()
by Delaney, Timothy (Tim) 06 Sep '05

06 Sep '05

Fredrik Lundh wrote: > the problem isn't the time it takes to unpack the return value, the > problem is that it takes time to create the substrings that you don't > need. I'm actually starting to think that this may be a good use case for views of strings i.e. rather than create 3 new strings, each "string" is a view onto the string that was partitioned. Most of the use cases I've seen, the partitioned bits are discarded almost as soon as the original string, and often the original string persists beyond the partitioned bits. Tim Delaney

7 16

Re: [Python-Dev] Replacement for print in Python 3.0
by rzed 06 Sep '05

06 Sep '05

Guido van Rossum <guido(a)python.org> wrote: [...] > OK, still with me? This, together with the observation that the only > use cases for the delimiter are space and no space, suggests that we > should have separate printing APIs for each of the use cases (a), (b) > and (c) above, rather than trying to fold (b) into (a) using a way to > parameterize the separator (and the trailing newline, to which the > same argument applies). For example: > > (a) print(...) > (b) printraw(...) or printbare(...) > (c) printf(fmt, ...) > > Each can take a keyword parameter to specify a different stream than > sys.stdout; but no other options are needed. The names for (a) and (c) > are pretty much fixed by convention (and by the clamoring when I > proposed write() :-). I'm not so sure about the best name for (b), but > I think picking the right name is important. Applying the same reasoning as above, why not remove the last remaining keyword parameter by adding fprint(ftobj,...) fprintraw( ftobj,...) and fprintf(ftobj,fmt,...) functions? -- rzed

1 0

gdbinit problem
by Neal Norwitz 06 Sep '05

06 Sep '05

break in gdbinit is apparently does not break a loop, but rather sets a break point. I don't know how to hit the break within lineno with a simple test case. Debugging pychecker with a C extension (matplotlib) triggers it. The only way I could see to fix it was by setting a continue flag and testing it. Does anyone know a better way to fix this problem? A patch is attached which fixes the problem for me, but I would rather check in a better solution if one exists. Any ideas? Or should I just check in the attached patch. n -- more gory details. after the patch, i get the expected results: (gdb) pystack ./pychecker/checker.py (573): _initModule ./pychecker/checker.py (537): load ./pychecker/checker.py (517): addModule ./pychecker/checker.py (574): _initModule ./pychecker/checker.py (537): load ./pychecker/checker.py (517): addModule ./pychecker/checker.py (574): _initModule ./pychecker/checker.py (540): load ./pychecker/checker.py (668): processFiles ./pychecker/checker.py (721): main ./pychecker/checker.py (741): ? before the patch, i get this: (gdb) pystack ./pychecker/checker.py (Breakpoint 1 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 2 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 3 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 4 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 5 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 6 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 7 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 8 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 9 at 0x455372: file Objects/typeobject.c, line 2012. 584): _initModule ./pychecker/checker.py (Breakpoint 10 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 11 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 12 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 13 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 14 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 15 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 16 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 17 at 0x455372: file Objects/typeobject.c, line 2012. 545): load ./pychecker/checker.py (Breakpoint 18 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 19 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 20 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 21 at 0x455372: file Objects/typeobject.c, line 2012. 521): addModule ./pychecker/checker.py (Breakpoint 22 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 23 at 0x455372: file Objects/typeobject.c, line 2012. ---Type <return> to continue, or q <return> to quit--- Breakpoint 24 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 25 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 26 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 27 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 28 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 29 at 0x455372: file Objects/typeobject.c, line 2012. 584): _initModule ./pychecker/checker.py (Breakpoint 30 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 31 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 32 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 33 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 34 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 35 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 36 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 37 at 0x455372: file Objects/typeobject.c, line 2012. 545): load ./pychecker/checker.py (Breakpoint 38 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 39 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 40 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 41 at 0x455372: file Objects/typeobject.c, line 2012. 521): addModule ./pychecker/checker.py (Breakpoint 42 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 43 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 44 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 45 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 46 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 47 at 0x455372: file Objects/typeobject.c, line 2012. ---Type <return> to continue, or q <return> to quit--- Breakpoint 48 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 49 at 0x455372: file Objects/typeobject.c, line 2012. 584): _initModule ./pychecker/checker.py (Breakpoint 50 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 51 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 52 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 53 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 54 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 55 at 0x455372: file Objects/typeobject.c, line 2012. 545): load ./pychecker/checker.py (Breakpoint 56 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 57 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 58 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 59 at 0x455372: file Objects/typeobject.c, line 2012. 671): processFiles ./pychecker/checker.py (Breakpoint 60 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 61 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 62 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 63 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 64 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 65 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 66 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 67 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 68 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 69 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 70 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 71 at 0x455372: file Objects/typeobject.c, line 2012. ---Type <return> to continue, or q <return> to quit--- Breakpoint 72 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 73 at 0x455372: file Objects/typeobject.c, line 2012. 735): main ./pychecker/checker.py (Breakpoint 74 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 75 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 76 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 77 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 78 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 79 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 80 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 81 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 82 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 83 at 0x455372: file Objects/typeobject.c, line 2012. 796): ?

3 3

Revising RE docs (was: partition() (was: Remove str.find in 3.0?))
by Michael Chermside 05 Sep '05

05 Sep '05

Barry Warsaw writes: > Although it's mildly annoying that the docs describe the compiled method > names in terms of the uncompiled functions. I always find myself > looking up the regexp object's API only to be shuffled off to the > module's API and then having to do the argument remapping myself. An excellent point. Obviously, EITHER (1) the module functions ought to be documented by reference to the RE object methods, or vice versa: (2) document the RE object methods by reference to the module functions. (2) is what we have today, but I would prefer (1) to gently encourage people to use the precompiled objects (which are distinctly faster when re-used). Does anyone else think we ought to swap that around in the documentation? I'm not trying to assign more work to Fred... but if there were a python-dev consensus that this would be desirable, then perhaps someone would be encouraged to supply a patch. -- Michael Chermside

9 12

Re: [Python-Dev] Replacement for print in Python 3.0
by Meyer, Tony 05 Sep '05

05 Sep '05

> In the end the process is not democratic. Which may make it easier: rather than having to convince 50%+ of the people, one only has to convince a single person... > I don't think there's anything that can change my mind > about dropping the statement. As long as "I don't think there's anything" isn't "There isn't anything", there is still hope, and the potential that the one person's opinion that matters can be changed. However, when I wrote the email, I assumed you wouldn't read it (because you said you were leaving the discussion until there was a PEP). What I wanted to know was what the best way of putting together succinct, clear, reasons why you should change your mind would be, so that could be done. Even if you didn't change your mind, at least it would be (judging from previous decision reversals) the best shot. =Tony.Meyer

1 0

Re: [Python-Dev] Replacement for print in Python 3.0
by Meyer, Tony 05 Sep '05

05 Sep '05

[Guido] > The print statement harks back to ABC and even > (unvisual) Basic. Out with it! [Barry] > I have to strongly disagree. As would I. From observing recent discussions here, it would be helpful if everyone else that agrees could come up with a list (a wiki page on python.org, perhaps?) of simple, to-the-point, reasons why losing print is a bad idea. Once Guido sees the huge list of reasons in favour of keeping it, versus the one or two reasons against it (and ruminates on it while 2.5 through 2.9 are released) I'm sure he'll see reason. FWIW, I wouldn't really care if >> or the trailing comma was lost. [Barry] > The print statement is simple, easy to understand, and > easy to use. For use cases like debugging or the interactive > interpreter [...] I think it's hard to beat the useability > of print with a write() function, even if builtin. ISTM that Barry nails the key reasons here. One of the real strengths of Python is that it can be used in a wide range of applications, many of which don't need to be burdened with a complex logging strategy, don't have a GUI, aren't inside a web browser, and so on. "print" is the best example I can think of for "practicality beats purity". Writing to stdout is as common in the code I write as loops - it's worth keeping such basic functionality as elegant, simple, easy to understand, and easy to use as possible. (This is certainly my motiviation, not any concern about backwards compatibility). With standard English keyboards, at least, the '(' and ')' keys are also inconvenient to type, compared to lower-case English characters. Fundamental actions like writing to stdout deserve simplicity. =Tony.Meyer

2 1

Asynchronous use of Traceback objects
by Christopher Armstrong 05 Sep '05

05 Sep '05

With the implementation and soon release of PEP 342, I've been thinking more about traceback objects lately. First I'll give you some background information for my problem. I've implemented a module for integrating Twisted's Deferreds with the new yield expression, that allows you to do stuff like: @defgen def foo(): x = yield deferredOperation() print x Basically, defgen checks for Deferreds coming out of the generator, and when it finds one, adds a callback to that Deferred which will resume the generator, sending the result in. Since Deferreds have error support, it also allows code like this: @defgen def foo(userinput): try: x = yield deferredOperation(userinput) except ValueError: "Crap, wrong user input!" We have this object in Twisted called the "Failure", which is used for conveniently passing around exceptions asynchronously, and Deferreds use them to represent errors in deferred operations. The Failure objects have a reference to an exception object and the traceback that was associated with the original raising of that exception. However, we can only hold on to that traceback for so long, because traceback objects have references to so many things and can so easily cause horrible GC issues. The loss of this traceback object isn't *usually* a problem because we store enough other information in the Failure object to print representations of tracebacks nicely. However, if we try to re-raise the exception, we lose that traceback information. defgen re-raises the exception from a Failure into a defgen-using function with g.throw(). Unfortunately, quite often the traceback has been cleaned from the Failure object, and this means you'll get exceptions in defgen-using code with very bizarre and uninformative tracebacks. I had the idea to create a fake Traceback object in Python that doesn't hold references to any frame objects, but is still able to be passed to 'raise' and formatted as tracebacks are, etc. Unfortunately, raise does a type check on its third argument and, besides, it seems the traceback formatting functions are very reliant on the internal structure of traceback objects, so that didn't work. It does seem that I would be able to construct a passable fake Traceback object from C code -- one that had references to fake frames. These fake objects would only remember the original line numbers, filenames and so forth so that traceback printing could still work. I can try implementing this soon, but I'd just like to make sure I'm on the right track. For example, perhaps a better idea would be to change the traceback-printing functions to use Python attribute lookup instead of internal structure lookup, and then change raise to accept arbitrary Python objects as its third argument, as long as it matches the traceback interface. That would probably mean much more work, though. One concern is that I really don't like requiring C modules to use Twisted; all of the ones currently in there are optional. What's the likelihood of such a traceback-constructor getting its way into CPython if I do implement it? It may seem niche, but I expect many Twisted users would like to use PEP 342 defgen (many users are already using the defgen I wrote for python 2.2 generators). Thanks for any help, and have fun, -- Twisted | Christopher Armstrong: International Man of Twistery Radix | -- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// | -- http://twistedmatrix.com |o O| | w----v----w-+

3 4

New Wiki page - PrintAsFunction
by Nick Coghlan 04 Sep '05

04 Sep '05

All, I put up a Wiki page for the idea of replacing the print statement with an easier to use builtin: http://wiki.python.org/moin/PrintAsFunction Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com

5 5

Re: [Python-Dev] Replacement for print in Python 3.0
by Tony Meyer 04 Sep '05

04 Sep '05

[Nick Coghlan] > "Print as statement" => printing sequences nicely is a pain What's wrong with this? >>> print range(10) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> print tuple("string") ('s', 't', 'r', 'i', 'n', 'g') This is a serious question - that's how I would expect a print function to work anyway. > "Print as statement" => can't easily change the separator [etc] To me, the point of the builtin print is that it's simple. If you want to control what separator is used, or if there is a newline at the end, or print to something that isn't sys.stdout, or some other magic, then use sys.stdout.write(). If you want to get the contents of __unicode__/__str__ of an object to stdout, which there has been overwhelming evidence is a very common task, then print is a fantastically simple and straightforward way to do that. [Terry Reedy] > For quickly adding debug prints, two extra ()s are a small burden, > but if the function were called 'out', then there would still be just five > keystrokes. But seven keypresses (assuming one is using a keyboard where you use shift to get '(' and ')'). It sounds trivial, but a print statement (i.e. no ()) looks clean and concise. I like this: while True: pass More than: while (true) {} For the same reason. This is a big plus of Python vs. C. [Guido] > Consider this: if Python *didn't* have a print statement, but > it had a built-in function with the same functionality > (including, say, keyword parameters to suppress the trailing > newline or the space between items); would anyone support a > proposal to make it a statement instead? Yes. If it didn't have the redirect stuff; I would like it more if it also didn't have the trailing comma magic. "print" is a fundamental; it deserves to be a statement :) =Tony.Meyer

3 2