Re: [Python-Dev] Replacement for print in Python 3.0
Terry Reedy wrote: > "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message >>- Going from statement to function? > > > Minor. 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. Nick's output() convinced me that there are compensations to > the function form. Besides, having used the argument of aesthetic > consistency elsewhere, I can hardly deny it to you ;-). I've added a bit to the wiki to look at different names that have been suggested. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > With so many people expressing a gut response and not saying what in > the proposal they don't like, it's hard to even start a response. > Is it... For me a bit of several things though with quite variable intensity. First, print, as an abbreviation of looped writes, works fine for its appointed task. It gives me don't-care-about-the-format info on values with near minimal overhead. So change needs clear justification. > - Going from statement to function? Minor. 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. Nick's output() convinced me that there are compensations to the function form. Besides, having used the argument of aesthetic consistency elsewhere, I can hardly deny it to you ;-). > - Losing the automatically inserted space? Major. This is an essential plus of print. > - Having to write more to get a newline appended? Near major. See above. I believe that two people have reported that around 85% of their prints use these defaults, so I think adding a keyword for something other would be the way to go. > - Losing the name 'print'? You gave one reason for this as disassociating from Basic. I can see how a CS grad would want to do so, but Basic once was the vehicle for CP4E (computer programming for everyone) that you want Python to become. In fact, I think PSF should promote Python as the 'Basic for the 21st Century' that should be on most desktops the way Basic once was. So I would prefer to see a different reason for a name change. > - [dash added] Some responses seemed to have missed [snip] > that I was proposing builtins in addition to the stream methods, My objections here are first the plural, which does not seem really necessary, and second the longer (in chars and syllables) and also old name 'writeln' from Pascal for the one that does what print does. > I'd like to be flexible on all points *except* the syntax -- I really > want to get rid of print as a *statement*. [snip] > would anyone support a proposal to make it a statement instead? Good question. Most Python statements benefit from statement syntax because their function syntax equivalent would be a little to hughly more awkward. This is mainly because parts of the statement are implicitly quoted. (Lisp does this with special forms and macros, but I prefer the Python way.) The two syntax tricks in print are different in that they are easily replaced by keywords. So I strongly suspect 'no'. Terry J. Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Neal Norwitz wrote: > I'm sure this tool wouldn't be perfect, but if it did most of the > work, would that change opinions? To me, the main objection seems to revolve around the fact that people would like to be able to "future-proof" Python 2.x code so that it will also run on Py3k. We're steadily accumulating collections of "old ways" and "new ways", and the Py3k transition should mainly be about deleting the "old ways". That is, if the way something is going to be done is to change in Py3k, the new alternative should already be in place towards the end of the 2.x series, so that Py3k is only a potential problem if people are still using the "old ways". Maybe "from __future__ import py3k" would do the trick ;) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/2/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Nope, but there is a large body of code out there that does use print > statements already. Again, I know you're prepared for breakage, but that > doesn't necessarily mean a completely blank sheet of paper. Ideally I very much prefer that print become a function. However, the major backlash has swayed me some, if for no other reason that people are so strongly against changing it. What if a tool existed that did the conversion? I realize that the tool is unlikely to be perfect, but what if it could do 99.9% of the job? I'm not thinking about just fixing print, but also converting iterkeys/itervalues/iteritems, xrange -> range, raw_input -> input, warning about use of input(), etc. I'm sure this tool wouldn't be perfect, but if it did most of the work, would that change opinions? n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Guido> Is it... Guido> - Going from statement to function? Guido> - Losing the automatically inserted space? Guido> - Having to write more to get a newline appended? Guido> - Losing the name 'print'? You forgot - gratuitous breakage? I realize you're talking about Py3K, so breakage is allowed, but the advantages of a print function/method over the current print statement don't seem sufficient to warrant the level of code change (probably simple but tedious) that will be necessary to convert 2.x to 3.x. Guido> Consider this: if Python *didn't* have a print statement, but it Guido> had a built-in function with the same functionality (including, Guido> say, keyword parameters to suppress the trailing newline or the Guido> space between items); would anyone support a proposal to make it Guido> a statement instead? Nope, but there is a large body of code out there that does use print statements already. Again, I know you're prepared for breakage, but that doesn't necessarily mean a completely blank sheet of paper. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Phillip J. Eby wrote: > At 11:02 AM 9/3/2005 +1000, Nick Coghlan wrote: > >> Printing the items in a sequence also becomes straightforward: >> >> print " ".join(map(str, range(10))) => output(*range(10)) >> >> Playing well with generator expressions comes for free, too: >> >> print " ".join(str(x*x) for x in range(10)) >> => output(*(x*x for x in range(10))) > > > An implementation issue: that generator expression will get expanded > into a tuple, so you shouldn't use that for outputting large sequences. Agreed - but using join with print suffers from a similar problem, in that it builds the large string in memory before displaying it. I actually hope that extended function call syntax in Py3k will use iterators rather than tuples so that this problem goes away. > I don't much care for 'output' as the name, or 'end' as the end-of-line > arguments, but for the most part I like the semantics; being able to > drop the separator or change the end-of-line string make lots of use > cases straightforward, and perhaps almost worth the parentheses. > > My inclination would be to call the function 'print', though, and rename > 'end' to 'trailer'. 'print' is Py24 incompatible though, which is why I didn't use it for the sample code. The version I put on the wiki now uses 'term' for the line terminator keyword, but I'm not too worried about the exact names at this point. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
"Paul F. Dubois" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Remove the print statementI laughed until my sides hurt. Hello? Try > dating girls and talking to normal people, geek boys. > > We scientists still use these for debugging. We never 'move on' very far > from the tutorial. The salient feature about print statements is that > they live to be put in and commented out 10 minutes later, without some > import being required or other enabling object being around. > > Easy things should be easy. Hard things should be possible. I don't > believe the person who said the trailing comma case mixed up anybody, > not for more than 10 seconds anyway. > > OK, now that I've offended everyone, I'll go back into retirement. But I > *am* laughing at you. > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New Wiki page - PrintAsFunction
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 | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/2/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 11:02 AM 9/3/2005 +1000, Nick Coghlan wrote: > >Printing the items in a sequence also becomes straightforward: > > > >print " ".join(map(str, range(10))) => output(*range(10)) > > > >Playing well with generator expressions comes for free, too: > > > >print " ".join(str(x*x) for x in range(10)) > > => output(*(x*x for x in range(10))) > > An implementation issue: that generator expression will get expanded into a > tuple, so you shouldn't use that for outputting large sequences. Then how about:: output(*(x*x for x in range(10)), iter=1) Where all given iterable parameters are automatically iterated? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Wow. With so many people expressing a gut response and not saying what in the proposal they don't like, it's hard to even start a response. Is it... - Going from statement to function? - Losing the automatically inserted space? - Having to write more to get a newline appended? - Losing the name 'print'? Some responses seemed to have missed (or perhaps for stronger rhetorical effect intentionally neglected) that I was proposing builtins in addition to the stream methods, so that all those debug prints would be just as easy to add as before. And I don't think I ever said print was only for newbies! I'd like to be flexible on all points *except* the syntax -- I really want to get rid of print as a *statement*. 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? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
At 11:02 AM 9/3/2005 +1000, Nick Coghlan wrote: >Printing the items in a sequence also becomes straightforward: > >print " ".join(map(str, range(10))) => output(*range(10)) > >Playing well with generator expressions comes for free, too: > >print " ".join(str(x*x) for x in range(10)) > => output(*(x*x for x in range(10))) An implementation issue: that generator expression will get expanded into a tuple, so you shouldn't use that for outputting large sequences. I don't much care for 'output' as the name, or 'end' as the end-of-line arguments, but for the most part I like the semantics; being able to drop the separator or change the end-of-line string make lots of use cases straightforward, and perhaps almost worth the parentheses. My inclination would be to call the function 'print', though, and rename 'end' to 'trailer'. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Martin Blais wrote: > Funny enough, the syntax does not barf and goes undetected: Python generally allows trailing commas so that it is easier to write sequence literals which are appended to later. There's also the fact that a trailing comma is used to make a 1-element tuple - so it could be said that the exception is actually that the comma after the last item can be optionally left out when there is more than one item in the sequence :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Paul Moore wrote: > No-one is saying "crucial". We're just expressing opinions. But so are > those (even Guido!) who want to remove the print statement. No-one has > come up with a genuine, objective benefit to removing it (that I can > see). If there isn't one, then we're left with preferences, and > Guido's trumps everyone else's. You (as someone who agrees with Guido) > don't have anything to prove. Those of us who want to change Guido's > mind need to impress him with the strength of our opinions :-). "Print as statement" => printing sequences nicely is a pain "Print as function" => extended call syntax deals with sequences nicely "Print as statement" => can't easily change the separator "Print as function" => keyword argument handles the separator nicely "Print as statement" => trailing comma suppresses newline by magic "Print as function" => keyword argument handles the line terminator nicely "Print as statement" => redirection is via a magic symbol "Print as function" => keyword argument handles redirection nicely "Print as statement" => can't easily save 'settings' for re-use "Print as function" => can use functional.partial to create custom version See my other post where I present a Python 2.4 implementation of a function called "output" which does everything I describe above. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Steven Bethard wrote: > Well, my proposal (which differs from Guidos) is that the print > function (or whatever it ends up getting called) would have the > semantics: > > def print(*args): > sys.stdout.write(' '.join(str(arg) for arg in args)) > sys.stdout.write('\n') I'd rather see a signature with the expressiveness of the current print statement (full implementation below). I've called it 'output' rather than 'print' so that copy and pasting it into a 2.4 interactive session will work (I also think the symmetry with input is cute). With this function: print 1, 2, 3 => output(1, 2, 3) print >> sys.stderr, 1, 2, 3 => output(1, 2, 3, stream=sys.stderr) print "%d%d%d" % (1, 2, 3) => output(1, 2, 3, sep='') print 1, 2, 3, => output(1, 2, 3, end='') Printing a tab-separated or comma separated list becomes trivial: print "%d, %d, %d" % (1, 2, 3) => output(1, 2, 3, sep=', ') print "%d\t%d\t%d" % (1, 2, 3) => output(1, 2, 3, sep='\t') Printing the items in a sequence also becomes straightforward: print " ".join(map(str, range(10))) => output(*range(10)) Playing well with generator expressions comes for free, too: print " ".join(str(x*x) for x in range(10)) => output(*(x*x for x in range(10))) The capabilities of the current print statement reveal a lot of collective wisdom regarding what is useful - the only real issues are that the syntax is somewhat ugly and unique to the print statement, rather than using standard function call syntax, and that as a result of the first issue, it is difficult to control the behaviour of the separator. Turning it into a proper function with three keyword arguments (sep, end, stream) would allow both of these issues to be addressed, and also provide a whole lot of fringe benefits relating to printing of sequences as described above. Cheers, Nick. The sample implementation: def output(*args, **kwds): """Functional replacement for the print statement >>> output(1, 2, 3) 1 2 3 >>> output(1, 2, 3, sep='') 123 >>> output(1, 2, 3, sep=', ') 1, 2, 3 >>> output(1, 2, 3, end='Alternate line ending') 1 2 3Alternate line ending >>> import sys >>> output(1, 2, 3, stream=sys.stderr) 1 2 3 >>> output(*range(10)) 0 1 2 3 4 5 6 7 8 9 >>> output(*(x*x for x in range(10))) 0 1 4 9 16 25 36 49 64 81 """ # Parse the keyword-only optional arguments defaults = { "sep": " ", "end": "\n", "stream": sys.stdout, } for name, default in defaults.items(): item = None try: item = kwds[name] except KeyError: pass if item is None: kwds[name] = default sep, end, stream = kwds["sep"], kwds["end"], kwds["stream"] # Perform the print operation without building the whole string for arg in args[:1]: stream.write(str(arg)) for arg in args[1:]: stream.write(sep) stream.write(str(arg)) stream.write(end) -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
[EMAIL PROTECTED] wrote: > >> And good riddance! The print statement harks back to ABC and even > >> (unvisual) Basic. Out with it! > > Barry> I have to strongly disagree. The print statement is simple, easy > Barry> to understand, and easy to use. > > I'm with Barry. Even for non-debug use the print statement is suitable for > the majority of my output. 99.9% of my Python code is test harnesses to run low-level hardware control interface tests, for which printing to stdout works perfectly. Maybe one day I'll stick a GUI on the front end of them, but even then I will probably just be using subprocess to invoke the command line versions behind the scenes. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/2/05, Steven Bethard <[EMAIL PROTECTED]> wrote: > Paul Moore wrote: > > Interestingly enough, the other languages I use most (C, Java, > > VB(Script) and Javascript (under Windows Scripting Host)) all use > > functions for output. Except for C, I uniformly dislike the resulting > > code - the output structure gets hopelessly lost under the weight of > > string concatenation and explicitly added spaces. > > Are your complaints about Guido's proposal or mine? The complaint > above doesn't quite seem relevant to my proposal, which retains the > space-insertion. Basically, my proposal suggests that files (and > other streams) gain a print method like: > > class file(object): > ... > def print(self, *args): > self.write(' '.join(str(arg) for arg in args)) > self.write('\n') > > and the print statement becomes the builtin print() function, defined like: > > def print(*args): > sys.stdout.print(*args) > > Looking at your use cases, this seems to cover them pretty well: > > > - Debugging, most definitely. Adding a quick print "a =", a is often > > all that's needed. > > Use the builtin print(): > > print('a =', a) > > > - Logging, sometimes. When I just want some basic output, and don't > > want to deal with the complexity of the logging package. > > Use the builtin print(): > > print('some logging message', foo) > > > - Unix-style command-line utilities, where textual output to stdout is the > > norm. > > Use the builtin print(): > > print('line of output') > > > - Error and help messages, often with print >>sys.stderr > > Use the print() method of sys.stderr: > > sys.stderr.print('error or help message') > Wow, that's so cool actually, you make the concept of "print'ing" even more regular (on all file objects, and then builtin print is just like general print'ing, except for sys.stdout), we don't need a keyword argument for the stream anymore, and the special statement goes away. And if you like concise, then you could do something like this:: perr = sys.stderr.print ... perr("Error: comfobulator failed to initialize doogledigook.") I like it so much that my mind is wandering about hacking my sitecustomize.py to inject it in __builtin__ so I can start using it right now... +1 Also, you're making a point that I think seem to be missing: it's REALLY just about a couple of parentheses. Print statement without parens, print with parens same stuff. It's a builtin, it's still always there, and so it's still a convenient as before, except you have to type parentheses. On the upside: one less quirk/exception in the language (one more tiny step towards lisp, me love that, simple is good). I don't think that it would make it harder on the newbies either: less stuff to learn, it's just a function! Someone above proposed a string of one char as last argument would trigger the no-newline case. Why not use an empty string instead? print("Incomplete line", '') Seems like the thing that would disrupt print the least is an empty string... The special meaning is implied. Or if you want more verbose, a special symbol/value in a convenient namespace: print("Incomplete line", print.cont) cheers, ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/2/05, Steven Bethard <[EMAIL PROTECTED]> wrote: > Paul Moore wrote: > > Interestingly enough, the other languages I use most (C, Java, > > VB(Script) and Javascript (under Windows Scripting Host)) all use > > functions for output. Except for C, I uniformly dislike the resulting > > code - the output structure gets hopelessly lost under the weight of > > string concatenation and explicitly added spaces. > > Are your complaints about Guido's proposal or mine? The complaint > above doesn't quite seem relevant to my proposal, which retains the > space-insertion. Basically, my proposal suggests that files (and > other streams) gain a print method [...] Mainly Guido's, I guess. As you point out, your pint method is pretty close to the print statement. Some comments, though: 1. The print statement applies to *all* streams, where a print method won't. (You can't ensure that all 3rd-party file-like objects will be updated, unfortunately...) [A mildly obscure example - the Vim interface to Python binds sys.stdout to a pseudo stream which puts output in Vim's message area. Fail to update that code, and the print builtin won't work in Vim...] 2. There are still a confusing number of methods/builtins involved. Your print method isn't enough by itself, you still need write (and presumably a write builtin). Would you reject Guido's writeln? What about writef (again, as proposed by Guido)? I'm not at all clear precisely how many new methods and builtins you are proposing. 3. I am still hoping that someone will articulate a clear benefit for removing the print statement. Without that, I still see all cost and no benefit (even if I accept that your print function is an entirely adequate replacement for the print statement, that doesn't count as a benefit, just as the avoidance of yet another cost...) Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/2/05, Charles Cazabon <[EMAIL PROTECTED]> wrote: > Fredrik Lundh <[EMAIL PROTECTED]> wrote: > > > > > >print('foo:', foo, 'bar:', bar, 'baz:', baz, > > > 'frobble', frobble) > > > > > > To my (admittedly biased) eyes, the second version more obviously > > > prints to a single line. > > > > next use case: > > > > print 'foo:', foo, 'bar:', bar, 'baz:', baz, > > if frobble > 0: > > print 'frobble', frobble > > else: > > print 'no frobble today' > > The need to print /and/ not add a newline isn't nearly as common. print() > could take a keyword parameter to skip the newline, or ... > > print('foo:', foo, 'bar:', bar, 'baz:', baz, > frobble and 'frobble: ' + frobble or 'no frobble today') Ouf, I'm just feeling an evil idea creeping up just now: print('foo:', foo, 'bar:', bar, 'baz:', baz,) Just kidding, really... Funny enough, the syntax does not barf and goes undetected: >>> def foo( a, b, c ): ... print a, b, c ... >>> foo(1, 2, 3,) 1 2 3 >>> ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Steven> Obviously print is used by the rest of us too -- I count around Steven> 5000 instances in my installation. However, I only count around Steven> 400 instances where a "print" line ends with a comma. I took a quick look at my own code: 980 active print statements 110 active print statements with trailing commas 67 active print statements with output redirection 6 active print statements with trailing commas and output redirection 64 inactive print statements 4 inactive print statements with trailing commas 6 inactive print statements with output redirection 1 inactive print statement with trailing commas and output redirection so more than 10% of the print statements in my code use the trailing comma feature and more than 5% use output redirection. I suspect the discrepancy between use of the two features would be less if output redirection had been available from the start. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
I like the elegance of python, and read py-dev for my own edification. Since I believe I still have somewhat of a "beginner's mind" regarding python, I'll chime in with my opinions. First of all, I dislike 'writeln', for two reasons: 1) The name. I always want to mentally pronounce it 'ritt-linn'. If we *must* have this function, I'd prefer 'writeline'. 2) 'writeln' is a convenience function. A convenience function should be convenient! It seems to me that the most common (and convenient) use case is adding spaces between the arguments /and/ adding the newline. Since this is the same as the current default behavior of 'print', I suggest we use that name. So, after reading all the messages, it turns out my proposal is the same as STeVe's: all streams grow a 'print' method, and the builtin print function just be an alias to sys.stdout.print. Originally, I thought I preferred the statement version of print, but as long as the basic behavior of print is kept, I could get used to adding parens in my typing. The consistency calling the print builtin function with the stream.print method is nicer than the keystroke savings of no parens required by the statement. Having print as a function removes the need for ">>" too ('stream.print(foo)' instead of 'print >>stream foo'). I'm OK with losing the trailing-comma behavior, as I think 'write' should be used for anything beyond the basic default usecase. To summarize: +1 STeVe's proposal (stream.print for all streams, print builtin which maps to sys.stdout.print) +0 status quo -1 Guido's proposal (stream.write and stream.writeln for all streams, write and writeln builtins which map to sys.stdout) -John For reference: * Steven Bethard <[EMAIL PROTECTED]> [2005-09-02 13:06]: > > Basically, my proposal suggests that files (and > other streams) gain a print method like: > > class file(object): > ... > def print(self, *args): > self.write(' '.join(str(arg) for arg in args)) > self.write('\n') > > and the print statement becomes the builtin print() function, defined like: > > def print(*args): > sys.stdout.print(*args) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Paul Moore wrote: > Interestingly enough, the other languages I use most (C, Java, > VB(Script) and Javascript (under Windows Scripting Host)) all use > functions for output. Except for C, I uniformly dislike the resulting > code - the output structure gets hopelessly lost under the weight of > string concatenation and explicitly added spaces. Are your complaints about Guido's proposal or mine? The complaint above doesn't quite seem relevant to my proposal, which retains the space-insertion. Basically, my proposal suggests that files (and other streams) gain a print method like: class file(object): ... def print(self, *args): self.write(' '.join(str(arg) for arg in args)) self.write('\n') and the print statement becomes the builtin print() function, defined like: def print(*args): sys.stdout.print(*args) Looking at your use cases, this seems to cover them pretty well: > - Debugging, most definitely. Adding a quick print "a =", a is often > all that's needed. Use the builtin print(): print('a =', a) > - Logging, sometimes. When I just want some basic output, and don't > want to deal with the complexity of the logging package. Use the builtin print(): print('some logging message', foo) > - Unix-style command-line utilities, where textual output to stdout is the > norm. Use the builtin print(): print('line of output') > - Error and help messages, often with print >>sys.stderr Use the print() method of sys.stderr: sys.stderr.print('error or help message') STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/2/05, Steven Bethard <[EMAIL PROTECTED]> wrote: > Sorry for the confusion. I wasn't trying to imply anyone was a newbie > here, only that the earlier messages in this thread suggested that > these were the print statement's main audience. No problem - I was more joking than serious. But I don't see the same implication in earlier messages as you do - to me, the general impression is that people use the print statement in many different ways, and debugging and trivial scripts are far from the only use. > Obviously print is used by the rest of us too -- I count around > 5000 instances in my installation. I find it hard to reconcile that with your comment that newbies/debigging are the only real uses for the print statement... > However, I only count around 400 > instances where a "print" line ends with a comma. Yes, generally my uses of print are to produce complete lines of output. > I understand that. I'd just like to see the opinions backed up with > real code. ;-) Personally, I still use print a fair bit for debugging > purposes. But as I don't use it for much else, I can't judge too well > what other needs people have for it. Fair enough. I'll try to review where I use the print statement: - Debugging, most definitely. Adding a quick print "a =", a is often all that's needed. - Logging, sometimes. When I just want some basic output, and don't want to deal with the complexity of the logging package. - Unix-style command-line utilities, where textual output to stdout is the norm. - Error and help messages, often with print >>sys.stderr (The last two are obviously the ones I'd emphasize most when arguing that print should stay). Frankly, pretty much anything where the output is to go to stdout/stderr (console, redirected file or pipe) and it's line-oriented in nature. Yes, a stream.writeln() method could do what I want, but the print statement just *feels* more natural. Interestingly enough, the other languages I use most (C, Java, VB(Script) and Javascript (under Windows Scripting Host)) all use functions for output. Except for C, I uniformly dislike the resulting code - the output structure gets hopelessly lost under the weight of string concatenation and explicitly added spaces. With C, this is mitigated by printf, which implies to me that if Python goes this route, C-style string formatting will become far more prevalent in code. But I'm really still just speculating. No-one's really going to know if it's a bad idea until it happens. Personally, I'm just arguing against taking that risk in the absence of any clear benefits beyond "purity"... Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Tim Peters wrote: > [Paul F. Dubois] > >>Remove the print statementI laughed until my sides hurt. Hello? Try >>dating girls and talking to normal people, geek boys. [...] > > > Providing entertainment for retirees is one of the PSF's missions. I > wonder whether we could get AARP to kick back $10 to the PSF for each > of their members? For 350 million dollars a year, I'll be happy to > maintain a parallel P3K with a "print" statement until I die. No you wouldn't, that's a lie (whether you know it or not). With that kind of money at your disposal you would soon realise there's more to life than writing software and smoking by the office door. You might even start smoking things other than tobacco. Maintaining software would become a tedious drudge, you would be stultified by the obligation to do it, and be driven to suicide by the enforced interactions with the other developers who had nothing but scorn for the lowly print statement. On the other hand, with that kind of money you could probably hire enough geeks to do the maintenance for you. first-in-line-for-the-job-ly y'rs - steve PS: For what little it's worth I'd keep print too. -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setdefault's second argument
[Tim Peters] >> Dang! I may have just found a use, in Zope's >> lib/python/docutils/parsers/rst/directives/images.py (which is part >> of docutils, not really part of Zope): >> >> figwidth = options.setdefault('figwidth') >> figclass = options.setdefault('figclass') >> del options['figwidth'] >> del options['figclass'] [David Goodger] > If a feature is available, it *will* eventually be used! > Whose law is that? This is a different law, about design mistakes getting used by people who should know better ;-) > The code needs to store the values of certain dict entries, then > delete them. This is because the "options" dict is passed on to > another function, where those entries are not welcome. The code above > is simply shorter than this: > >if options.has_key('figwidth'): >figwidth = options['figwidth'] >del options['figwidth'] ># again for 'figclass' > > Alternatively, > >try: >figwidth = options['figwidth'] >del options['figwidth'] >except KeyError: >pass Those wouldn't work in context, because they leave figwidth unbound if it's not a key in options. Later code unconditionally references fidgwidth. > It saves between one line and three lines of code per entry. But > since those entries are probably not so common, it would actually be > faster to use one of the above patterns. Changing figwidth = options.setdefault('figwidth') figclass = options.setdefault('figclass') to figwidth = options.setdefault('figwidth', None) figclass = options.setdefault('figclass', None) is a minimal semantics-neutral edit to avoid the unloved 1-argument case. >> Assuming options is a dict-like thingie, it probably meant to do: >> >> figwidth = options.pop('figwidth', None) >> figclass = options.pop('figclass', None) > Yes, but the "pop" method was only added in Python 2.3. Docutils > currently maintains compatibility with Python 2.1, so that's RIGHT > OUT! Oh, stop torturing yourself. Nobody uses Python 2.1 anymore ;-) >> David, are you married to that bizarre use of setdefault ? > No, not at all. In fact, I will vehemently deny that I ever wrote > such code, and will continue to do so until someone looks up its > history and proves that I'm guilty, which I probably am. No, I checked, and this code was actually added by an Asian spammer, who polluted the docutils codebase with thousandsd of porn links hidden in triple-quoted strings. Google reveals that 1-argument setdefault() is a favorite of Asian porn spammers. So you should add a second argument just to avoid getting in trouble with Interpol ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Paul Moore wrote: > On 9/2/05, Steven Bethard <[EMAIL PROTECTED]> wrote: > [...] > > Since > > the print function seems to be intended mainly for newbies and simple > > debugging, > > I think there have been quite a few comments here from people who > *don't* see the print statement [1] as "mainly for newbies and simple > debugging". Sorry for the confusion. I wasn't trying to imply anyone was a newbie here, only that the earlier messages in this thread suggested that these were the print statement's main audience. (Hence "seems to be".) Obviously print is used by the rest of us too -- I count around 5000 instances in my installation. However, I only count around 400 instances where a "print" line ends with a comma. > [1] Sorry, you said "print function". But you seem to be aiming the > function as able to address everyone's concerns over features they > like in the print *statement* so I think my point stands. Yes, that was the intention. If the print function doesn't meet most of the same needs that the print statement needs, then it's not doing its job. > > I'm having trouble coming up with examples where this is > > really necessary. I'd like to see a few examples where it's crucial > > that the final newline is suppressed. > > No-one is saying "crucial". We're just expressing opinions. I understand that. I'd just like to see the opinions backed up with real code. ;-) Personally, I still use print a fair bit for debugging purposes. But as I don't use it for much else, I can't judge too well what other needs people have for it. Steve -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] itertools.chain should take an iterable ?
Christos Georgiou wrote: > "Paolino" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > >>What if I want to chain an infinite list of iterables? >>Shouldn't itertools.chain be built to handle that? > > > Raymond already suggested a four-line function that does exactly that. > > Create your own personal-library modules containing the functions you find > useful as building blocks, and when you have a large sw base using them, > present your building blocks along with their use cases as arguments for > inclusion in the standard library. > > >>I don't think it is a problem to accept only the second case you paste >>and produce TypeError on the others. > > > It would break compatibility with the current uses of itertools.chain . I > like it (and have used it) as it is. I see ,I just thought itertools was young and important enough to be investigated and eventually changed, but probably this is not the place to talk about that.I will submit the feature request to SF. I must add that the inverse story would have been def handy_chain(*args): return itertools.chain(iter(args)) a two-line function (ex lambda). Generally speaking, having a star-signature in a base library function is not a good choice. This is a proof of a case. Thanks all and have a nice summer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Paul Moore wrote: > On 9/2/05, Ron Adam <[EMAIL PROTECTED]> wrote: > >>Jim Jewett wrote: >> >>>Putting the spaces back in (without a format string) would >>>be even worse. Charles Cazabon's pointed out that it *could* >>>be as simple as >>> >>>writeln(' '.join( ... )) >> >>Why not just offer an addition method ? >> >>examine(x,y,z) # print with spaces > > > Because we're now up to *four* stream methods, plus the same number of > builtins, to do what one statement currently does? I'm not sure having one statement that can do several things with multiple syntax's is better than having multiple methods each with a single syntax. How is this different than having two methods in the case of partition() and rpartiion(). Ron ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Paul Moore wrote: > Sorry about that - I just get a bit tired of feeling like everyone's > characterising me as either a newbie, or as not writing "real" code... Hey, I'm a newbie, and I only write simple things, but Python is for people like me, too! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/2/05, Steven Bethard <[EMAIL PROTECTED]> wrote: [...] > Since > the print function seems to be intended mainly for newbies and simple > debugging, I think there have been quite a few comments here from people who *don't* see the print statement [1] as "mainly for newbies and simple debugging". But just to be absolutely clear, I find the print statement useful in general code - not just debugging code, not trivial scripts. I don't consider myself a "newbie". I hesitate to speak for others, but I believe that I'm not the only one in this situation. [1] Sorry, you said "print function". But you seem to be aiming the function as able to address everyone's concerns over features they like in the print *statement* so I think my point stands. Oh, yes - I also know about the "warts" in print (the >> syntax, and the trailing comma). They don't bother me - I use them on occasion and find them useful, rather than annoying. Yes, I know about stream.write and its variations. I know I can write a print function which adds spaces. Nevertheless, I still find the print statement more convenient, easier to understand and read, and frankly, not as ugly. *This is a personal opinion*. You aren't going to change my mind, and nor are you under any obligation to try. I won't discard Python if print is dropped, but I will be a little saddened. > I'm having trouble coming up with examples where this is > really necessary. I'd like to see a few examples where it's crucial > that the final newline is suppressed. No-one is saying "crucial". We're just expressing opinions. But so are those (even Guido!) who want to remove the print statement. No-one has come up with a genuine, objective benefit to removing it (that I can see). If there isn't one, then we're left with preferences, and Guido's trumps everyone else's. You (as someone who agrees with Guido) don't have anything to prove. Those of us who want to change Guido's mind need to impress him with the strength of our opinions :-). Sorry about that - I just get a bit tired of feeling like everyone's characterising me as either a newbie, or as not writing "real" code... Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
[Paul F. Dubois] > Remove the print statementI laughed until my sides hurt. Hello? Try > dating girls and talking to normal people, geek boys. I tried talking to both, and in this case all said "What's a 'print statement'? You mean like a bank statement -- or what?" ;-) > We scientists still use these for debugging. We never 'move on' very far > from the tutorial. The salient feature about print statements is that > they live to be put in and commented out 10 minutes later, without some > import being required or other enabling object being around. In fairness, Guido suggested adding builtin functions as replacements, so in his view you still wouldn't need to import anything. OTOH, I'd keep print, but (a) remove the inscrutable softspace gimmick, so that a comma always meant "one space"; and, (b) add even more special sytnax, so there was also an easy way to separate print items without forcing a space between them in the output. > Easy things should be easy. Hard things should be possible. I don't > believe the person who said the trailing comma case mixed up anybody, > not for more than 10 seconds anyway. Indeed, you can't even start to spell "practicality beats purity" without first duplicating the first two letters of "print" . > OK, now that I've offended everyone, I'll go back into retirement. But I > *am* laughing at you. Providing entertainment for retirees is one of the PSF's missions. I wonder whether we could get AARP to kick back $10 to the PSF for each of their members? For 350 million dollars a year, I'll be happy to maintain a parallel P3K with a "print" statement until I die. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
[EMAIL PROTECTED] wrote: > Perhaps if the last non-keyword argument was exactly one space, the > newline could be suppressed, e.g.: > > print("foo", "bar", "baz", " ", stream=sys.stderr) Sorry, I missed the newline-suppression idea in my first reply. I think the rule above is too confusing. I'm also still not convinced that the print function needs to support newline-suppression. Since the print function seems to be intended mainly for newbies and simple debugging, I'm having trouble coming up with examples where this is really necessary. I'd like to see a few examples where it's crucial that the final newline is suppressed. If it *has* to be supported, I'd add it as a keyword argument, so that your example above reads like: sys.stderr.print("foo", "bar", "baz", newline=False) I guess that's not too bad actually. Kinda nice that it has to be the last thing in the function... STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
[EMAIL PROTECTED] wrote: > the print statement is more convenient. Maybe a print builtin wouldn't kill > me. In that case I'd want both output redirection and newline suppression > though. I guess you'd have to use a keyword arg to specify an alternate > stream. Perhaps if the last non-keyword argument was exactly one space, the > newline could be suppressed, e.g.: > > print("foo", "bar", "baz", " ", stream=sys.stderr) I think, instead, the stream API should grow a "print" method (or whatever it ends up getting called). The example would then look like: sys.stderr.print("foo", "bar", "baz", " ") It would probably be nice to provide a FileMixin object too. (Actually, this would be nice now, so that if I implement read(), I don't have to implement readline(), readlines(), etc.) The FileMixin object would make it easy for user-defined file-like objects to also support the print() method: class FileMixin(object): """Adds the file methods. Requires: read() write() Adds: __iter__() next() readline() readlines() writelines() print() # or whatever it gets called """ ... STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
skip> print("foo", "bar", "baz", " ", stream=sys.stderr) skip> That seems a bit like magic, but probably no less magic than the skip> current trailing comma. Make that no *more* magic ... Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/2/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Steven> print 'foo:', foo, 'bar:', bar, 'baz:', baz, > Steven> print 'frobble', frobble > > Steven> In my proposed function: > > Steven> print('foo:', foo, 'bar:', bar, 'baz:', baz, > Steven> 'frobble', frobble) > > Steven> To my (admittedly biased) eyes, the second version more > Steven> obviously prints to a single line. > > Yes, you're right. My bad. > > So, is the proposal that you would need an explicit "\n" to terminate the > output or not? Well, my proposal (which differs from Guidos) is that the print function (or whatever it ends up getting called) would have the semantics: def print(*args): sys.stdout.write(' '.join(str(arg) for arg in args)) sys.stdout.write('\n') STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Charles> Or the user can just use stdout.write and have full control. Don't forget that those of us who are arguing in favor of keeping print are fully aware of stream.write's existence. It's just that in the common case the print statement is more convenient. Maybe a print builtin wouldn't kill me. In that case I'd want both output redirection and newline suppression though. I guess you'd have to use a keyword arg to specify an alternate stream. Perhaps if the last non-keyword argument was exactly one space, the newline could be suppressed, e.g.: print("foo", "bar", "baz", " ", stream=sys.stderr) That seems a bit like magic, but probably no less magic than the current trailing comma. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Steven> print 'foo:', foo, 'bar:', bar, 'baz:', baz, Steven> print 'frobble', frobble Steven> In my proposed function: Steven> print('foo:', foo, 'bar:', bar, 'baz:', baz, Steven> 'frobble', frobble) Steven> To my (admittedly biased) eyes, the second version more Steven> obviously prints to a single line. Yes, you're right. My bad. So, is the proposal that you would need an explicit "\n" to terminate the output or not? Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
> > 3. It's convenient for debugging, interactive use, simple scripts, > >and various other things. > >Interactive use is its own mode and works differently to the base > language. To print the value of something, just type an expression. Doesn't do the same thing. >The problem with print is it becomes a barrier to extending a > script into something more ambitious. This then leads to ugly > 'features' like '>>' and trailing commas. By all means provide a > simple syntax for i/o with the standard streams but ensure it is > something that is a firm basis for extension. Do you have any suggestion that's as practically usable as "print"? -- g ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Charles Cazabon wrote: > Fredrik Lundh <[EMAIL PROTECTED]> wrote: > > next use case: > > > > print 'foo:', foo, 'bar:', bar, 'baz:', baz, > > if frobble > 0: > > print 'frobble', frobble > > else: > > print 'no frobble today' > > The need to print /and/ not add a newline isn't nearly as common. print() > could take a keyword parameter to skip the newline, or ... > > print('foo:', foo, 'bar:', bar, 'baz:', baz, > frobble and 'frobble: ' + frobble or 'no frobble today') > > Or the user can just use stdout.write and have full control. Or you can easily refactor your code to do the print in one line: if frobble > 0: frobble_str = 'frobble: ' + frobble else: frobble_str = 'no frobble today' print('foo:', foo, 'bar:', bar, 'baz:', baz, frobble_str) or similarly: if frobble > 0: rest = ['frobble', frobble] else: rest = ['no frobble today'] print('foo:', foo, 'bar:', bar, 'baz:', baz, *rest) I don't know which refactoring you'd prefer, but there are at least a few options here. In the first one you have to be careful to add the extra space yourself. In the second one, you have to know how *args work. But I would claim that the extra mental burden of manually adding a space or understanding *args is about equivalent to the current mental burden of print's trailing-comma behavior. I also find it more obvious in both refactored examples that the print produces exactly one line. Of course, there are examples that don't refactor so easily. Here's one: for i, obj in enumerate(objs): # do stuff print i, obj, # do more stuff print If the "do stuff" and "do more stuff" sections are empty, you can write it as something like: print(*[item for tup in enumerate(objs) for item in tup]) But it's clearly not as beginner-friendly, requiring knowledge of *args and list comprehensions. OTOH, I'd claim that if you need such exacting format, you're not doing beginner stuff anyway. But YMMV. STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Fredrik Lundh <[EMAIL PROTECTED]> wrote: > > > >print('foo:', foo, 'bar:', bar, 'baz:', baz, > > 'frobble', frobble) > > > > To my (admittedly biased) eyes, the second version more obviously > > prints to a single line. > > next use case: > > print 'foo:', foo, 'bar:', bar, 'baz:', baz, > if frobble > 0: > print 'frobble', frobble > else: > print 'no frobble today' The need to print /and/ not add a newline isn't nearly as common. print() could take a keyword parameter to skip the newline, or ... print('foo:', foo, 'bar:', bar, 'baz:', baz, frobble and 'frobble: ' + frobble or 'no frobble today') Or the user can just use stdout.write and have full control. Charles -- --- Charles Cazabon <[EMAIL PROTECTED]> GPL'ed software available at: http://pyropus.ca/software/ --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Steven Bethard wrote: > But that would be just as easy with a print() function. In the current > syntax: > >print 'foo:', foo, 'bar:', bar, 'baz:', baz, >print 'frobble', frobble > > In my proposed function: > >print('foo:', foo, 'bar:', bar, 'baz:', baz, > 'frobble', frobble) > > To my (admittedly biased) eyes, the second version more obviously > prints to a single line. next use case: print 'foo:', foo, 'bar:', bar, 'baz:', baz, if frobble > 0: print 'frobble', frobble else: print 'no frobble today' ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
[EMAIL PROTECTED] wrote: > I don't find either the trailing comma or >> redirection ugly. If I have a > long print line that's hard to read because it extends past column 80 (the > print statement, not the output), it's easy to hit NL at an intermediate > comma, then just type "print ", perhaps followed by another output > redirector. The two print statements' output still falls on a single > line. The trailing comma on the previous line gives me a space between the > two output chunks. But that would be just as easy with a print() function. In the current syntax: print 'foo:', foo, 'bar:', bar, 'baz:', baz, print 'frobble', frobble In my proposed function: print('foo:', foo, 'bar:', bar, 'baz:', baz, 'frobble', frobble) To my (admittedly biased) eyes, the second version more obviously prints to a single line. STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Neil> The problem with print is it becomes a barrier to extending a Neil> script into something more ambitious. This then leads to ugly Neil> 'features' like '>>' and trailing commas. By all means provide a Neil> simple syntax for i/o with the standard streams but ensure it is Neil> something that is a firm basis for extension. I don't find either the trailing comma or >> redirection ugly. If I have a long print line that's hard to read because it extends past column 80 (the print statement, not the output), it's easy to hit NL at an intermediate comma, then just type "print ", perhaps followed by another output redirector. The two print statements' output still falls on a single line. The trailing comma on the previous line gives me a space between the two output chunks. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Neil Hodgson wrote: > Interactive use is its own mode and works differently to the base > language. To print the value of something, just type an expression. > Python will evaluate and print the value of the expression. Much > easier than adding 'print '. print and "echo" prints different things, for many values of "something". ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] itertools.chain should take an iterable ?
"Paolino" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > What if I want to chain an infinite list of iterables? > Shouldn't itertools.chain be built to handle that? Raymond already suggested a four-line function that does exactly that. Create your own personal-library modules containing the functions you find useful as building blocks, and when you have a large sw base using them, present your building blocks along with their use cases as arguments for inclusion in the standard library. > I don't think it is a problem to accept only the second case you paste > and produce TypeError on the others. It would break compatibility with the current uses of itertools.chain . I like it (and have used it) as it is. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
On Fri, Sep 02, 2005 at 10:07:29AM +0200, Fredrik Lundh wrote: > > OK, now that I've offended everyone, I'll go back into retirement. But I > > *am* laughing at you. > > Amen. Seconded. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] itertools.chain should take an iterable ?
[Paolino] > >>Well this happened after I tried instinctively > >>itertools.chain(child.method() for child in self). As Jack's note points out, your proposed signature is incompatible with the one we have now. I recommend creating your own version: def paolino_chain(iterables): for it in iterables: for element in it: yield element >>> list(chain(c+c for c in string.ascii_uppercase)) ['A', 'A', 'B', 'B', 'C', 'C', 'D', 'D', 'E', 'E', 'F', 'F', 'G', 'G', 'H', 'H', 'I', 'I', 'J', 'J', 'K', 'K', 'L', 'L', 'M', 'M', 'N', 'N', 'O', 'O', 'P', 'P', 'Q', 'Q', 'R', 'R', 'S', 'S', 'T', 'T', 'U', 'U', 'V', 'V', 'W', 'W', 'X', 'X', 'Y', 'Y', 'Z', 'Z'] > >>Is there a reason for this signature ? It was handy for the use cases I had in mind when creating the function. Also it was styled after a version in another language where it had proven successful. > > This is more suited to comp.lang.python > > > Why ? I'm not asking for help ,I'm asking why itertools library is > implemented like that and if it is possible to clean it. The newsgroup would have guided you to the solution listed above. If you want to request a new feature, please use SourceForge. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
On Fri, 2005-09-02 at 03:18, Paul F. Dubois wrote: > Remove the print statementI laughed until my sides hurt. Hello? Try > dating girls and talking to normal people, geek boys. > > We scientists still use these for debugging. We never 'move on' very far > from the tutorial. The salient feature about print statements is that > they live to be put in and commented out 10 minutes later, without some > import being required or other enabling object being around. > > Easy things should be easy. Hard things should be possible. I don't > believe the person who said the trailing comma case mixed up anybody, > not for more than 10 seconds anyway. > > OK, now that I've offended everyone, I'll go back into retirement. But I > *am* laughing at you. Thank you Paul! Don't stay retired for long. :) -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Gareth McCaughan: > 3. It's convenient for debugging, interactive use, simple scripts, >and various other things. Interactive use is its own mode and works differently to the base language. To print the value of something, just type an expression. Python will evaluate and print the value of the expression. Much easier than adding 'print '. Extended interactive modes like ipython include other conveniences that don't belong in the python language. The problem with print is it becomes a barrier to extending a script into something more ambitious. This then leads to ugly 'features' like '>>' and trailing commas. By all means provide a simple syntax for i/o with the standard streams but ensure it is something that is a firm basis for extension. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
On Fri, 2005-09-02 at 00:40, Martin Blais wrote: > Talking about cleanliness, I'm not sure which is cleaner:: > > print >> sys.stderr, "This is a long sentence that I " \ > "had to cut in two." > > print("This is a long sentence that I " > "had to cut in two.", stream=sys.stderr) > > Sometimes I'll do this because I don't like the backslashes:: > > print >> sys.stderr, ("This is a long sentence that " > "Had to cut in two.") Or maybe print >> sys.stderr, "\ This is a long sentence that I didn't have to cut in two." A bit yucky, but easily extended to TQS when your message gets longer and longer. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
On Thu, 2005-09-01 at 16:07, Guido van Rossum wrote: > Another real problem with print is that, while the automatic insertion > of spaces is nice for beginners, it often gets in the way, OTOH, print's automatic space insertion is often the reason why I'll reach for it instead of stream.write(). Maybe we should be thinking of this differently. What on the surface appears to be many varieties of one use case, screaming out for TOOWTDI+options is really (at least) two use cases urging us to different solutions appropriate for the problem. I have no qualms with adding writeln() or writefmt() or whatever -- those seem like useful additions I'm sure I'd use. But I don't think that therefore (or under the principles of TOOWTDI or cleanliness) demands the removal of print. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
On Thu, 2005-09-01 at 17:49, Bob Ippolito wrote: > That is absolutely true, print is becoming less and less useful in > the context of GUI or web applications. I know we're dinosaurs, but some of us still write console apps in Python! > Even in Just Debugging > scenarios, you're probably better off using something with more > flexibility, such as the logging module. The logging module is great, but logging and debugging are two different things (although that fact is obscured when you don't have a console). print is useful in scenarios other than debugging. And while I do occasionally use it, I wouldn't be too heartbroken if the trailing comma form were lost. I /would/ mourn the loss of print>> though -- not necessarily the syntax, which was clearly a compromise, but the functionality. If we could have spelled it "print to sys.stderr" we would have. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] itertools.chain should take an iterable ?
Jack Diederich wrote: > On Thu, Sep 01, 2005 at 07:58:40PM +0200, Paolino wrote: > >>Working on a tree library I've found myself writing >>itertools.chain(*[child.method() for child in self]). >>Well this happened after I tried instinctively >>itertools.chain(child.method() for child in self). >> >>Is there a reason for this signature ? > > > This is more suited to comp.lang.python > Why ? I'm not asking for help ,I'm asking why itertools library is implemented like that and if it is possible to clean it. > Consider the below examples (and remember that strings are iterable) > > import itertools as it list(it.chain('ABC', 'XYZ')) > > ['A', 'B', 'C', 'X', 'Y', 'Z'] > list(it.chain(['ABC', 'XYZ'])) > > ['ABC', 'XYZ'] > list(it.chain(['ABC'], ['XYZ'])) > > ['ABC', 'XYZ'] > What if I want to chain an infinite list of iterables? Shouldn't itertools.chain be built to handle that? I don't think it is a problem to accept only the second case you paste and produce TypeError on the others. Hope this explains and to get other reasons. Regards Paolino > > Hope that helps, > > -jackdied > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/paolo_veronelli%40libero.it > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
> We scientists still use these for debugging. We never 'move on' very far > from the tutorial. The salient feature about print statements is that > they live to be put in and commented out 10 minutes later, without some > import being required or other enabling object being around. > > Easy things should be easy. Hard things should be possible. I don't > believe the person who said the trailing comma case mixed up anybody, > not for more than 10 seconds anyway. Damn right. No, I mean: damn "write" :-). I've used Python for teaching beginner programmers, for quick-hack scripts, for interactive diddling about, for scientific computation, for algorithmic experimentation, for GUI applications. I'd appreciably miss "print" for *all* of these, even the last. (My GUI applications sometimes have bugs. How about yours?) So far as I can see, two arguments against "print" have been proposed. 1. It has some ugly features, like the trailing-comma hack. 2. It's a statement that does something "ordinary" and could be replaced by a function. Against which, we have 3. It's convenient for debugging, interactive use, simple scripts, and various other things. 4. It's beginner-friendly. Now, I'm sure I remember hearing something that was relevant to this. "Pragmatism beats purification"? No, that's not quite it. "Practice beats perfection?" No. Ah yes, I remember: "Practicality beats purity". But, of course, that wasn't talking about Python 3000. :-) -- g ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revising RE docs
On Thursday 2005-09-01 18:09, Guido van Rossum wrote: > They *are* cached and there is no cost to using the functions instead > of the methods unless you have so many regexps in your program that > the cache is cleared (the limit is 100). Sure there is; the cost of looking them up in the cache. >>> import re,timeit >>> timeit.re=re >>> timeit.Timer("""re.search(r"(\d*).*(\d*)", "abc123def456")""").timeit(100) 7.6042091846466064 >>> timeit.r = re.compile(r"(\d*).*(\d*)") >>> timeit.Timer("""r.search("abc123def456")""").timeit(100) 2.6358869075775146 >>> timeit.Timer().timeit(100) 0.091850996017456055 So in this (highly artificial toy) application it's about 7.5/2.5 = 3 times faster to use the methods instead of the functions. -- g ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
On Thu, 1 Sep 2005, Jack Diederich wrote: > On Thu, Sep 01, 2005 at 11:12:57PM +0200, Fredrik Lundh wrote: >> yeah, real programmers don't generate output. >> > I'd say: > yeah, real programmers don't generate output _to stdout_ > > sockets, GUI widgets, buffers? sure. stdout? Almost never. Almost every program I write produces its output mainly to stdout. And I probably use print half the time to produce this output (the rest is done mostly with csv). GUI widgets? Who needs 'em? -- Michael Hoffman <[EMAIL PROTECTED]> European Bioinformatics Institute ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
[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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 design principles
On 2005-09-01, Ron Adam <[EMAIL PROTECTED]> wrote: > As for functions without '()'s. (Just a thought) You could use '<<' or > '<<<' (or other symbol) as a way to move data between objects. > > ui.write <<< 'Hello World/n' # ui.write('Hello World/n') > > ui.writeln <<< counter# ui.writeln(counter.next()) > > ok = ui.input <<< 'press a key:' # ok = ui.input('press a key:') > > The requirement could be that the item on the left is a callable, and > the item on the right is a sequence or generator. > Please don't abuse symbols. Perl's ways of symbols all the way without intuitive meaning is bad. Use descriptive methods and functions please. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
On 01/09/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > And good riddance! The print statement harks back to ABC and even > (unvisual) Basic. Out with it! I disagree strongly. I can't count the number of times I've been p*ssed having to write something like System.out.println("point(" + this.x + "," + this.y +")") in Java. (Strangely though, I don't object to having printf() in C, but I know it doesn't work any other way). This is what I liked about Python, it offered a no-frills way to get the job done (TSOOWTDI and the like). I agree it's mostly used for debugging purposes, to do quick-and dirty calculations, etc. Nothing can beat it. We don't want the language to be pure, we want it to be useful. Isn't "Practicality beats purity" in the Zen of Python? Last time I checked (2.4.1) it was there, and updating Zen isn't in PEP 3000 ;) -1 on removal of print. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Hallöchen! "Paul F. Dubois" <[EMAIL PROTECTED]> writes: > [...] > > We scientists still use these for debugging. We never 'move on' > very far from the tutorial. The salient feature about print > statements is that they live to be put in and commented out 10 > minutes later, without some import being required or other > enabling object being around. Being a natural scientist myself, I plan to use Python for such purposes, too, and surely print will be part of it. I also agree that at least for the not professionally trained programmer, print is a very handy debugging helper. However, an even more important kind of Python programs are the utilities one creates for making life easier. They are usually short and simple with respect to their I/O. I really love the print statement with its comma notation here. Typically it's used frequently in my programs and produces lucid lines of code. Additionally, print is positive for Python advocacy in my opinion. It strengthens the beginner's impression that Python has a gentle syntax. (Again, I may speak for the non-CS folks.) I think that print's purpose is important enough for Python's target group that it deserves to remain as it is. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/2/05, Ron Adam <[EMAIL PROTECTED]> wrote: > Jim Jewett wrote: > > Putting the spaces back in (without a format string) would > > be even worse. Charles Cazabon's pointed out that it *could* > > be as simple as > > > > writeln(' '.join( ... )) > > Why not just offer an addition method ? > > examine(x,y,z) # print with spaces Because we're now up to *four* stream methods, plus the same number of builtins, to do what one statement currently does? (BTW, the ' '.join() idiom has a minor disadvantage in that it *builds* the output string, whereas print doesn't. Not a major issue, given the typical sizes of strings to be output, but it's another cost nevertheless...) Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Paul F. Dubois wrote: > Remove the print statementI laughed until my sides hurt. Hello? Try > dating girls and talking to normal people, geek boys. > > We scientists still use these for debugging. We never 'move on' very far > from the tutorial. The salient feature about print statements is that > they live to be put in and commented out 10 minutes later, without some > import being required or other enabling object being around. > > Easy things should be easy. Hard things should be possible. I don't > believe the person who said the trailing comma case mixed up anybody, > not for more than 10 seconds anyway. > > OK, now that I've offended everyone, I'll go back into retirement. But I > *am* laughing at you. Amen. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Remove the print statementI laughed until my sides hurt. Hello? Try dating girls and talking to normal people, geek boys. We scientists still use these for debugging. We never 'move on' very far from the tutorial. The salient feature about print statements is that they live to be put in and commented out 10 minutes later, without some import being required or other enabling object being around. Easy things should be easy. Hard things should be possible. I don't believe the person who said the trailing comma case mixed up anybody, not for more than 10 seconds anyway. OK, now that I've offended everyone, I'll go back into retirement. But I *am* laughing at you. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com