RetroSearch Browse

Sat Jan 11 00:02:24 CET 2014 · https://mail.python.org/pipermail/python-dev/2014-January/131168.html

On Fri, 10 Jan 2014 14:58:15 -0800
Ethan Furman <ethan at stoneleaf.us> wrote:
> On 01/10/2014 02:42 PM, Antoine Pitrou wrote:
> > On Fri, 10 Jan 2014 17:33:57 -0500
> > "Eric V. Smith" <eric at trueblade.com> wrote:
> >> On 1/10/2014 5:29 PM, Antoine Pitrou wrote:
> >>> On Fri, 10 Jan 2014 12:56:19 -0500
> >>> "Eric V. Smith" <eric at trueblade.com> wrote:
> >>>>
> >>>> I agree. I don't see any reason to exclude int and float. See Guido's
> >>>> messages http://bugs.python.org/issue3982#msg180423 and
> >>>> http://bugs.python.org/issue3982#msg180430 for some justification and
> >>>> discussion.
> >>>
> >>> If you are representing int and float, you're really formatting a text
> >>> message, not bytes. Basically if you allow the formatting of int and
> >>> float instances, there's no reason not to allow the formatting of
> >>> arbitrary objects through __str__. It doesn't make sense to
> >>> special-case those two types and nothing else.
> >>
> >> It might not for .format(), but I'm not convinced. But for %-formatting,
> >> str is already special-cased for these types.
> >
> > That's not what I'm saying. str.__mod__ is able to represent all kinds
> > of types through %s and calling __str__. It doesn't make sense for
> > bytes.__mod__ to only support int and float. Why only them?
> 
> Because embedding the ASCII equivalent of ints and floats in byte streams
> is a common operation?

Again, if you're representing "ASCII", you're representing text and
should use a str object.

Regards

Antoine.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2014-January/131168.html below:

[Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5