Marc-Andre Lemburg added the comment: On 16.11.2013 14:37, Nick Coghlan wrote: > > Such codecs can be represented (for 3.4) by simply not setting the attribute > and leaving the output types unspecified. We don't need that complexity for > the standard library, and the "not specified" escape hatch means complex > codecs will be no worse off than they are now. > > The elegance of Victor's proposal is that it doesn't lock us out of solving > the more complex cases later (where the codec's output type depends on the > input type) by permitting a tuple or dict mapping input types to output types > for "encodes_to" and "decodes_to", while still solving all of our immediate > problems. > > This is especially relevant since we can't effectively represent codec input > types until we have a ByteSequence ABC to cover the "bytes-like object" case, > so demanding that the general case be handled immediately is the same as > requesting that the feature be postponed completely to Python 3.5.
I don't agree. The mapping API is not much more complex than the single type combination proposal and it could well handle the case for which you'd have to add a ByteSequence ABC now to be able to define this single type combination using one ABC. Rather than adding the ABC now, you could simply add all relevant types to the mappings and then replace those mappings with an ABC in 3.5. BTW: I don't see a need to rush any of this. If more discussion is needed, then it's better to have a more complete proposal implemented in 3.5 than to try to do patchwork this late in the 3.4 release process. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue19619> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
