Return self on calls to update

[reaperhulk]

From the mailing list:

Finally, if I may, I have one final suggestion. It would be convenient to 
have the update() function return self (the signer object). That way, it 
would be possible to write something like:

        signature = key.signer(PKCS1v15(), SHA1()).update(data).finalize()

instead of:

        signer = self._key.signer(PKCS1v15(), SHA1())
        signer.update(data)
        signature = signer.finalize()

in cases where you had only a single block of data to pass in.

[alex]

I'm strongly -1 on this, returning self on a mutating operation is just
confusing, and is not something replicated anywhere else in Pythonic APIs.

On Sat, Jul 26, 2014 at 5:09 PM, Paul Kehrer notifications@github.com
wrote:

From the mailing list:

Finally, if I may, I have one final suggestion. It would be convenient to
have the update() function return self (the signer object). That way, it
would be possible to write something like:

    signature = key.signer(PKCS1v15(), SHA1()).update(data).finalize()

instead of:

    signer = self._key.signer(PKCS1v15(), SHA1())
    signer.update(data)
    signature = signer.finalize()

in cases where you had only a single block of data to pass in.

—
Reply to this email directly or view it on GitHub
#1287.

"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084

[ronf]

I was the one who made the original suggestion, but after thinking about it a bit more I'd like to propose something different. The asymmetric key classes could have sign() and verify() functions in addition to signer() and verifier(). They would take the same arguments as signer/verifier plus an additional "data" argument and would do the equivalent of signer/verifier, update, and finalize all in one call (returning the signature). In cases where you needed to sign or verify a single block of data, this would be the preferred API. In cases where you wanted to feed the data in as multiple blocks, the existing API would be used.

[michael-hart]

I feel like this would simplify a commonly used function, and that many applications only expect a single large code block, so it makes sense to me that standalone sign/verify methods would be useful. I'm happy to work on this if others agree.

[alex]

We've got a lot of APIs that are exclusively streaming right now (symmetric
encryption, hashes, HMAC/CMAC), we should think if we want to do this
across the board.

On Fri, Sep 26, 2014 at 5:54 PM, michael-hart notifications@github.com
wrote:

I feel like this would simplify a commonly used function, and that many
applications only expect a single large code block, so it makes sense to me
that standalone sign/verify methods would be useful. I'm happy to work on
this if others agree.

—
Reply to this email directly or view it on GitHub
#1287 (comment).

"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084

[reaperhulk]

Closing this in favor of the new issue that captures the current proposal.