Re: [Python-Dev] Replacement for print in Python 3.0
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 actually that the comma after the
> last item can be optionally left out when there is more than one item in the
> sequence :)
>
Given
>>> (1,2,3,)
(1, 2, 3)
>>> (1,2,3,,)
File "", line 1
(1,2,3,,)
^
SyntaxError: invalid syntax
>>>
in Python 2.4, could the double-comma be imbued with some additional
mystical meaning that the print() function/method could recognise as
indicating a requirement to terminate output with a space rather than a
newline?
Python 3.0.6 (#17, Aug 13, 2008, 18:02:40)
[CC 4.6.2 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
.
.
.
>>> f = open("myfile.txt", "w")
>>> f.print('foo:', foo, 'bar:', bar, 'baz:', baz,,)
>>> if frobble > 0:
... f.print('frobble', frobble)
... else:
... f.print('no frobble today')
...
What other uses might this exciting new syntax (;-) find? Perhaps there
could also be special meanings for three and four training commas, and a
double-semicolon. Maybe it's time to consult Larry Wall?
I am aware this response seems flippant. Sorry.
I'm not against the introduction of the suggested new API, but that's
adding to the language rather than simplifying it, so I'm not sure I
understand the reason why the print statement must go (except to counter
the addition of the new API), particularly since Guido's original
venomous outburst arrived in the middle of a thread about Python 3.0
design principles:
>
> [Reinhold Birkenfeld]
>
>>> You'd have to enclose print arguments in parentheses. Of course, the
>>> "trailing
>>> comma" form would be lost.
>
>
> And good riddance! The print statement harks back to ABC and even
> (unvisual) Basic. Out with it!
>
Is the principle here "Python must be different from ABC and BASIC"? In
that case I suppose we'd better start thinking about what to use instead
of "if" and "for". What did the print statement do to us that it must be
cast out in this way?
I suspect the fundamental problem is that the commas do something more
than delimit sequence members. In which case we should say so rather
than belittling Python's ancient predecessors.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
___
Python-Dev mailing list
[email protected]
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:
>> - 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-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Asynchronous use of Traceback objects
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: @defgen def foo(): x = yield deferredOperation() print x Basically, defgen checks for Deferreds coming out of the generator, and when it finds one, adds a callback to that Deferred which will resume the generator, sending the result in. Since Deferreds have error support, it also allows code like this: @defgen def foo(userinput): try: x = yield deferredOperation(userinput) except ValueError: "Crap, wrong user input!" We have this object in Twisted called the "Failure", which is used for conveniently passing around exceptions asynchronously, and Deferreds use them to represent errors in deferred operations. The Failure objects have a reference to an exception object and the traceback that was associated with the original raising of that exception. However, we can only hold on to that traceback for so long, because traceback objects have references to so many things and can so easily cause horrible GC issues. The loss of this traceback object isn't *usually* a problem because we store enough other information in the Failure object to print representations of tracebacks nicely. However, if we try to re-raise the exception, we lose that traceback information. defgen re-raises the exception from a Failure into a defgen-using function with g.throw(). Unfortunately, quite often the traceback has been cleaned from the Failure object, and this means you'll get exceptions in defgen-using code with very bizarre and uninformative tracebacks. I had the idea to create a fake Traceback object in Python that doesn't hold references to any frame objects, but is still able to be passed to 'raise' and formatted as tracebacks are, etc. Unfortunately, raise does a type check on its third argument and, besides, it seems the traceback formatting functions are very reliant on the internal structure of traceback objects, so that didn't work. It does seem that I would be able to construct a passable fake Traceback object from C code -- one that had references to fake frames. These fake objects would only remember the original line numbers, filenames and so forth so that traceback printing could still work. I can try implementing this soon, but I'd just like to make sure I'm on the right track. 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 long as it matches the traceback interface. That would probably mean much more work, though. One concern is that I really don't like requiring C modules to use Twisted; all of the ones currently in there are optional. What's the likelihood of such a traceback-constructor getting its way into CPython if I do implement it? It may seem niche, but I expect many Twisted users would like to use PEP 342 defgen (many users are already using the defgen I wrote for python 2.2 generators). Thanks for any help, and have fun, -- Twisted | Christopher Armstrong: International Man of Twistery Radix|-- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// |-- http://twistedmatrix.com |o O|| wvw-+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Wiki page - PrintAsFunction
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?
There are several advantages such as persistent separators and being
able to have several different instances active at once.
Cheers,
Ron
import sys
class Print(object):
newline = '\n'
sep = ' '
def __init__(self, out=sys.stdout):
self.out = out
def __call__(self, *args, **kwds):
savesep = self.sep
try:
self.sep = kwds['sep']
except KeyError:
pass
for arg in args[:1]:
self.out.write(str(arg))
for arg in args[1:]:
self.out.write(self.sep)
self.out.write(str(arg))
self.sep = savesep
def ln(self, *args, **kwds):
self(*args, **kwds)
self.out.write(self.newline)
# default "builtin" instance
write = Print() # could be print in place of write in python 3k.
# standard printing
write.ln(1, 2, 3)
# print without spaces
write.ln(1, 2, 3, sep='')
# print comma separated
write.ln(1, 2, 3, sep=', ')
# or
write.sep = ', '# remain until changed
write.ln(1, 2, 3)
write.ln(4, 5, 6)
write.sep = ' '
# print without trailing newline
write(1, 2, 3)
# print to a different stream
printerr = Print(sys.stderr)
printerr.ln(1, 2, 3)
# print a simple sequence
write.ln(*range(10))
# Print a generator expression
write.ln(*(x*x for x in range(10)))
# print to file
f = open('printout.txt','w')
fileprint = Print(f)
fileprint("hello world\n")
f.close()
___
Python-Dev mailing list
[email protected]
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: > 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) > Illegal in python2.4.(Wrongly ?) And makes the star solution half unuseful. >>> def f(*args,**kwargs): ... pass ... >>> f(*(1,2,3),iter=True) File "", line 1 f(*(1,2,3),iter=True) Leaving out what I just asserted in the previous thread :( I suppose you meant output((x*x for x in range(10)), iter=1) f(1,[2,3],(_ for _ in (4,5)),iter=True) Regards Paolino ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Wiki page - PrintAsFunction
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 making it a class? That's what sys.stdout is for :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Wiki page - PrintAsFunction
"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 added, at least 95%) the common case should be easier, not harder. Terry J. Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Wiki page - PrintAsFunction
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 (in
> this case, with newline added, at least 95%) the common case should be
> easier, not harder.
Having write/writeln as builtins has that problem too (with writeln being more
common, but having the less obvious and longer name), but that pair of
functions is still what is currently recorded in PEP 3000 as the candidate
replacement for the print statement.
Unfortunately, giving "write" the behaviour of "writeln" would result in a
confusing difference between "sys.stdout.write('Hello world!')" and
"write('Hello world!')", where the latter appends a trailing newline, but the
former doesn't.
I figure the naming of any replacement function for the print statement is
going to end up squarely in Guido's court, particularly given that the need
for a workable transition strategy makes it difficult to use the most obvious
name (i.e., print).
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
[email protected]
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/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, but Nick Coghlan's output() function has persuaded me otherwise. Now, I'd say I was more concerned about going from *one* statement to *six* functions (the number you explicitly referred to in your posting - 3 methods and 3 builtins - but I'd be willing to concede that the exact number needed is vague, not least because the write method already exists...) > - Losing the automatically inserted space? This was important to me. > - Having to write more to get a newline appended? Not so much "more" as "ugly" - the function name writeln reminds me of Pascal (not a good thing!), and an explicit "\n" obscures the main intent of the code. > - Losing the name 'print'? Not a big deal, but it seems gratuitous. > 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, The opposite - to me, that just increases the number of proposed functions, which is one of my objections :-) > I'd like to be flexible on all points *except* the syntax -- I really > want to get rid of print as a *statement*. OK, how about a *single* builtin, named "print", which works something like Nick Coghlan's proposal (I'm happy to fiddle with the details, but the basic principle is that it can do all the variations the print statement can currently do - plus extra, in the case of Nick's code). It should rely solely on a stream having a "write" method (so there's no change to the "file-like object" interface, and existing objects don't need to be changed to support the new proposal). If you really want a stream.print method, I can cope, as long as it's clear that it's an *optional* part of the file-like interface - after all, it's a convenience method only. A mixin providing it might work, but I've no idea how you'd do a mixin which file-like objects implemented in C could use... A name other than "print" for the new builtin has the benefit that it could be introduced now, with Python 3.0 merely removing the print statement in its favour. But there isn't really a name I like as much as "print", and at least you *know* that no-one is using variable names that would hide a print builtin :-) > 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? No - and if that builtin was what you had proposed, you may not have got such a negative reaction :-) Paul. ___ Python-Dev mailing list [email protected] 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/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 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, an explicit check for types.GeneratorType would work, but I'm not sure if there's a more general check that might might work - for example, iter((1,2,3)) may be a candidate for looping over, where (1,2,3) clearly (? :-)) isn't. Maybe "iter(arg) is arg" is the right check... Of course, there's a completely separate question as to whether magic this subtle is *advisable*... Paul. ___ Python-Dev mailing list [email protected] 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/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 "", line 1 > f(*(1,2,3),iter=True) > > Leaving out what I just asserted in the previous thread :( I suppose you > meant output((x*x for x in range(10)), iter=1) > > f(1,[2,3],(_ for _ in (4,5)),iter=True) Yes, that's right, my bad, I indeed meant your corrected version above (forgot to remove the star) ___ Python-Dev mailing list [email protected] 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:
> 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, an explicit check for types.GeneratorType would
> work, but I'm not sure if there's a more general check that might
> might work - for example, iter((1,2,3)) may be a candidate for looping
> over, where (1,2,3) clearly (? :-)) isn't. Maybe "iter(arg) is arg" is
> the right check...
>
> Of course, there's a completely separate question as to whether magic
> this subtle is *advisable*...
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'))
writeln('def', (5, 6))
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
[email protected]
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
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 makes
it a non compatible solution with the rest of yours.
>writeln('def', (5, 6))
>
Regards Paolino
___
Python-Dev mailing list
[email protected]
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
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 this is a bug), which makes > it a non compatible solution with the rest of yours. 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, 16, 25, 36, 49, 64, 81 I personally believe keyword arguments should be allowed between *args and **kwds at the call site, and keyword-only arguments after * in the function definition, but the current behaviour has never bothered me enough for me to look into what would be required to change it. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] 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 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 actually
converted some code in our commercial app (if I have time I might look
at some code in Mailman) to try to understand why I disliked the
proposal so much.
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 that while this can be a real annoyance for some code,
there are some beneficial trade-offs that make this palatable. I
haven't read all the concrete proposals for the print() function, but
assuming it's something like the logger, it's very nice not to have to
do the %-operation explicitly. A very common case in my code is to have
a format string followed by a bunch of arguments, and including an
output stream. IWBNI could do something like this:
printf("""\
ERROR: Failed to import handler %s for function %s in file %s.
Improperly formed foobar string.""",
handler, function, file,
to=sys.stderr)
The other use case is where I don't have a format string and there, a
straight translation to
print('WAUUGH! object:', obj, 'refcounts:', sys.getrefcount(obj))
print('Finishing frobnication...', nl=False)
isn't horrible, although this looks kind of goofy to get a blank line:
print()
So for permanent code, I think it's a decent trade-off. We lose
something but we gain something. I'll mourn the syntax highlighting
loss (or end up hacking python-mode) but oh well.
I still suspect that a print function will be less friendly to newbies
and casual programmers. I can't test that, but I would love it if one
of the educators on this list could conduct some usability studies on
the issue.
I also suspect that having to use a function will every-so-slightly
impede the debug-to-console use of print. I haven't played with that
idea much, but I'll try it next time I'm doing something like that.
> - Losing the automatically inserted space?
Yes, definitely for the non-format-string variety. The two things I
hate most about Java's way is having to concatenate a string and having
to include the space myself. It's highly error-prone and ugly.
Above all else, /please/ avoid the forehead-welt-tool which is
System.out.println().
> - Having to write more to get a newline appended?
Yes, definitely. In everything I've converted, it's much more common to
want the newline than not. I want an easy way to suppress the newline,
but I'm willing to write "nl=False" to get that.
> - Losing the name 'print'?
I'm mixed on this. OT1H, I like print() better than write() but OTOH, I
can imagine that a decade of muscle memory will be hard to overcome.
> 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 know we'll have built-ins, but I disagree that debug prints will be
just as easy. Clearly they won't be, the question is to what degree
they will be harder to write and what benefit you will get in trade. If
those answers are "only a little bit" and "a lot", it will probably be
acceptable.
> 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?
Probably not, but such an alternative universe is hard to imagine, so
I'm not sure it would have dawned on anyone to suggest it. I think the
right approach is to design and add the replacement for Python 2.x,
encourage people to use it, and then see if it still warrants removal of
the print statement for Python 3.0.
fwiw-ly y'rs,
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
[email protected]
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
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, for example.
* Neal brought up the possibility of a conversion tool and wondered
how perfect it could be. Because it's currently syntax, this is a rare
case where the conversion can easily be made perfect (assuming the
tool has a complete Python parser). The only thing that wouldn't
necessarily be translated perfectly would be code manipulating
softspace directly.
* The possibility of future-proofing: I don't believe that this was a
major reason for the negative responses; after all, once we settle on
the function names & functionality, we can add the functions to 2.5
and people can start using them at their leisure. (This was actually
why I proposed different names.)
* Don't break it just because it's too much like Basic or ABC? I never
meant it that way. In ABC, WRITE was actually *more* like a procedure
call, because procedure calls in ABC don't use parentheses. I think
the old Basic wasn't such a bad language as its reputation would like
to have it; it was fully interactive, and quite good for teaching. The
problem that the ABC authors were mainly fighting was arbitrary
limitations and lack of structured programming support -- for example,
old Basic implementations often had 1- or 2-char variable names only,
heavily relied on GOTO, and there were no locals. The ABC authors also
made a slogan of getting rid of PEEK and POKE, but ABC never did
provide a replacement for interacting with the environment or
graphics. Basic's WRITE statement (in the version that I remember) had
to be a statement because there were no predefined procedures -- only
a few functions, all other predefined functionality was statements.
Since WRITE was the only game in town, it used some syntax hacks:
separating items with commas caused them to be written as
20-character-wide columns; using semicolons instead caused single
spaces to appear between (it would have made more sense the other way
around, but I guess they were constrained by backward compatibility,
too :-). I guess Python's print statement's trailing comma reminds me
of the latter feature.
* Alas, writing the arguments to the print statement in parentheses is
not enough to future-proof your code, even if we had a print()
function that behaved right; print ('a', 'b') prints something
completely diferent than print 'a', 'b'. (The former prints a tuple
with quoted string literals.) The only thing that could mean the same
would be print(expr) with a single expression argument.
* A lot of discussion has actually focused on getting the semantics of
the replacement function right, and I like a lot of what was written.
Here's my own version:
print() could become a built-in function that behaves roughly like the
current print statement without a trailing comma; it inserts spaces
between items and ends with a newline. A keyword argument (file= or
to=?) can specify an alternate file to write to (default sys.stdout);
all that is used is the file's write() method with one string
argument. The softspace misfeature goes away.
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, sep="//" would print double slashes between
the items, and sep="" would concatenate the items directly. And
end="\r\n" could be used to change the newline delimiter to CRLF,
while end="" would mean to suppress the newline altogther.
But to me that API becomes rather klunky; I'd rather have a separate
function (printbare() or write()?) that just writes its arguments as
strings to sys.stdout (or to the file given with a keyword argument)
without intervening spaces or trailing newline. If for example you
want the intervening spaces but not the trailing newline, sorry,
you're going to have to write the spaces yourself, which is no big
deal IMO. The new API is still much easier to use than what you have
to do currently for more control (sys.stdout.write()).
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.
It would be easier from a future-proofing standpoint if the main
function *wasn't* called print; but people seem to react intuitively
to the name change, and there are other approaches available (like a
conversion program or running P2 programs in the P3 VM using a
backwards compatible parser+translator).
Maybe someone can work this into the Wiki?
(http://wiki.python.org/moin/PrintAsFunction)
As I said, I'm flexible on all the details but I really want to get
rid of the statement syntax for this functio
Re: [Python-Dev] Replacement for print in Python 3.0
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, they won't be distinguished by their end-of-line behavior. That is easily handled by a keyword argument. More important IMO will be the need to distinguish whether you want a format string or not. The two use cases I came up with (and posted about previously) are: print 'obj:', obj, 'refcounts', sys.getrefcount(obj) print 'obj: %s, refcounts: %s' % (obj, sys.getrefcount(obj)) Despite that these look superficially equivalent, they really aren't. The problem is that if you used one function, you'd have to make the format string selectable by keyword argument. But that's really ugly because the focus of the operation /is/ the format string, and you really want that to come first, not last, in the function call order. So the alternative is to do some magical interpretation of the first argument to decide whether it's a format string or not. Ick! So 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" if that's what you wanted. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] 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
[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" if that's what you > wanted. Good improvements. Raymond ___ Python-Dev mailing list [email protected] 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 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 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 string.Templates or %s-strings as its first argument. I'm not sure I like reserving 'to' and 'nl' keyword arguments, and not having the ability to print Separator instances directly, but OTOH maybe those aren't big deals. Anyway, this is close to what (I think) I'd like to see in the proposed built-ins. I'm out of time for now, so I'll check back later for all the derision and mocking. :) -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] 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 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 xyzf functions, because formatting is an operation you can do directly on the string and pass that to any function you like. It's much cleaner... James ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] iterators and extended function call syntax (WAS: Replacement for print in Python 3.0)
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 brought up a few pretty valid complaints, the biggest of which is that a lot of code now expects *args to be sequences, not iterators. For example, the code you posted on the Wiki[1] would break: def write(*args, **kwds): ... # may break if args iterator does not have a __len__ if not args: return ... # will break unless "args = tuple(args)" precedes it stream.write(str(args[0])) for arg in args[1:]: stream.write(sep) stream.write(str(arg)) This code would have to be rewritten to use the iterator's .next() method and try/excepts for StopIterations. It's not particularly hard, but people would have to do some relearning about *args. [1] http://wiki.python.org/moin/PrintAsFunction STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] 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/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 PITA when the start of > the function call is separated from the end by many lines. (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) ___ Python-Dev mailing list [email protected] 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
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__(), 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 don't
already have one...
STeVe
--
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
[email protected]
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 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 suggested). I don't
think that:
write("""\
ERROR: Failed to import handler %s for function %s in file %s.
Improperly formed foobar string.""".substitute(handler, function, file),
to=sys.stderr)
is really any worse than:
printf("""\
ERROR: Failed to import handler %s for function %s in file %s.
Improperly formed foobar string.""",
handler, function, file,
to=sys.stderr)
STeVe
--
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] iterators and extended function call syntax (WAS: Replacement for print in Python 3.0)
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/pipermail/python-list/2004-December/257282.html > > Raymond Hettinger brought up a few pretty valid complaints, [...] What he said. There's no way this is going to happen. If you want to have a function that takes an iterator and you want to pass it an iterator, just do that -- don't use the *args notation. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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/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, 16, 25, 36, 49, 64, 81 > > I personally believe keyword arguments should be allowed between *args and > **kwds at the call site, and keyword-only arguments after * in the function > definition, but the current behaviour has never bothered me enough for me to > look into what would be required to change it. Same here. If anyone wants to give it a try, please go ahead! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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
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 speak up now and volunteer as a co-author. I suggest the wiki as a place for working out drafts. I'm pulling out of the discussion until I see a draft PEP. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Asynchronous use of Traceback objects
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 long as it matches >the traceback interface. Given that traceback printing isn't a performance-critical activity, there probably isn't a reason any more for requiring a particular C layout. On the other hand, being able to create frame or traceback instances or subclasses would probably also solve your problem, without having to do too much hacking on the C code that expects a particular layout. ___ Python-Dev mailing list [email protected] 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/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. I've always really liked that Python doesn't have > separate xyzf functions, because formatting is an operation you can > do directly on the string and pass that to any function you like. > It's much cleaner... 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? Paul. ___ Python-Dev mailing list [email protected] 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 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 add a second builtin just to apply the > > % operator for you. I've always really liked that Python doesn't have > > separate xyzf functions, because formatting is an operation you can > > do directly on the string and pass that to any function you like. > > It's much cleaner... > > 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? printf does avoid one extra set of () in many cases, making the code look and indent nicer. 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 printer anymore. We all love it! I know Guido wanted a different name so that print() could be introduced in python 2 to allow a smooth transition to python 3, but the disadvantages in lost readability and familiarity by far outweigh the transition concerns imho. Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] str.strip() enhancement
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 some examples, first argument string
to be stripped, second argument a list of things to strip:
#A char list gives the same result as the standard strip
>>> my_strip("abcdeed", "de")
'abc'
#A list of strings instead
>>> my_strip("abcdeed", ("ed",))
'abcde'
#The char order in the strings to be stripped are of importance
>>> my_strip("abcdeed", ("ad", "eb"))
'abcdeed'
Functions used in the above examples:
def my_lstrip(str, list):
ret_str = str[max([k == True and len(v) for (k,v) in zip
([str.startswith(e) for e in list], list)]):]
if ret_str != str:
return my_lstrip(ret_str, list)
return str
def my_rstrip(str, list):
ret_str = str[:len(str)-max([k == True and len(v) for (k,v)
in zip([str.endswith(e) for e in list], list)])]
if ret_str != str and ret_str != False:
return my_rstrip(ret_str, list)
return str
def my_strip(str, list):
return my_lstrip(my_rstrip(str, list), list)
Would this be useful for anyone else besides me?
--
Jonny Reichwald
___
Python-Dev mailing list
[email protected]
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
"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 printer anymore. We all love it! I know Guido wanted a different
> name so that print() could be introduced in python 2 to allow a smooth
> transition to python 3, but the disadvantages in lost readability and
> familiarity by far outweigh the transition concerns imho.
'prnt(' (or any other temp name) could easily be searched/replaced by
'print(' when the time comes.
Terry J. Reedy
___
Python-Dev mailing list
[email protected]
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
>> 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, Neal> the major backlash has swayed me some, if for no other reason that Neal> people are so strongly against changing it. I think from Guido's perspective the print statement is a wart. From my perspective I see it as a case of if it ain't broke, don't fix it. I'll adapt to a print function easily enough. The breakage just seems unnecessary. Neal> What if a tool existed that did the conversion? I realize that Neal> the tool is unlikely to be perfect, but what if it could do 99.9% Neal> of the job? I'm not thinking about just fixing print, but also Neal> converting iterkeys/itervalues/iteritems, xrange -> range, Neal> raw_input -> input, warning about use of input(), etc. That's a different subject altogether, especially if you are talking about more than just converting print. It should probably have its own subject and thread. I don't know what's in the "etc" part, but I've never used iter-this-n-that (their names have always seemed ugly enough that I've simply avoided them) or raw_input, I rarely use xrange, and the conversion is trivial, so the only potential benefit for me would be print, which I can probably get 90% of the way there with a couple Emacs macros. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.strip() enhancement
[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 useful for anyone else besides me? Probably not. Have you seen any other requests for something similar? Are there precedents in any other language? Can you point to examples of existing code other than your own that would benefit? 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. Raymond ___ Python-Dev mailing list [email protected] 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
> 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 gratuitous breakage is one good argument for retaining it, but by no means the main argument. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.strip() enhancement
"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 words from the stripped string. > . . . > > > Would this be useful for anyone else besides me? > > Probably not. There is also the point that this functionality is a 4-line function... def trim_endings(strng, endings): for ending in endings: if ending and string.endswith(ending): return strng[:-len(ending)] - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Hacking print (was: Replacement for print in Python 3.0)
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, but uses the Python string formatting to merge the ARGS into the FORMAT-STRING. Having the printf-style formatting seems to me to outweigh the irritation of having to surround my args with parentheses (why are parentheses shifted characters?!), though having both would be great. If an integer LEVEL is provided, it is compared to the current output-level setting, and if LEVEL is *higher* than the current setting, the output is suppressed. The default LEVEL is 1. Normally, "note" writes to sys.stderr, but there are functions to set both the note-level and the note-sink. Adding the "\n" to the end of the format string seems to be just as easy as writing "noteln", and much clearer, so I've never even considered adding a "-ln" variant of this function. I think the "-ln" variants made familiar by Pascal and Java were a bad idea, on a par with the notion of a split between "text" and "binary" file opens. I might even be in favor of retiring "print" if it were replaced with a different statement, say "printf", which had the capabilities of "note", but didn't require parentheses around its arguments. Bill ___ Python-Dev mailing list [email protected] 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 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 that while this can be a real annoyance for some code, > there are some beneficial trade-offs that make this palatable... > So for permanent code, I think it's a decent trade-off. We lose > something but we gain something. I'll mourn the syntax highlighting > loss (or end up hacking python-mode) but oh well. Wouldn't it make sense then to replace the "print" statement with a "printf" statement? Then you'd get the formatting, and wouldn't have to type the parentheses. I don't see an argument for moving to a function; indeed, there's an argument against. What you want is a fancier print. Bill ___ Python-Dev mailing list [email protected] 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 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, for example. 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 "@" wasn't used instead. :-) Seems pretty weak to me. Are there other args against? What baffles me is that when I read through the rest of PEP 3000, I agree with the other changes. But removing "print" sticks in my craw, and there's no real justification for it. I just don't get it. If someone said, "print" doesn't support a format argument as C printf does, I'd say that's a strong argument. But an argument for extending "print" once again, not junking it. Unless it was perhaps replaced with: >>> printf @sys.stderr %"Must output %s at once!" "important message" Bill ___ Python-Dev mailing list [email protected] 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
Or perhaps: >>> print [with FORMAT-STRING] [>> STREAM] *ARGS as an alternative to >>> printf [@ STREAM] FORMAT-STRING *ARGS Bill ___ Python-Dev mailing list [email protected] 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
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 "@" > wasn't used instead. :-) > > Seems pretty weak to me. Are there other args against? 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. BTW, the implementation he refers to in this post is at: http://mail.python.org/pipermail/python-dev/2005-September/056075.html and the updated version is at: http://wiki.python.org/moin/PrintAsFunction STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.strip() enhancement
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 single, clear, unified, > cohesive > concept. I am not aware of these difficulties, any pointers? From an API pow, I do not think it neccessarily complicates it, but rather generalizes it in a way that may not be very usable :) I can understand that it would probably not be worth the effort though... -- Jonny Reichwald ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.strip() enhancement
> > 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 memory, write-down what you think str.split() does. Then look at the docs and see how much you got wrong and how much you missed. A thorough answer would cover empty string behaviors, the return type, whether None is allowed, whether a keyword argument is acceptable, and the effects of using a unicode or UserString argument. For extra credit, write down the length invariant and determine whether a string.join() invariant would always hold. The str.split() API has led to countless doc revisions, invalid error reports, newsgroup discussions, and questions on the tutor list. We ought to keep it unchanged for Py3.0 just to serve as a warning to future generations ;-) > From an API pow, I do not think it neccessarily complicates it Please stop smoking crack before posting to python-dev ;-) Try updating the doc string, library reference entry, and the test suite. Be sure to specify that the proposed arguments are non-commutative and whether general iterables are allowed. Then report back that there was no change in complexity. >, but > rather generalizes it in a way that may not be very usable :) > I can understand that it would probably not be worth the effort > though... Hmm, that suggests another design principle, "If a proposer lacks faith in his or her own proposal, it is doomed." Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] iterators and extended function call syntax (WAS: Replacement for print in Python 3.0)
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: >>http://mail.python.org/pipermail/python-list/2004-December/257282.html >> >>Raymond Hettinger brought up a few pretty valid complaints, > > [...] > > What he said. There's no way this is going to happen. If you want to > have a function that takes an iterator and you want to pass it an > iterator, just do that -- don't use the *args notation. I guess that answers that, then. . . so noted on the Python 3.0 Suggestions wiki page. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Asynchronous use of Traceback objects
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 accept > >arbitrary Python objects as its third argument, as long as it matches > >the traceback interface. > > Given that traceback printing isn't a performance-critical activity, there > probably isn't a reason any more for requiring a particular C layout. On > the other hand, being able to create frame or traceback instances or > subclasses would probably also solve your problem, without having to do too > much hacking on the C code that expects a particular layout. I guess the biggest difference in these two strategies, to me, is that one can be implemented in an external module while the other *requires* changes to CPython to work. So I'll do the former, i.e., writing C functions that construct traceback objects, accessible from Python. Maybe after I do that I could write a PEP (if that's necessary) on changing the traceback stuff on a more fundamental level, to allow for Python objects. putting-on-his-C-gloves-ly, -- Twisted | Christopher Armstrong: International Man of Twistery Radix|-- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// |-- http://twistedmatrix.com |o O|| wvw-+ ___ Python-Dev mailing list [email protected] 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
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 ;) 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 string.Templates or %s-strings as its
> first argument. I'm not sure I like reserving 'to' and 'nl' keyword
> arguments, and not having the ability to print Separator instances
> directly, but OTOH maybe those aren't big deals.
The latter problem is easily solved by calling str() at the point of the call
so that write() never sees the actual Separator object. However, this 'inline'
behaviour modification has always annoyed me in C++ - if you want this kind of
control over the formatting, a format string is significantly clearer. I think
your own examples from the Wiki page show this:
write('obj:', obj, 'refs:', refs)
write(Separator(': '), 'obj', obj,
Separator(', '), 'refs',
Separator(': '), refs,
nl=False)
write()
writef('obj: %s, refs: %s', obj, refs)
writef(Template('obj: $obj, refs: $refs, obj: $obj'),
obj=obj, refs=refs,
to=sys.stderr,
nl=False)
That said, looking at 'writef' suggests a different solution to me - a builtin
called 'format'. The latter two examples would become:
write(format('obj: %s, refs: %s', obj, refs))
write(format(Template('obj: $obj, refs: $refs, obj: $obj'),
obj=obj, refs=refs),
to=sys.stderr,
nl=False)
Separating the formatting out into a separate functions like this addresses
your concern with the namespace conflict for 'to' and 'nl', and also makes the
'format' builtin more generally useful, as it can be used for cases other than
direct output to a stream.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Mixin classes in the standard library
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 don't > already have one... Where would we put it though? I sometimes wonder if there should be a 'mixins' module to provide a one-stop shop for finding things like DictMixin and ListMixin. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] 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, > 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 "arguments" compelling. I did not. I thought it was rather weak. The "points" he makes seem either irrelevant or style judgements, and many seem mischaracterized by the words used. Point by point: > "Print as statement" => printing sequences nicely is a pain > "Print as function" => extended call syntax deals with sequences nicely True, but I see it as a weakness in the Python string formatting language, instead of a weakness with "print". I think that print should be extended with a printf-like format argument (or replaced with a "printf" statement), and that the formatting available in this format argument should handle this complaint. > "Print as statement" => can't easily change the separator > "Print as function" => keyword argument handles the separator nicely So what? To begin with, "print" users have been "changing the separator" for years by doing string concatentation where it matters. And there's always file.write() for those who need it. > "Print as statement" => trailing comma suppresses newline by magic > "Print as function" => keyword argument handles the line terminator nicely This is a somewhat argumentative way of writing this. It would be better put as "newline emission control is performed syntactically", which I see as neutral. Style judgement. > "Print as statement" => redirection is via a magic symbol > "Print as function" => keyword argument handles redirection nicely This is a somewhat argumentative way of writing this. It would be better put as "output redirection is indicated syntactically", which I see as neutral. Style judgement. I might write this point as "Print as statement" => redirection is via a cool magic symbol "Print as function" => redirection done with a boring wordy keyword arg See what I mean? > "Print as statement" => can't easily save 'settings' for re-use > "Print as function" => can use functional.partial to create custom version So what? Who in the world thought up this as a reasonable feature for "print"? Oh, well: file a feature request and see what happens. 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. Let's add a good format specifier to "print", instead. Bill ___ Python-Dev mailing list [email protected] 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
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 you found those "arguments" compelling.
>
> I did not.
>
> I thought it was rather weak. The "points" he makes seem either
> irrelevant or style judgements, and many seem mischaracterized by the
> words used.
>
> Point by point:
>
>
>>"Print as statement" => printing sequences nicely is a pain
>>"Print as function" => extended call syntax deals with sequences nicely
>
>
> True, but I see it as a weakness in the Python string formatting
> language, instead of a weakness with "print". I think that print
> should be extended with a printf-like format argument (or replaced
> with a "printf" statement), and that the formatting available in this
> format argument should handle this complaint.
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:
("% i" % my_seq) => " ".join(my_seq)
("%, i" % my_seq) => ", ".join(my_seq)
I see this as being similar to the way that "%.2f" controls the way that a
floating point value is displayed.
> 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. Let's add a good format specifier to "print",
> instead.
The real driver is that Guido wants to change it, but I'm actually starting to
think I like having the print statement, and what I really want is a 'format'
builtin to get around the tuple-related quirks of the string mod operator, and
an enhancement to the string mod operator to deal better with iterables.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
[email protected]
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 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).
>
> 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.
Yeah, but the cost is a constant -- it is not related to the cost of
compiling the re. (You should've shown how much it cost if you
included the compilation in each search.)
I haven't looked into this, but I bet the overhead you're measuring is
actually the extra Python function call, not the cache lookup itself.
I also notice that _compile() is needlessly written as a varargs
function -- all its uses pass it exactly two arguments.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
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
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:
> ("% i" % my_seq) => " ".join(my_seq)
> ("%, i" % my_seq) => ", ".join(my_seq)
>
> I see this as being similar to the way that "%.2f" controls the way that a
> floating point value is displayed.
A correction to this - such a formatting operator would need to automatically
invoke str on the items in the iterable:
("%i" % (my_seq,)) => "".join(map(str, my_seq))
("% i" % (my_seq,)) => " ".join(map(str, my_seq))
("%, i" % (my_seq,)) => ", ".join(map(str, my_seq))
("%(seq), i" % dict(seq=my_seq)) => ", ".join(map(str, my_seq))
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
[email protected]
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
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 other examples:
>>("% i" % my_seq) => " ".join(my_seq)
>>("%, i" % my_seq) => ", ".join(my_seq)
>>
>>I see this as being similar to the way that "%.2f" controls the way that a
>>floating point value is displayed.
>
>
> A correction to this - such a formatting operator would need to automatically
> invoke str on the items in the iterable:
>
> ("%i" % (my_seq,)) => "".join(map(str, my_seq))
> ("% i" % (my_seq,)) => " ".join(map(str, my_seq))
> ("%, i" % (my_seq,)) => ", ".join(map(str, my_seq))
> ("%(seq), i" % dict(seq=my_seq)) => ", ".join(map(str, my_seq))
Hmm, 'i' is already taken. I think I'll use 'j for join' while working on a
patch. The full specification of the number formatting operations is
impressive, though (this is the first time I've actually read the full
description of the string formatting behaviour).
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
[email protected]
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
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 will make Python's parser more complex, while converting the print statement to a function should make Python's parser simpler. STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] 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
[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 statement" => can't easily change the separator
[etc]
To me, the point of the builtin print is that it's simple. If you want to
control what separator is used, or if there is a newline at the end, or
print to something that isn't sys.stdout, or some other magic, then use
sys.stdout.write(). If you want to get the contents of __unicode__/__str__
of an object to stdout, which there has been overwhelming evidence is a very
common task, then print is a fantastically simple and straightforward way to
do that.
[Terry Reedy]
> 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.
But seven keypresses (assuming one is using a keyboard where you use shift
to get '(' and ')'). It sounds trivial, but a print statement (i.e. no ())
looks clean and concise. I like this:
while True: pass
More than:
while (true) {}
For the same reason. This is a big plus of Python vs. C.
[Guido]
> 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?
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 :)
=Tony.Meyer
___
Python-Dev mailing list
[email protected]
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
[...] > 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 proposal B is very nearly the status quo? IOW, would writing a "Future of the print statement in Python 3.0" counter PEP that kept print as a statement be appropriate? If not, other than python-dev posting (tiring out the poor summary guys <0.5 wink>), what is the thing to do? =Tony.Meyer ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
