On Tue, May 05, 2020 at 05:26:02PM +0100, Henk-Jaap Wagenaar wrote:
This is a straw man in regards to backwards compatibility. This particular (sub)thread is about whether if this zip-is-strict either as a separate name or a Boolean flag or some other flag of zip should be a built-in or be in e.g. itertools.
Please don't misuse "strawman" in that fashion. A strawman argument is a logical fallacy where you attack a weaker position your opponent didn't make in order to make your own position stronger. That's not what Chris did, and frankly accusing him of strawmanning is a form of "poisoning the well". What Chris did was to propose a counterfactual to express his opinion on this proposal. To paraphrase: "If this were true (we were designing zip from scratch for the first time) then I would agree with the proposal, but since we aren't, I disagree because of these reasons." That is a perfectly legitimate position to take. "If we weren't in lockdown, I would take you out for dinner at a restaurant, but since we are in quarantine, I don't think we should go out." Personally, I don't think Chris' backwards-compatibility argument is strong. Technically adding a new keyword argument to a function is backwards-incompatible, but we normally exclude that sort of change. Who writes this? # This behaviour will be changed by the proposed new parameter. zip('', strict=1) # Raise a type error. So I think the *backwards incompatibility* argument is weak in that regard. But maybe Chris has got a different perspective on this that I haven't thought of. [Chris]
Should they? I'm not sure how well-supported this actually is. If you hand-craft an AST and then compile it, is it supposed to catch every possible malformation?
I would expect that the ast library should accept anything which could come from legal Python, and nothing that doesn't. -- Steven