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
"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
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 stead
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 th
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,
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*
"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 tu
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
---
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, to
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 '
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))
> => outpu
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 s
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, an
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 rath
[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 n
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
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
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
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 a
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'
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
> str
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 do
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 ba
[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['fig
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
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.
>
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
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!
___
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"
[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
[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.
[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
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@pyt
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> 'f
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
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 secon
> > 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
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 newlin
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:
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', frobbl
[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 fo
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 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 thing
"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 co
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://mai
[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
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 featu
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 o
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.std
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().
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 b
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).
>
> 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 th
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.
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.
Al
[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?)
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
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
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 b
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 ?
>
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 th
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
62 matches
Mail list logo
