Hello, On Tue, 31 Mar 2020 18:09:59 +0900 "Stephen J. Turnbull" <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote: []
[3] Paul's "exact alias of .write() method", which can be done in 1 line, fails because .write() doesn't return self. Thanks, Serhiy. In
I stand corrected gentlemen, thanks for catching that. It's a poorman's pep, not a real pep after all. A real pep wouldn't use ambiguous phrases like that, but something like "__iadd__ method, with the same semantics as existing .write() method, bur returning self". In terms of C implementation, that's one line difference, in pseudocode: - return write_method(self, ...) + write_method(self, ...) + return self In terms of machine code, that would be +1 instruction, I guess such a minor difference made me discount it and use ambiguous term "alias". For reference, the implementation for Pycopy: https://github.com/pfalcon/pycopy/commit/4b149fb8a4fb18e954ba7113d1495ccf822... (such a big patch because expectedly, Pycopy optimizes operators vs general methods, and as there was no operators defined for StringIO before, it takes whole 14 lines of boilerplate to add).
the stdlib we might even want a check for "at end of buffer" (.write() can overwrite Unicode scalars anywhere in the buffer). That's definitely overengineering for a user, but in the stdlib, dunno.
Per my idea, __iadd__ would be exact equivalent of .write in behavior (a complexity-busting measure), but specific implementations of course can add extra checks if they just can't do otherwise. (Reminds me of PEP 616 discussion, where there was mentioning of raising ValueError on empty prefix, even though it all started as being an equivalent of if s.startswith(prefix): s = s[len(prefix):] And str.startswith() doesn't throw no ValueError on neither str.startswith("") or str.startswith(("foo", "")). It seems that we just can't pass by a chance to add another corner case to explain away from the already existing behavior, all with a good intention of policing our users, for they can't handle it themselves). -- Best regards, Paul mailto:pmiscml@gmail.com