[...]
> 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 prop
[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.
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 statemen
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 form
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 othe
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
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 n
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 you found those "argume
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 d
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
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
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:
>>
> > 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?
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 b
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 th
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:
http:/
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
> ar
> 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
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,
"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 remov
> 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 gra
[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
>> 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. Howe
"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 g
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 som
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 see
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
> % opera
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
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 spea
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
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:
> http://mail.python.org/pip
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
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 a
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 ca
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 b
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
separa
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 pos
[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 "str
On Sat, 2005-09-03 at 09:15, Paul Moore wrote:
> OK, how about a *single* builtin, named "print", which works something
> like Nick Coghlan's proposal (I'm happy to fiddle with the details,
So I've now read Nick's wiki page and here are my comments:
First, while I think you'll need two builtins,
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,
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
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(
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), whic
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 simple
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=T
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 t
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 i
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 m
"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
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.
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 ex
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
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 like
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?
___
Python-D
Nick Coghlan wrote:
> Martin Blais wrote:
>
> 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
55 matches
Mail list logo
