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?
/F
___
Python-Dev mailing list
Python-Dev@python.org
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 Python-Dev@python.org 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
Python-Dev@python.org
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 stdin, 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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
Python-Dev@python.org
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 Python-Dev@python.org 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 Python-Dev@python.org 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 stdin, 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 Python-Dev@python.org 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
Python-Dev@python.org
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
Python-Dev@python.org
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 Python-Dev@python.org 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
Python-Dev@python.org
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 functionality.
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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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
Python-Dev@python.org
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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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
Python-Dev@python.org
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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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
Python-Dev@python.org
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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
