[Python-3000] print() parameters in py3k

[Brett Cannon]

On 11/19/06, Guido van Rossum <guido at python.org> wrote:
>
> On 11/19/06, Brett Cannon <brett at python.org> wrote:
> >
> >
> > On 11/19/06, Georg Brandl <g.brandl at gmx.net> wrote:
> > > Guido van Rossum wrote:
> > >
> > > > PEPs aren't only for difficult discussions. :-) They are also there
> > > > for reference and to record agreement. Referring to an email isn't
> > > > really a very good answer when someone asks (as happened here) "what
> > > > is the spec"?  A PEP may also discourage attempts to add more cruft,
> > > > and encourage someone with a few spare cycles to provide a patch so
> we
> > > > can put the whole thing behind it.
> > > >
> > > > BTW I forgot to mention that it shouldn't return anything.
> > > >
> > > > (So are you going to write that PEP? :-)
> > >
> > > It's in Subversion and numbered 3105, should be online with the next
> > > website update cycle.
> >
> > The only thing I would prefer is instead of 'end' have 'newline' and
> have
> > that be a boolean since I don't see a need to support different line
> > endings.  I realize the difference between ``end=''`` and
> ``newline=False``
> > is minimal beyond more typing, but for some reason my head just keeps
> > telling me I prefer the latter for clarity reasons.
> >
> > Otherwise +1 from me.
>
> Oh, but I *do* see a use case for other line endings. E.g. when
> writing a Windows file or a standards-compliant email from within
> Unix, end="\r\n" would be helpful. In practice it probably would be a
> variable set from a config option.


Right, I assumed it would always get set by some config option that was set
during compile.  But whatever, as I said it is not a big deal to me and I
can definitely be happy with the existing proposal.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20061120/f068d41c/attachment.htm