On Thu, Jan 16, 2014 at 11:33 AM, Michael Urman <mur...@gmail.com> wrote:
> On Thu, Jan 16, 2014 at 8:45 AM, Brett Cannon <br...@python.org> wrote: > > Fine, if you're worried about bytes.format() overstepping by implicitly > > calling str.encode() on the return value of __format__() then you will > need > > __bytes__format__() to get equivalent support. > > Could we just re-use PEP-3101's note (easily updated for Python 3): > > Note for Python 2.x: The 'format_spec' argument will be either > a string object or a unicode object, depending on the type of the > original format string. The __format__ method should test the type > of the specifiers parameter to determine whether to return a string or > unicode object. It is the responsibility of the __format__ method > to return an object of the proper type. > > If __format__ receives a format_spec of type bytes, it should return > bytes. For such cases on objects that cannot support bytes (i.e. for > str), it can raise. This appears to avoid the need for additional > methods. (As does Nick's proposal of leaving it out for now.) > That's a very good catch, Michael! I think that makes sense if there is precedence. Unfortunately that bit from the PEP never made it into the documentation so I'm not sure if there is a backwards-compatibility worry.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
