fixes #22: throw a TypeError when padding is not an Object

[michaelficarra]

Fixes #22. /cc @bakkot

[bakkot]

Probably the appropriate place to perform this check is immediately after reading it? We generally validate early, when doing validation.

Either this is an API which behaves like most existing APIs in allowing strings as iterables, or is a new API which rejects strings as iterables. If it's allowing them, it should allow them for all of iterables, paddingOption, and the iterators being zipped. If it's rejecting them, it should reject them for all three.

Prior to this PR they were rejected for iterables but allowed for paddingOption and the iterators being zipped. After this PR they are rejected for iterables and paddingOption but still allowed in the iterators being zipped.

[michaelficarra]

I'm not sure whether we want to permit iterables to yield strings. I think I'll open a PR and run it by committee.

[bakkot]

Approved but I still think the appropriate place to perform this check is immediately after reading _paddingOption_.

[michaelficarra]

I can do that.

[ljharb]

if longest isn't true, shouldn't this still validate paddingOption?

[michaelficarra]

nah, we don't need to validate if we're not going to read it

[ljharb]

In general (and in Temporal) I think we've been optimistically reading and validating every option whether they're used or not, to minimize depending on observable lookups later.

[bakkot]

If there's an option which is only relevant to one mode, it seems wasteful to read that option in other modes.

[michaelficarra]

to minimize depending on observable lookups later

there won't be a later lookup because it's guaranteed to not be needed