This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author r.david.murray
Recipients PedanticHacker, The Compiler, r.david.murray, serhiy.storchaka
Date 2015-03-26.14:56:55
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1427381815.98.0.143267465466.issue23780@psf.upfronthosting.co.za>
In-reply-to
Content
Python's philosophy is one of duck typing, which means that in general we just let the functions fail with whatever error they produce when the in put datatype is wrong.  The error message in this case is fairly straightforward: you passed a list and it says that that data type doesn't work.  The linux case is a bit more problematic in that it *doesn't* produce an error for invalid input.  The problem there is that we can't raise an error if there's only one argument for backward compatibility reasons: there almost certainly exists code that depends on single argument path returning the argument.  

In theory there shouldn't be code that depends on that single argument being an incorrect data type, but it would still only be something we'd consider changing in a feature release.

I'm not sure it is worth fixing, frankly, but I've attached a patch we could consider applying to 3.5.  (aside: the isinstance check in _get_sep looks like a bug report waiting to happen...it will do the wrong thing if passed a bytearray or memoryview...)

There may be others who will advocate for a stricter type check or a try/except with a "better" error message...I'd be OK with the better error message as long as it doesn't break the duck typing rule.
History
Date User Action Args
2015-03-26 14:56:56r.david.murraysetrecipients: + r.david.murray, serhiy.storchaka, The Compiler, PedanticHacker
2015-03-26 14:56:55r.david.murraysetmessageid: <1427381815.98.0.143267465466.issue23780@psf.upfronthosting.co.za>
2015-03-26 14:56:55r.david.murraylinkissue23780 messages
2015-03-26 14:56:55r.david.murraycreate