print "hello", >> file
Jp Calderone
exarkun at intarweb.us
Tue Feb 25 15:40:08 EST 2003
On Tue, Feb 25, 2003 at 08:22:43PM +0000, phil hunt wrote:
> On Tue, 25 Feb 2003 13:47:04 -0500, Jp Calderone <exarkun at intarweb.us> wrote:
> [snip]
> >
> > This rebinds "s" to a new string object. I suppose this hypothetical "<<"
> >operator could do the same.
>
> Indeed. IMOv it's irrelevant whether += (or <<, or whatever) is
> implemented by modifying an existing object or binding to a new one
> -- that's just an implementation detail, of no more significance
> bthan whether the underlying processor is a Pentium or ARM.
>
No way. It -totally- matters. Imagine you have a Queue object you use to
pass messages between two unrelated parts of your program. You could define
+= for this Queue to add new messages to it.
messageQueue += newMessage
and
message = messageQueue.pop()
Now imagine that += rebinds the left-hand argument to a new Queue object.
Oops! The other part of your program will never receive any messages!
Ignore that this is a ridiculous example (who would have an immutable
Queue?) and just consider the implications of the implementation leaving
unspecified whether an operation modified the object in place or rebound it
to a new one. It is unlikely that any programs would work at all.
> > OTOH, why does anyone want yet -another- way to
> >concatenate strings?
>
> I don't particularly. I think that if Python had been designed from
> scratch to use << for all 3, it'd be more concise and a cleaner
> design -- but we are not designing Python from scratch.
>
Or possibly if "print" did not exist at all ;) The file IO API is quite
clean and consise if you disregard it (sys.stdin and sys.stdout have "read"
and "write" methods, like any other file). However, just for fun:
class iostream(file):
def __lshift__(self, arg):
file.write(self, str(arg))
return self
Knock yourself out ;)
Jp
--
"One World, one Web, one Program." - Microsoft(R) promotional ad
"Ein Volk, ein Reich, ein Fuhrer." - Adolf Hitler
--
up 17 days, 0:29, 3 users, load average: 0.27, 0.21, 0.18
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20030225/aee1d54b/attachment.sig>
More information about the Python-list
mailing list