Steven Bethard wrote:
- Error and help messages, often with print sys.stderr
Use the print() method of sys.stderr:
sys.stderr.print('error or help message')
so who's going to add print methods to all file-like objects?
/F
___
Python-Dev
With the implementation and soon release of PEP 342, I've been
thinking more about traceback objects lately. First I'll give you some
background information for my problem.
I've implemented a module for integrating Twisted's Deferreds with the
new yield expression, that allows you to do stuff
Nick Coghlan wrote:
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.
Looks like a good start, much better than just expressing opinions. :-)
How about making it a class?
Martin Blais wrote:
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,
Ron Adam wrote:
Nick Coghlan wrote:
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.
Looks like a good start, much better than just expressing opinions. :-)
How about
Ron Adam [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
# standard printing
write.ln(1, 2, 3)
# print without trailing newline
write(1, 2, 3)
This violates this design principle:
When there are two options and one is overwhelmingly more common in use (in
this case, with newline
Terry Reedy wrote:
Ron Adam [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
# standard printing
write.ln(1, 2, 3)
# print without trailing newline
write(1, 2, 3)
This violates this design principle:
When there are two options and one is overwhelmingly more common in use
On 9/3/05, Guido van Rossum [EMAIL PROTECTED] wrote:
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.
Fair point.
Is it...
- Going from statement to function?
I thought this was a major issue,
On 9/3/05, Nick Coghlan [EMAIL PROTECTED] wrote:
[...]
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)))
Hmm... This prompts a coding question - is it possible to recognise
which arguments to a
On 9/3/05, Paolino [EMAIL PROTECTED] wrote:
Martin Blais wrote:
Then how about::
output(*(x*x for x in range(10)), iter=1)
Illegal in python2.4.(Wrongly ?) And makes the star solution half unuseful.
def f(*args,**kwargs):
... pass
...
f(*(1,2,3),iter=True)
File stdin,
Paul Moore wrote:
Hmm... This prompts a coding question - is it possible to recognise
which arguments to a function are generators, so that you could write
output(1, 2, [3,4], (c for c in 'abc'), 'def', (5, 6))
and get
1 2 [3, 4] a b c def (5, 6)
?
At the simplest level,
Nick Coghlan wrote:
If an iterator wants to behave like that, the iterator should define the
appropriate __str__ method. Otherwise, just break it up into multiple lines:
write(1, 2, [3,4])
write(*(c for c in 'abc'))
This cannot accept keyword args(I wonder if this is a bug), which
Paolino wrote:
Nick Coghlan wrote:
If an iterator wants to behave like that, the iterator should define
the appropriate __str__ method. Otherwise, just break it up into
multiple lines:
write(1, 2, [3,4])
write(*(c for c in 'abc'))
This cannot accept keyword args(I wonder if
On Fri, 2005-09-02 at 21:42, Guido van Rossum wrote:
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?
So I ignored my visceral reaction against the proposal and
So, another round.
* Gratuitous breakage: IMO it's not gratuitous. The *extensions* to
the print statement (trailing comma, stream) are ugly, and because
it's all syntax, other extensions are hard to make. Had it been a
function from the start it would have been much easier to add keyword
args,
[Barry Warsaw]
I think it's best to have two builtins:
print(*args, **kws)
printf(fmt, *args, **kws)
I would also /require/ that any behavior changing keyword arguments
/not/ be magically inferred from the positional arguments. So you'd
have to explicitly spell 'nl=False' or stream=fp
On Sat, 2005-09-03 at 11:17, Guido van Rossum wrote:
I see two different ways to support the two most-called-for additional
requirements: (a) an option to avoid the trailing newline, (b) an
option to avoid the space between items.
See a (very quick and very dirty ;) strawman that I just
On Sep 3, 2005, at 11:32 AM, Barry Warsaw wrote:
So I think it's best to have two builtins:
print(*args, **kws)
printf(fmt, *args, **kws)
It seems pretty bogus to me to add a second builtin just to apply the
% operator for you. I've always really liked that Python doesn't have
separate
Nick Coghlan wrote:
I actually hope that extended function call syntax in Py3k will
use iterators rather than tuples so that this problem goes away.
I suggested this a while back on the Python list:
http://mail.python.org/pipermail/python-list/2004-December/257282.html
Raymond Hettinger
On 9/3/05, Barry Warsaw [EMAIL PROTECTED] wrote:
On Fri, 2005-09-02 at 21:42, Guido van Rossum wrote:
I do hate having to write two parentheses -- it's more than the extra
keystrokes. It's that I have to use two shifted characters and I have
to be sure to close the construct, which can be a
Fredrik Lundh wrote:
Steven Bethard wrote:
- Error and help messages, often with print sys.stderr
Use the print() method of sys.stderr:
sys.stderr.print('error or help message')
so who's going to add print methods to all file-like objects?
The same people that added __iter__(),
Guido van Rossum wrote:
If there's demand, we could also introduce printf(), which would work
just like C's printf() except it takes a keyword argument to redirect
the output.
I think this is probably unnecessary if string formatting becomes a
function instead of the % operator (as has been
On 9/3/05, Steven Bethard [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
I actually hope that extended function call syntax in Py3k will
use iterators rather than tuples so that this problem goes away.
I suggested this a while back on the Python list:
On 9/3/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Actually, it's an ordering quirk in the parser - the extended call syntax
stuff has to come last in the function call, which means we need to put the
keyword arguments at the front:
Py writeln(sep=', ', *(x*x for x in range(10)))
0, 1, 4, 9,
OK. Now that we've got the emotions under control somewhat, maybe a
few folks can go off and write up a PEP for a print-replacement. I
nominate Barry and Nick since they seem to be motivated; anyone who
thinks their view is important and won't be taken into account enough
by those two ought to
At 06:24 PM 9/3/2005 +1000, Christopher Armstrong wrote:
For example, perhaps a better idea would be to
change the traceback-printing functions to use Python attribute lookup
instead of internal structure lookup, and then change raise to accept
arbitrary Python objects as its third argument, as
On 9/3/05, James Y Knight [EMAIL PROTECTED] wrote:
On Sep 3, 2005, at 11:32 AM, Barry Warsaw wrote:
So I think it's best to have two builtins:
print(*args, **kws)
printf(fmt, *args, **kws)
It seems pretty bogus to me to add a second builtin just to apply the
% operator for you.
On Sat, 2005-09-03 at 19:42 +0100, Paul Moore wrote:
On 9/3/05, James Y Knight [EMAIL PROTECTED] wrote:
On Sep 3, 2005, at 11:32 AM, Barry Warsaw wrote:
So I think it's best to have two builtins:
print(*args, **kws)
printf(fmt, *args, **kws)
It seems pretty bogus to me to
Hi,
I would like to suggest a small enhancement to str.strip().
By expanding its current form, where it only takes a char list, to
taking any list containing either char lists or string lists, it is
possible to remove entire words from the stripped string.
To clarify what I mean, here are
Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I take this chance to state my humble opinion. Please keep the print
function print(), not writeln()! printing stuff is everyone's
favorite anachronistic expression, even though the output doesn't go to
a
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.
Neal Ideally I very much prefer that print become a function. However,
[Jonny Reichwald]
I would like to suggest a small enhancement to str.strip().
By expanding its current form, where it only takes a char list, to
taking any list containing either char lists or string lists, it is
possible to remove entire words from the stripped string.
. . .
Would this be
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.
Nick,
You seem to be dreaming. People like the print statement for many
and varied reasons, it seems. Skip's point about
Raymond Hettinger [EMAIL PROTECTED] wrote:
[Jonny Reichwald]
I would like to suggest a small enhancement to str.strip().
By expanding its current form, where it only takes a char list, to
taking any list containing either char lists or string lists, it is
possible to remove entire
Just to add a bit more perspective (though I continue to believe that
print should be retained as-is):
In my UpLib code, I no longer use print. Instead, I typically use a
variant of logging called note instead of print:
note ([LEVEL, ] FORMAT-STRING [, *ARGS])
It works just like C printf,
I do hate having to write two parentheses -- it's more than the extra
keystrokes. It's that I have to use two shifted characters and I have
to be sure to close the construct, which can be a PITA when the start of
the function call is separated from the end by many lines.
What I found is
Guido writes:
* Gratuitous breakage: IMO it's not gratuitous. The *extensions* to
the print statement (trailing comma, stream) are ugly, and because
it's all syntax, other extensions are hard to make. Had it been a
function from the start it would have been much easier to add keyword
args,
Or perhaps:
print [with FORMAT-STRING] [ STREAM] *ARGS
as an alternative to
printf [@ STREAM] FORMAT-STRING *ARGS
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Bill Janssen wrote:
So here's the summary of the arguments against: two style points
(trailing comma and stream) (from the man who approved the current
decorator syntax!), and it's hard to extend. (By the way, I agree that
the syntax is ugly, and IMO a bad idea in general. Shame the @
Raymond Hettinger wrote:
[Jonny Reichwald]
Would this be useful for anyone else besides me?
Probably not.
ok
Even if an example or two is found, it is worth complicating the API.
Keep in mind the difficulties that plague str.split() -- that is what
happens when a function grows beyond a
Even if an example or two is found, it is worth complicating the
API.
Keep in mind the difficulties that plague str.split() -- that is
what
happens when a function grows beyond a single, clear, unified,
cohesive
concept.
I am not aware of these difficulties, any pointers?
Yes. From
Guido van Rossum wrote:
On 9/3/05, Steven Bethard [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
I actually hope that extended function call syntax in Py3k will
use iterators rather than tuples so that this problem goes away.
I suggested this a while back on the Python list:
On 9/4/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 06:24 PM 9/3/2005 +1000, Christopher Armstrong wrote:
For example, perhaps a better idea would be to
change the traceback-printing functions to use Python attribute lookup
instead of internal structure lookup, and then change raise to
Barry Warsaw wrote:
On Sat, 2005-09-03 at 11:17, Guido van Rossum wrote:
I see two different ways to support the two most-called-for additional
requirements: (a) an option to avoid the trailing newline, (b) an
option to avoid the space between items.
See a (very quick and very dirty ;)
Steven Bethard wrote:
The same people that added __iter__(), next(), readline(), readlines()
and writelines() to their file-like objects when technically these are
all derivable from read() and write(). This is why I suggested
providing a FileMixin class. In retrospect, I'm surprised we
Bill Janssen wrote:
Steven,
Did you see Nick Coghlan's post?
http://mail.python.org/pipermail/python-dev/2005-September/056076.html
I found his arguments to be reasonably compelling.
You were already convinced on Friday, so with you, he was preaching to
the choir. I'm not surprised
On 9/2/05, Gareth McCaughan [EMAIL PROTECTED] wrote:
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).
Nick Coghlan wrote:
I agree with this point actually. There should be an iterable formatting
code that looks something like %[sep]i
Then %i % (my_seq,) would be the equivalent of .join(my_seq), only
allowing it to be easily embedded inside a larger format string.
Some other examples:
Nick Coghlan wrote:
Nick Coghlan wrote:
I agree with this point actually. There should be an iterable formatting
code that looks something like %[sep]i
Then %i % (my_seq,) would be the equivalent of .join(my_seq), only
allowing it to be easily embedded inside a larger format string.
Some
Bill Janssen wrote:
I think what Nick really is asking for is a better print statement --
and there's no particularly good reason to move to a function to
attain that end.
Well one reason (you can judge for yourself whether it's good or
not) is that adding more syntax to the print statement
50 matches
Mail list logo
