<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 17 April 2016 at 18:03, Stephen J. Turnbull <span dir="ltr"><<a href="mailto:stephen@xemacs.org" target="_blank">stephen@xemacs.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Nick Coghlan writes:</span><span class=""><br>
 > and instead throw exceptions in those cases.<br>
<br>
</span>Then I don't understand the current design of fsdecode and fsencode.<br>
Shouldn't they raise on str and bytes respectively, rather than<br>
passing them through?  In general, I would expect that something<br>
that's explicitly intended to be polymorphic would be documented as<br>
such, and the *caller* would be responsible for type-checking and<br>
raising if it got the wrong thing.<br></blockquote><div><br></div></div>I was initially surprised myself, but then realised it made sense for their intended use cases - if almost every usage looks like "obj if isinstance(obj, str) else os.fsdecode(obj)", then there ends up being a strong pragmatic case for pushing the pass-through down into the underlying function to reduce code duplication and rejecting str input in the cases where it isn't supported. By contrast, there are lots of places where "obj.decode()" gets called without a pass-through for objects that are already decoded.<br><br></div><div class="gmail_extra">Cheers,<br></div><div class="gmail_extra">Nick.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>