Re: [Python-Dev] String views (was: Re: Proof of the pudding:str.partition())
[EMAIL PROTECTED] wrote: Fredrik Python strings are character buffers with a known length, not Fredrik null-terminated C strings. the CPython implementation Fredrik guarantees that the character buffer has a trailing NULL Fredrik character, but that's mostly to make it easy to pass Python Fredrik strings directly to traditional C API:s. I'm obviously missing something that's been there all along. Since Python strings can contain NULs, why do we bother to NUL-terminate them? Clearly, any tradition C API that expects to operate on NUL-terminated strings would break with a string containing an embedded NUL. sure, but that doesn't mean that such an API would break on a string that *doesn't* contain an embedded NUL. in practice, this is the difference between the s and s# argument specifiers; the former requires a NUL-free string, the latter can handle any byte string: f = open(myfile\0) Traceback (most recent call last): File stdin, line 1, in ? TypeError: file() argument 1 must be (encoded string without NULL bytes), not str f = open(myfile) f open file 'myfile', mode 'r' at 0x0091E9A0 /F ___ 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
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. /F ___ 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
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 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] 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
[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] 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] 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
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] 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
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] 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 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
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 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] 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, 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] 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'
/F
___
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
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
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
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
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
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
[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
[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 wink. 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
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 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! /F ___ 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] 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] 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 wink?
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
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] 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
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
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
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
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
[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
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
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
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
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
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
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
[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
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
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
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
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
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
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
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
