On 9/6/05, Guido van Rossum [EMAIL PROTECTED] wrote:
My hypothesis is that there are actually only two use cases that
matter enough to be supported directly:
(a) quickly print a bunch of items with spaces in between them and a
trailing newline
(b) print one or more items with precise
On 9/9/05, Guido van Rossum [EMAIL PROTECTED] wrote:
While I laugh at the naive view of people who write things like
Interface equality and neutrality would be a good thing in the
language and seriously (? I didn't see a smiley) use this argument to
plead for not making print() a built-in, I
(Maybe someone else has already raised this point. I'm a bit behind.)
Martin Here goes something: for applications targeted to the web, where
Martin newlines don't matter, the line breaks in _()'ed strings are
Martin superfluous.
How will you know you're generating output that
Nick Coghlan wrote:
Not to mention the annoyingly large number of fonts that make '`' and '''
look
virtually identical :(
Well, you need to be careful about choice of font for
programming anyway, for 0/O, 1/l, etc.
--
Greg Ewing, Computer Science Dept,
Greg == Greg Ewing [EMAIL PROTECTED] writes:
Greg Stephen J. Turnbull wrote:
IMO strings that are being printf'd can probably be assumed to
be human readable, and therefore candidates for translation.
This
Greg That's a dangerous assumption to make, I think.
Could be.
Greg Ewing wrote:
Maybe backquotes could be repurposed in Py3k for interpolated
string literals?
backquotes are a PITA to type on many non-US keyboards.
/F
___
Python-Dev mailing list
Python-Dev@python.org
Fredrik Lundh [EMAIL PROTECTED] writes:
Greg Ewing wrote:
Maybe backquotes could be repurposed in Py3k for interpolated
string literals?
backquotes are a PITA to type on many non-US keyboards.
Even more since they are especially broken in Windows XEmacs.
Thomas
On 9/8/05, Stephen J. Turnbull [EMAIL PROTECTED] wrote:
Could be. For me, the name print is associated with a long history
of magical behavior that only a human could possibly feel comfortable
with. One of the great sins of Pascal was tarring the name write
with the same brush!
Well, apart
Fredrik backquotes are a PITA to type on many non-US keyboards.
Interesting. On US keyboards they are often easier to type than parens...
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On 9/8/05, Antoine Pitrou [EMAIL PROTECTED] wrote:
Hi,
Le jeudi 08 septembre 2005 à 19:12 +0900, Stephen J. Turnbull a écrit :
It would be
nice to be able to lose the _() calls to gettext(). The function
would look to see if a message catalog was available for the current
output
Guido == Guido van Rossum [EMAIL PROTECTED] writes:
Guido I certainly didn't mean to rule that out.
Speaking for myself, that's all I really wanted to hear at this time.
As Bob Ippolito said, currently it's straightforward to
internationalize an application, and well worth the minimal
Hi,
Le jeudi 08 septembre 2005 à 19:12 +0900, Stephen J. Turnbull a écrit :
It would be
nice to be able to lose the _() calls to gettext(). The function
would look to see if a message catalog was available for the current
output stream, and if not, do no translation.
That doesn't sound
Guido writes:
Is it worth doing this and completely dropping the %-based formats in
Py3k? (Just asking -- it might be if we can get people to get over the
shock of $ becoming first class ;-).
In my opinion, YES -- it's worth seriously considering it. A single,
well-designed solution for string
On Wed, 2005-09-07 at 08:55, Nick Coghlan wrote:
The leading 'p' (for 'positional') is necessary to get around the fact that
$1
is currently an illegal identifier in a Template
That should be fixable. Ideally, $1 is better than $p1.
-Barry
signature.asc
Description: This is a digitally
On Wed, 2005-09-07 at 15:07, Bob Ippolito wrote:
I was also able to easily automate the process of extracting strings
to create that spreadsheet. I wrote a simple script that parsed the
Python modules and looked for function calls of _ whose only
argument was a constant string. Worked
On Thu, 2005-09-08 at 07:48, Antoine Pitrou wrote:
As I said Python needs an operator or function that does string
formatting using a simple template, *without* doing output at the same
time. The current syntax is the '%' operator, it could change, but it
shouldn't be removed in favor of an
Barry Warsaw wrote:
On Wed, 2005-09-07 at 08:55, Nick Coghlan wrote:
The leading 'p' (for 'positional') is necessary to get around the fact that
$1
is currently an illegal identifier in a Template
That should be fixable. Ideally, $1 is better than $p1.
I also looked into the idea of
On 9/6/05, Guido van Rossum [EMAIL PROTECTED] wrote:
On 9/5/05, Calvin Spealman [EMAIL PROTECTED] wrote:
There is a lot of debate over this issue, obviously. Now, I think
getting rid of the print statement can lead to ugly code, because a
write function would be called as an expression, so
Michael Chermside writes:
| Guido writes:
| Is it worth doing this and completely dropping the %-based formats in
| Py3k? (Just asking -- it might be if we can get people to get over the
| shock of $ becoming first class ;-).
|
| In my opinion, YES -- it's worth seriously considering it. A
On Sep 8, 2005, at 5:42 AM, Barry Warsaw wrote:
On Wed, 2005-09-07 at 15:07, Bob Ippolito wrote:
I was also able to easily automate the process of extracting strings
to create that spreadsheet. I wrote a simple script that parsed the
Python modules and looked for function calls of _ whose
Stephen J. Turnbull wrote:
IMO strings that are being printf'd can probably be assumed to be
human readable, and therefore candidates for translation. This
That's a dangerous assumption to make, I think.
I'd be uncomfortable with having some strings in
my program translated automatically
Guido == Guido van Rossum [EMAIL PROTECTED] writes:
Guido Sure, we must provide good i18n support. But the burden on
Guido users who don't need i18n should be negligeable; they
Guido shouldn't have to type or know extra stuff that only exists
Guido for the needs of i18n.
Agreed.
On Wed, 2005-09-07 at 05:23, Stephen J. Turnbull wrote:
But print-ng looks
like becoming the OOWTDI for a lot of applications. IMO it's just too
early to give up on print-ng becoming the one obvious way to do it for
a lot of i18n apps, too.
+1. I have a gut feeling that we can make it easy
Barry Warsaw wrote:
On Wed, 2005-09-07 at 05:23, Stephen J. Turnbull wrote:
But print-ng looks
like becoming the OOWTDI for a lot of applications. IMO it's just too
early to give up on print-ng becoming the one obvious way to do it for
a lot of i18n apps, too.
+1. I have a gut feeling
Nick Coghlan wrote:
I found the following to be an interesting experiment:
-
from string import Template
def format(*args, **kwds):
fmt = args[0]
kwds.update((p%s % idx, arg) for idx, arg in enumerate(args))
return Template(fmt).substitute(**kwds)
I
On 9/7/05, Barry Warsaw [EMAIL PROTECTED] wrote:
On Wed, 2005-09-07 at 05:23, Stephen J. Turnbull wrote:
But print-ng looks
like becoming the OOWTDI for a lot of applications. IMO it's just too
early to give up on print-ng becoming the one obvious way to do it for
a lot of i18n apps,
On Sep 7, 2005, at 7:11 AM, Guido van Rossum wrote:
On 9/7/05, Barry Warsaw [EMAIL PROTECTED] wrote:
On Wed, 2005-09-07 at 05:23, Stephen J. Turnbull wrote:
But print-ng looks
like becoming the OOWTDI for a lot of applications. IMO it's
just too
early to give up on print-ng becoming
Guido == Guido van Rossum [EMAIL PROTECTED] writes:
Guido intermezzo
Guido In a different thread I mentioned a design principle for
Guido which I have no catchy name, but which has often helped me
Guido design better APIs. One way to state it is to say that
Guido instead of
Guido van Rossum [EMAIL PROTECTED] wrote:
What do you think of the trick (that I wasn't aware of before)
used in Java and .net of putting an optional position specifier
in the format, and using positional arguments? It would be a
little less verbose and with sensible defaults wouldn't quite
Guido van Rossum wrote:
If there are other use cases they can obviously be coded by using (b)
and a modest amount of custom code. (I know there's the use case of
printing sequences; I'll try to give an analysis of this use case in
another post if one of its proponents doesn't do so soon.)
On Tue, 2005-09-06 at 00:56, Guido van Rossum wrote:
On 9/5/05, Barry Warsaw [EMAIL PROTECTED] wrote:
Eliminating the newline argument from print() would reduce the number of
reserved keyword arguments in my strawman by half. Maybe we could even
rename 'to' to '__to__' (!) to eliminate the
Guido van Rossum wrote:
So let's call it the Swiss Army Knife
(...Not) API design pattern.
Aha! Maybe this is the long-lost 20th principle from
the Zen of Python?
Greg
___
Python-Dev mailing list
Python-Dev@python.org
Greg Ewing wrote:
Guido van Rossum wrote:
So let's call it the Swiss Army Knife
(...Not) API design pattern.
Aha! Maybe this is the long-lost 20th principle from
the Zen of Python?
It also sounds like one of the reasons why the ultimates in programming swiss
army knives (that is, Lisp
On 9/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Positional arguments remove too much meaning from the template.
Compare:
'$user forgot to frobnicate the $file!\n'
with
'$1 forgot to frobnicate the $2!\n'
Whenever the template definition and its use are not directly
On 9/6/05, Nick Coghlan [EMAIL PROTECTED] wrote:
I did a fair bit of tinkering with that on the weekend. Printing a sequence of
strings is fine - it's the call to map(str, seq) that makes printing a
sequence of non-strings uglier than it should be. Doing it that way also
breaks the Python
On 9/6/05, Barry Warsaw [EMAIL PROTECTED] wrote:
printf('$1 forgot to frobnicate the $2!\n', username, file.name,
to=sys.stderr)
While that's a little less self-descriptive for a translator to deal
with (who would only see the string, not the call site), it certainly
looks nicer for
Guido van Rossum [EMAIL PROTECTED] wrote :
On 9/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Whenever the template definition and its use are not directly
adjacent, the template is that much harder to understand (i.e.,
This `i.e.` should have read `e.g.` :-(
in the context of
(just my 2 cents)
Le mardi 06 septembre 2005 à 07:23 -0700, Guido van Rossum a écrit :
On 9/6/05, Barry Warsaw [EMAIL PROTECTED] wrote:
printf('$1 forgot to frobnicate the $2!\n', username, file.name,
to=sys.stderr)
Is it worth doing this and completely dropping the %-based formats
Guido van Rossum [EMAIL PROTECTED] wrote:
[...]
OK, still with me? This, together with the observation that the only
use cases for the delimiter are space and no space, suggests that we
should have separate printing APIs for each of the use cases (a), (b)
and (c) above, rather than
Guido van Rossum [EMAIL PROTECTED] writes:
On 9/3/05, Bill Janssen [EMAIL PROTECTED] 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
On 9/6/05, Michael Hudson [EMAIL PROTECTED] wrote:
Gnyagh, couldn't you have *started* the thread with that post? :)
I hadn't anticipated so many great minds rusted shut. :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
On 9/6/05, Barry Warsaw [EMAIL PROTECTED] wrote:
printf('$1 forgot to frobnicate the $2!\n', username, file.name,
to=sys.stderr)
...
For me, the problem with that proposal is not the precise format syntax,
but the fact that formatting is tied to a specific function which _also_
On 9/6/05, Gareth McCaughan [EMAIL PROTECTED] wrote:
So borrow a trick from Common Lisp and use a destination of None
to mean return the formatted text as a string.
[...]
Or is that too cryptic?
Yes.
To my mind, formatting (returning a string) and output are separate
operations. A write
Nick Coghlan wrote:
Greg Ewing wrote:
Guido van Rossum wrote:
So let's call it the Swiss Army Knife
(...Not) API design pattern.
Aha! Maybe this is the long-lost 20th principle from
the Zen of Python?
It also sounds like one of the reasons why the ultimates in programming swiss
army
[Barry Warsaw wrote]
Also, we already have precedence in format+print in the logging
package. I actually think the logging provides a nice, fairly to use
interface that print-ng can be modeled on.
The main reason for doing that in the logging package is for
performance: processing the args
Michael Chermside wrote:
We could satisfy both people if in Python 2.x we introduced a
built-in function named print30 (for Python 3.0) with the intended
new behavior. People could start coding now using the print30
builtin. When Python 3.0 was released, 'print' would no longer be
a keyword,
LOL! That's a great solution for the 5 of us dinosaurs still using the
One True Editor. :)
And who also still program in C now and then :-). I think there are
more than 5 of us, though.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
Guido van Rossum wrote:
So let's call it the Swiss Army Knife
(...Not) API design pattern.
IIRC, this is one of the design principles which inspired Lisp mixins.
The idea was that different interfaces should be separated into
different classes. If you needed a class which combined them, you'd
In the end the process is not democratic.
Which may make it easier: rather than having to convince 50%+ of the people,
one only has to convince a single person...
I don't think there's anything that can change my mind
about dropping the statement.
As long as I don't think there's anything
Guido == Guido van Rossum [EMAIL PROTECTED] writes:
Guido I'm not at all convinced that we should attempt to find a
Guido solution that handles both use cases [print replacement
Guido and i18n]; most Python code never needs i18n.
It's true that the majority of Python applications
On 9/6/05, Stephen J. Turnbull [EMAIL PROTECTED] wrote:
It's true that the majority of Python applications never need i18n,
because they're only used in one language. But Python applications
are mostly assembled from a large and growing set of Python-standard
and other well-known libraries.
Steven Bethard wrote:
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__(), next(), readline(), readlines()
and writelines() to their file-like objects
who
On Mon, 5 Sep 2005, Martin Blais wrote:
However, there is an easy way out: hijack sys.stdout to forward to
your logger system.
I've got a web application framework that's setup like that right now,
it works great (if you will not need the original print-to-stdout
anymore in your program, that
On 5 sep 2005, at 18.56, Stephan Deibel wrote:
On Mon, 5 Sep 2005, Martin Blais wrote:
However, there is an easy way out: hijack sys.stdout to forward to
your logger system.
I've got a web application framework that's setup like that right
now,
it works great (if you will not need the
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.
One way would be to give the print() call additional keyword
arguments. For example,
On 9/5/05, Kay Schluehr [EMAIL PROTECTED] wrote:
[...] is the most heavyweight solution, but can encapsulate options and is
reusable:
Writer(sep=//).print(some,text)
some//text
or
writer = Writer(sep=//, file=sys.stderr)
writer.print(some,error-text)
writer.print(another,error
On Mon, 2005-09-05 at 20:52, Guido van Rossum wrote:
We could decide not to provide (b) directly, since it is easily
reduced to (c) using an appropriate format string (%s times the
number of arguments). But I expect that use case (b) is pretty
important, and not everyone likes having to use
Neil In interactive mode, you are normally interested in the values of
Neil things, not their formatting so it does the right thing.
class Dumb:
... def __init__(self, val):
... self.val = val
... def __str__(self):
... return Dumb val=%s % self.val
On 9/5/05, Barry Warsaw [EMAIL PROTECTED] wrote:
On Mon, 2005-09-05 at 20:52, Guido van Rossum wrote:
We could decide not to provide (b) directly, since it is easily
reduced to (c) using an appropriate format string (%s times the
number of arguments). But I expect that use case (b) is
On 9/1/05, Guido van Rossum [EMAIL PROTECTED] wrote:
[Charles Cazabon]
Perhaps py3k could have a py2compat module. Importing it could have the
effect of (for instance) putting compile, id, and intern into the global
namespace, making print an alias for writeln,
[Greg Ewing]
On 9/5/05, Barry Warsaw [EMAIL PROTECTED] wrote:
Eliminating the newline argument from print() would reduce the number of
reserved keyword arguments in my strawman by half. Maybe we could even
rename 'to' to '__to__' (!) to eliminate the other namespace wart. Is
this really too horrible:
[Nick Coghlan]
Print as statement = printing sequences nicely is a pain
What's wrong with this?
print range(10)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
print tuple(string)
('s', 't', 'r', 'i', 'n', 'g')
This is a serious question - that's how I would expect a print function to
work anyway.
Print as
[...]
maybe a few folks can go off and write up a PEP for a
print-replacement.
[...]
I'm pulling out of the
discussion until I see a draft PEP.
If there are two competing proposals, then the two groups write a PEP and
counter-PEP and the PEPs duke it out. Is this still the case if
Tony Meyer wrote:
[...]
maybe a few folks can go off and write up a PEP for a
print-replacement.
[...]
I'm pulling out of the
discussion until I see a draft PEP.
If there are two competing proposals, then the two groups write a PEP and
counter-PEP and the PEPs duke it out. Is
Tony Meyer wrote:
[Nick Coghlan]
Print as statement = printing sequences nicely is a pain
What's wrong with this?
print range(10)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
print tuple(string)
('s', 't', 'r', 'i', 'n', 'g')
This is a serious question - that's how I would expect a print
Gareth McCaughan:
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.
In interactive mode, you are normally interested in the values of
things, not their formatting so it
On 9/3/05, Tony Meyer [EMAIL PROTECTED] wrote:
If there are two competing proposals, then the two groups write a PEP and
counter-PEP and the PEPs duke it out. Is this still the case if proposal B
is very nearly the status quo?
No. The primary argument is between keeping the print statement
On 9/4/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Keeping print as a statement is certainly one of the options I'm considering,
so I don't think a counter-PEP is warranted just yet. There isn't even a PEP
to be a counter to - it's all still on the Wiki at the moment.
I am so far a bit
On 9/3/05, Bill Janssen [EMAIL PROTECTED] 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
On Sat, 2005-09-03 at 12:51, James Y Knight 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 14:42, Paul Moore wrote:
I have to agree. While I accept that Barry has genuine use cases for
the printf form, I don't quite see why %-formatting isn't enough. Is
the print-plus-% form so much less readable and/or maintainable?
IMO, yes. I can't tell you how many times
On Sat, 2005-09-03 at 13:12, Martin Blais wrote:
(defun python-abbrev-print ()
Help me change old habits.
(insert print()) (backward-char 1) t)
(put 'python-abbrev-print 'no-self-insert t)
(define-abbrev python-mode-abbrev-table print 'python-abbrev-print)
LOL! That's a great solution
[Barry]
Actually, we probably only /need/ printf(), and certainly for C
programmers (are there any of us left? ;), I think that would be a
small
conceptual leap. The motivation for keeping a non-formatting version
is
for simple cases, and beginners -- both of which use cases should not
be
On 9/4/05, Tony Meyer [EMAIL PROTECTED] wrote:
Yes. If it didn't have the redirect stuff; I would like it more if it also
didn't have the trailing comma magic. print is a fundamental; it deserves
to be a statement :)
I don't know exactly what you mean by fundamental, in opposition to
your
[Guido van Rossum]
[...] print is the only application-level functionality that has a
statement dedicated to it. Within Python's world, syntax is generally
used as a last resort, when something *can't* be done without help
from the compiler. Print doesn't qualify for such an exception
On Sun, 4 Sep 2005, Guido van Rossum wrote:
But more important to me are my own experiences exploring the
boundaries of print.
- I quite often come to a point in the evolution of a program where I
need to change all print statements into logging calls, or calls into
some other I/O or UI
Guido van Rossum [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Summarizing, my main problems with print as a statement are the
transformations -- when print doesn't cut it, you have to switch to
something entirely different. If it were a function the switch would
feel much
Meyer, Tony wrote:
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.
If writing to stdout
On Sep 4, 2005, at 12:51 PM, Barry Warsaw wrote:
On Sat, 2005-09-03 at 12:51, James Y Knight 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
On Sat, 2005-09-03 at 22:08, Nick Coghlan wrote:
See a (very quick and very dirty ;) strawman that I just posted to the
wiki. I think this has some interesting semantics, including the
ability to control the separator inline in a C++-like fashion. The
writef() version also accepts
On Sun, 2005-09-04 at 11:59, Guido van Rossum wrote:
I agree that those are strong arguments, so please hear me out.
Thanks Guido, I think your arguments are powerful too.
-Barry
signature.asc
Description: This is a digitally signed message part
On Sun, 2005-09-04 at 22:06, James Y Knight wrote:
No, we certainly don't /need/ printf(), as is well proven by its
current absence. Having the operation of printing and the operation
of string formatting be separated is good, because it means you can
easily do either one without the
On Sun, 2005-09-04 at 22:32, Guido van Rossum wrote:
Right. I just have one additional suggestion for the logging package
(not sure if it should apply to printf as well): if there's a problem
with the format operator, fall back to printing the format string
followed by the argument values (if
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
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,
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
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, 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,
1 - 100 of 192 matches
Mail list logo
