YA string interpolation and printing idea

[Paul Rubin]

How about adding a string interpolation method and a some print
methods to strings.

'hello world'.print([fd]) => same as "print 'hello world'". With optional
fd arg, print to file object
'hello world'.write([fd]) => same as "sys.stdout.write('hello world')"
i.e. print with no trailing newline
'hello $name'.interp() => like "'hello %s'%name"
'hello $name'.fprint([fd]) => like ('hello %s'%name).print([fd])
'hello $name'.fwrite([fd]) => like ('hello %s'%name).write([fd])

[Erik Max Francis]

Paul Rubin wrote:

How about adding a string interpolation method ...
You already have one with the % operator:

"hello %(name)s" % locals()
... and a some print
methods to strings.

Why in the world would you want that? Printing methods go on the things
that do work of printing, which are file-like objects, not strings.
And, on file-like objects, that method is called `write'.

--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
\__/ It comes from inside, and that's what I consider to be soul music.
-- Sade Adu

[Paul Rubin]

Erik Max Francis <ma*@alcyone.com> writes:

Why in the world would you want that? Printing methods go on the things
that do work of printing, which are file-like objects, not strings.
To give a convenient way to do interpolated printing. Practicality
beats purity. Another approach I like is to define a unary minus
operation on strings, which does interpolation. But that's gone
nowhere when I've proposed it in the past. Maybe if type/object
unification proceeds far enough, we'll someday be able to define our
own operations on builtin objects like strings.
And, on file-like objects, that method is called `write'.

'write' does what it should, which is writes out exactly the
characters you give it. Python's print statement does the same plus
adds a newline, and people have gotten used to that misbehavior
(explicit is better than implicit), so I made an accomodation for that.

[Christos TZOTZIOY Georgiou]

On 16 Jan 2004 20:52:08 -0800, rumours say that Paul Rubin
<http://ph****@NOSPAM.invalid> might have written:

Maybe if type/object
unification proceeds far enough, we'll someday be able to define our
own operations on builtin objects like strings.

I'd like that too, and I believe Ruby does it; however, ISTR that Guido
has specifically said that this won't be allowed, since you can always
subclass the base types. He's the boss :)

I've also seen a hackish patch (by MWH? can't be sure) that allowed one
to substitute their own classes for the base types (so that integer or
string constants would be instances of the derived subclasses). Don't
know if that would help you in your code.
--
TZOTZIOY, I speak England very best,
Ils sont fous ces Redmontains! --Harddix

[Michele Simionato]

Christos "TZOTZIOY" Georgiou <tz**@sil-tec.gr> wrote in message news:<gk********************************@4ax.com>. ..

On 16 Jan 2004 20:52:08 -0800, rumours say that Paul Rubin
<http://ph****@NOSPAM.invalid> might have written:

Maybe if type/object
unification proceeds far enough, we'll someday be able to define our
own operations on builtin objects like strings.

I'd like that too, and I believe Ruby does it; however, ISTR that Guido
has specifically said that this won't be allowed, since you can always
subclass the base types. He's the boss :)

I've also seen a hackish patch (by MWH? can't be sure) that allowed one
to substitute their own classes for the base types (so that integer or
string constants would be instances of the derived subclasses). Don't
know if that would help you in your code.

In Python, you cannot change built-in types, but you can always derive
a new type with additional methods and give to the new type the name
of a built-in type. So, we don't miss much of Ruby functionality, we just
miss is a bit of sugar. Also, knowing that the builtins types are fixed,
gives me some sense of safety ...

Micjele