Again: Please hear my plea: print without softspace

[Martin Bless]

[Andrei <fake at fake.net>]

>In these cases I tend to use string formatting, e.g.:
>
>print '%s-%s-%s' % (1,2,3)
>
>As others have already pointed out, there are several other ways too, so
>making a new keyword for this doesn't seem very useful.

That's exactly the point I'm trying to make: I think this new keyword
*would* be extremely useful.

The general advice I received so far is: "roll your own writer object,
create a wrapper, do those string calculations yourself, then hand the
ready to print output to 'print' or some 'write' method.  'print'
isn't good enough for sophisticated use, there are many ways to format
your output correctly..."

I *know* there are many ways. The point is: many of these
"workarounds" only come into play because there *is no* built in
variant of 'print' that doesn't emit blanks.

Advocating the 'print statement':

Let's remember:

print_stmt  ::=  "print" ( [expression ("," expression)* [","]] 
    | ">>" expression [("," expression)+ [","]] ) 

- Obviously it *is* an important language feature: it even has its own
keyword.
- It's easy to use  and *scalable* (no parentheses, variable number of
arguments).
- readable: pure list of arguments.
- Its efficient, since it has its built in ways of transforming
expressions to output strings, processing one by one. No need to join
those parts first.
- As a language feature it's well documented.
- 'print statements' stand for themselves and are highly expressive
and self documenting. Understanding, copying and pasting relies less
on context.

In one word: Looks like a very pythonic feature to me. Very
attractive.

And I'd simply like to benefit from all of these advantages. 99% seem
to be ok and because of 1% bad we can't use it to the full.

Aside: And there even must have been a time where 'print' has been
considered important enough to fight a long battle about introducing
the "chevron" form ('>>')...

Don't panic:

Of course I'm not saying we should change the existing behaviour of
'print' in any way.

But:

On the other hand: introducing a new keyword like 'printn' or 'prin0'

- wouldn't break any existing code
- wouldn't introduce a change of language structure
- could be documented within a few sentences ("... behaves like
'print' but does not insert blanks ...")
- and my suspicion is that the implentation in C isn't much of a
problem.

It's just like having a variant of something we allready have with
slightly different semantics. And that's ok and exactly what we want.
And it's no problem because we'd have a unique new name for it.

As far as I can see there's much benefit and little costs.

Ok, then back to where I startet. Let me asked again:

"Can we have an additional 'print' statement, that behaves exactly
like 'print' but doesn't insert blanks between arguments?"

curious,

Martin