On 9/5/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-09-05 at 20:52, Guido van Rossum wrote:
>
> > We could decide not to provide (b) directly, since it is easily
> > reduced to (c) using an appropriate format string ("%s" times the
> > number of arguments). But I expect that use case (b) is pretty
> > important, and not everyone likes having to use format strings. This
> > could be reduced to a special case of the Swiss Army Knife (...Not)
> > rule.
>
> I'm not sure. I do agree with your design principles (though I might
> call it "Sometime's a Spoon's Just a Spoon" ;) but thinking about my own
> uses of print, I think we could easily get away with just (a) and (c).
> I think someone else felt the same way in an earlier response to my
> strawman, pointing out that the inline Separator instances wasn't really
> any more usable than just degenerating to the format string version.
> There's no doubt that the format string approach gives you direct
> control over every character.
>
> Eliminating the newline argument from print() would reduce the number of
> reserved keyword arguments in my strawman by half. Maybe we could even
> rename 'to' to '__to__' (!) to eliminate the other namespace wart. Is
> this really too horrible:
>
> print('$user forgot to frobnicate the $file!\n',
> user=username, file=file.name, __to__=sys.stderr)
>
If I something stupid, I apologize; I have been swamped with
orientation stuff while this entire discussion has been going on and
so I am sure I have missed some of the finer details.
I like the way the above works, but ``print(username, "forgot to
frobicate the", file.name)`` just seems nicer for simple output. I do
agree that there is a need for simple and formatted versions of print
and that controlled output of numbers is important. And I also like
the $ formatting so I wished there was a way to take what Barry did
above but be able to do formatting, like ``${num:0.6f}`` or something
and have that be the formatting version and just have the default be a
call on str() for the substitution.
> > BTW we could use "from __future__ import printing" to disable the
> > recognition of 'print' as a keyword in a particular module -- this
> > would provide adequate future-proofing.
>
> +1
+1 from me as well.
-Brett
_______________________________________________
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
