[Python-3000] print() parameters in py3k

[Guido van Rossum]

Let me just say -1 on this idea so we can close the thread. None of
that convinces me. I don't think that print(a, b) failing when b has a
certain unexpected type can be considered consistent. The
ElementBuilder example doesn't apply because  it takes very limited
argument types (string, dict, E; everything else raises an exception).
print is carefully designed to be able to print *anything*. Not being
able to print a format object strikes me as wrong. Apart from that,
I'm not sure that having formats be a separate type is a good idea
either; but even if it were a good idea, the rest of the reason for
the -1 still stands.

--Guido

On 11/23/06, Fredrik Lundh <fredrik at pythonware.com> wrote:
> Guido van Rossum wrote:
>
> > Hm. While not as obviously from a different universe as Barry's
> > proposal, this still pretty weird, probably at least from a different
> > planet (much farther than Iceland anyway :-)
>
> it's inspired by
>
>     http://online.effbot.org/2006_11_01_archive.htm#et-builder
>
> which owes a lot to
>
>     http://www.tothink.com/python/ElementBuilder/
>
> which is inspired by
>
>     http://effbot.org/zone/idea-xml-literal.htm
>
> which you found "interesting in a futuristic kind of way" at the time ;-),
> and which is probably influenced by
>
>     http://okmij.org/ftp/Scheme/SXML.html
>
> whether or not I was aware of that at the time, and google gives me
> around 150,000 hits for "John McCarthy ufo", so I guess that settles
> it.
>
> > Treating the first argument differently based on its being of a specific
> > type doesn't sound right to me; what if you are handed an object x
> > and you decide to print it using print(x), but surreptitiously (or by
> > mistake) they hand you a format object?
>
> it'll fail in some way (exactly how remains to be defined), but at least it'll fail
> more consistently and reliably than if you accidentally do
>
>     printf(value)
>
> on a string value (see Adam's post at the top of this subthread).  a failure caused
> by the wrong type is easier to handle than a failure caused by using the right type,
> but the wrong value.
>
> (functions that needs to print arbitrary objects in a safe fashion cannot really use
> a bare "print" anyway, of course.)
>
> </F>
>
>
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)