On Thu, Jan 16, 2014 at 11:13 AM, Neil Schemenauer <n...@arctrix.com> wrote: > A TypeError exception is what we want if the object does not support > bytes formatting. Some possible problems: > > - It could be hard to provide a helpful exception message since it > is generated inside the __format__ method rather than inside the > bytes.__mod__ method (in the case of a missing __ascii__ method). > The most common error will be using a str object and so we could > modify the __format__ method of str to provide a nice hint (use > encode()).
The various format functions could certainly intercept and wrap exceptions raised by __format__ methods. Once the core types were modified to expect bytes in format_spec, however, this may not be critical; __format__ methods which delegate would work as expected, str could certainly be clear about why it raised, and custom implementations would be handled per comments I'll make on your second point. Overall I suspect this is no worse than unhandled values in the format_spec are today. > - Is there some risk that an object will unwittingly implement a > __format__ method that unintentionally accepts a bytes argument? > That requires some investigation. Agreed. Some quick armchair calculations suggest to me that there are three likely outcomes: - Properly handle the type (perhaps written with the 2.x clause in mind) - Raise an exception internally (perhaps ValueError, such as from format(3, 'q')) - Mishandle and return a str (perhaps due to to if/else defaulting) The first and second outcome may well reflect what we want, and the third could easily be detected and turned into an exception by the format functions. I'm uncertain whether this reflects all the scenarios we would care about. _______________________________________________ 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
