Ethan Furman wrote:
Can you do those with _pydecimal? If performance were an issue anywhere I would expect to see it with number crunching.
No difference, probably because those methods look like they spend most of their time doing string manipulation: ``` $ export PYPERFSETUP='from _pydecimal import Decimal; from random import getrandbits; l = Decimal(bin(getrandbits(28))[2:]); r = Decimal(bin(getrandbits(28))[2:])' $ export PYPERFRUN='l.logical_and(r); l.logical_or(r); l.logical_xor(r)' $ ./python-master -m pyperf timeit -s "$PYPERFSETUP" "$PYPERFRUN" Mean +- std dev: 53.4 us +- 2.8 us $ ./python-zip-strict -m pyperf timeit -s "$PYPERFSETUP" "$PYPERFRUN" Mean +- std dev: 53.8 us +- 2.5 us $ ./python-zip-strict -m pyperf timeit -s "$PYPERFSETUP" "$PYPERFRUN" # This time, with strict=True in each method. Mean +- std dev: 53.6 us +- 3.0 us ``` I would encourage those who are still curious to pull the branch and experiment for themselves. Let's try to keep this a design discussion, since we've established that performance isn't a problem (and there is plenty of time for code review later).
Paul Moore and Chris Angelico have made good arguments in favor of an itertools addition which haven't been answered yet.
I don't consider their arguments particularly strong, but yeah, I was getting to those. I wanted to address your points first since you weren't part of the Ideas discussion! Paul Moore wrote:
... so it's another beast because (among other reasons) it lives in a separate namespace, and it should live in a separate namespace because it's another beast? That's circular logic.
Sorry, that's on me for trying to respond to two questions with one answer right before bed. Strike the namespace argument, then. The rest stands.
So importing zip_strict from itertools is an entirely reasonable way for users to enable the check, then.
Still agreed. But I think they would be *better* served by the proposed keyword argument. This whole sub-thread of discussion has left me very confused. Was anything unclear in the PEP's phrasing here? If so, I'd like to improve it. The original quote is: "The goal here is not just to provide a way to catch bugs, but to also make it easy (even tempting) for a user to enable the check whenever using `zip` at a call site with this property."
It's very easy to suggest bad ways of using a feature. That doesn't make the feature bad. You seem to be arguing that zip_strict is bad because people can misuse it.
Well, I addressed this "irrelevant" point because right out of the gate people started suggesting that they want a separate function *because* it makes shadowing easy. Which brings me to my next quote: Chris Angelico wrote:
I am most in favour of the separate-functions option *because* it makes shadowing easy. Not an anti-pattern at all.
I *really* hope this isn't how people use this (and I don't *think* it would be predominantly used this way), but at least it's clear to me now why you want it to be a separate function. It would still be quite simple to follow this pattern, though, with `functools.partial` or a custom wrapper.
Python is *deliberately* designed so that you can shadow things.
I wouldn't confuse "can" and "should" here. Python is deliberately designed to make *many* design patterns possible, good and bad.
And considering that "from __future__ import print_function" is an officially-sanctioned way to cause a semantic change to print, I don't think it's really that strong an argument.
Well that's a parser directive that is just there for 2/3 compatibility (I'm pretty sure - I've never used Python 2). I see it as very, very different from my `from pprint import pprint as print` headache that was quoted two levels up. Brandt