Re: [Python-ideas] Repurpose `assert' into a general-purpose check

[Nathan Schneider]

On Mon, Nov 27, 2017 at 9:28 PM, Ivan Pozdeev via Python-ideas <
python-ideas@python.org> wrote:

> On 28.11.2017 5:19, Chris Angelico wrote:
>
> Actually, Python does have a way of disabling assertions (the -O
>> flag), so they should be treated the same way they are in C.
>> Assertions should not be used as shorthands for "if cond: raise Exc"
>> in the general case.
>>
> I'm claiming, and provided evidence, that there are no use cases for this
> in Python, so no-one (of any significance) will suffer when the disabling
> is cut out.
> In any case, we will probably do it with a __future__ statement for a
> transitional period.
>
>
I think it would be interesting to investigate how assert statements are
used in the wild. I can think of three kinds of uses:

1) Nonredundant checking: The assertion aims to be a concise way to raise
exceptions under certain conditions that might arise even presuming that
the code is internally correct. (For example, to check that the interface
with another piece of code is as expected, or to validate user input.)

This seems to be the use case the OP is targeting. It is probably not the
use envisioned by the designers of the assert statement. But perhaps assert
is frequently used in this way by people who don't know about the
optimization flag or assume their program won't be run with optimization.

2) Redundant checking: The assertion acts as a test of code correctness. If
the code is correct, it should have no effect; and presuming the code is
well-tested, it can thus be ignored with optimization turned on. But it is
useful as a sanity check of a tricky algorithm, and can help a reader to
understand the implementation. Is it often the case that optimizing these
assertions away brings significant performance savings?

3) Temporary debugging: I often write something like assert False,(x,y,z)
as a quick way to force the program to terminate and print some values.
Unlike print(x,y,z), this has the advantage of being blatantly obvious as
debugging code that does not belong in the final version.

It seems unlikely that one would purposefully turn on optimization in
conjunction with temporary assertions, so this use case may be irrelevant
to the proposal.

Best,
Nathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a sorting protocol dunder method?

[Nathan Schneider]

On Sun, Dec 3, 2017 at 6:06 PM, Chris Barker  wrote:

> In fact, it's striking me that there may well be classes that are defining
> the comparison magic methods not because they want the objects to "work"
> with the comparison operators, but because that want them to work with sort
> and min, and max, and...
>

An existence proof: in NLTK, an __lt__ method added purely to facilitate
consistent sorting (in doctests) of structured data objects for which
comparison operators do not really make conceptual sense:
https://github.com/nltk/nltk/pull/1902/files#diff-454368f06fd635b1e06c9bb6d65bd19bR689

Granted, calling min() and max() on collections of these objects would not
make conceptual sense either. Still, __sort_key__ would have been cleaner
than __lt__.

Cheers,
Nathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Nathan Schneider]

Care would have to be taken in the grammar to avoid syntactic ambiguity.
For example:

x = 1
def not(x):
...

if not - x: # Is this 'not' the keyword or the identifier? not (-x), or not
minus x?
...

Nathan

On Sun, May 13, 2018 at 2:20 PM Guido van Rossum  wrote:

> As anyone still following the inline assignment discussion knows, a
> problem with designing new syntax is that it's hard to introduce new
> keywords into the language, since all the nice words seem to be used as
> method names in popular packages. (E.g. we can't use 'where' because
> there's numpy.where
> ,
> and we can't use 'given' because it's used in Hypothesis
> .)
>
> The idea I had (not for the first time :-) is that in many syntactic
> positions we could just treat keywords as names, and that would free up
> these keywords.
>
> For example, we could allow keywords after 'def' and after a period, and
> then the following would become legal:
>
> class C:
> def and(self, other):
> return ...
>
> a = C()
> b = C()
> print(a.and(b))
>
> This does not create syntactic ambiguities because after 'def' and after a
> period the grammar *always* requires a NAME.
>
> There are other positions where we could perhaps allow this, e.g. in a
> decorator, immediately after '@' (the only keyword that's *syntactically*
> legal here is 'not', though I'm not sure it would ever be useful).
>
> Of course this would still not help for names of functions that might be
> imported directly (do people write 'from numpy import where'?). And it
> would probably cause certain typos be harder to diagnose.
>
> I should also mention that this was inspired from some messages where Tim
> Peters berated the fashion of using "reserved words", waxing nostalgically
> about the old days of Fortran (sorry, FORTRAN), which doesn't (didn't?)
> have reserved words at all (nor significant whitespace, apart from the
> "start in column 7" rule).
>
> Anyway, just throwing this out. Please tear it apart!
>
> --
> --Guido van Rossum (python.org/~guido)
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP: Dict addition and subtraction

[Nathan Schneider]

On Thu, Mar 21, 2019 at 9:17 AM Serhiy Storchaka 
wrote:

> 21.03.19 14:51, Chris Angelico пише:
> > ... then, in the interests of productive discussion, could you please
> > explain? What is it about dict addition that makes it harder to
> > understand than other addition?
>
> Currently the + operator has 2 meanings for builtin types (both are
> widely used), after adding it for dicts it will have 3 meanings.
>
> 3 > 2, is not?
>

It depends how abstractly you define the "meanings".

If you define + as "arithmetic addition" and "sequence concatenation", then
yes, there are 2. But novices have to learn that the same concatenation
operator applies to strings as well as lists/tuples. And when reading x +
y, it is probably relevant whether x and y are numbers, strings, or
sequence containers like lists.

The proposal would generalize "sequence concatenation" to something like
"asymmetric sequence/collection combination". (Asymmetric because d1 + d2
may not equal d2 + d1.) It seems a natural extension to me, though the |
alternative is also reasonable (interpreted as taking the OR of keys in the
two dicts; but unlike unioning two sets, the dict-merge operator would be
asymmetric). The third proposed alternative, <<, has no "baggage" from an
existing use as a combination operator, but at the same time it is a more
obscure choice.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 572: Assignment Expressions (post #4)

[Nathan Schneider]

On Wed, Apr 11, 2018 at 1:49 PM, Brendan Barnwell 
wrote:

> On 2018-04-11 05:23, Clint Hepner wrote:
>
>> I find the assignments make it difficult to pick out what the final
>> expression looks like.
>>
>
> I strongly agree with this, and for me I think this is enough to
> push me to -1 on the whole proposal.  For me the classic example case is
> still the quadratic formula type of thing:
>
> x1, x2 = (-b + sqrt(b**2 - 4*a*c))/2, (-b - sqrt(b**2 - 4*a*c))/2
>
> It just doesn't seem worth it to me to create an expression-level
> assignment unless it can make things like this not just less verbose but at
> the same time more readable.  I don't consider this more readable:
>
> x1, x2 = (-b + sqrt(D := b**2 - 4*a*c)))/2, (-b - sqrt(D))/2
> 
>

I'd probably write this as:

x1, x2 = [(-b + s*sqrt(b**2 - 4*a*c))/(2*a) for s in (1,-1)]

Agreed that the PEP doesn't really help for this use case, but I don't
think it has to. The main use cases in the PEP seem compelling enough to me.

Nathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Spelling of Assignment Expressions PEP 572 (was post #4)

[Nathan Schneider]

On Sat, Apr 14, 2018 at 11:54 PM, Chris Angelico  wrote:

> On Sun, Apr 15, 2018 at 1:08 PM, Nick Coghlan  wrote:
> > === Target first, 'from' keyword ===
> >
> > while (value from read_next_item()) is not None: # New
> > ...
> >
> > Pros:
> >
> >   * avoids the syntactic ambiguity of "as"
> >   * being target first provides an obvious distinction from the "as"
> keyword
> >   * typically reads nicely as pseudocode
> >   * "from" is already associated with a namebinding operation ("from
> > module import name")
> >
> > Cons:
> >
> >   * I'm sure we'll think of some more, but all I have so far is that
> > the association with name binding is relatively weak and would need to
> > be learned
> >
>
> Cons: Syntactic ambiguity with "raise exc from otherexc", probably not
> serious.
>
>
To me, "from" strongly suggests that an element is being obtained from a
container/collection of elements. This is how I conceptualize "from module
import name": "name" refers to an object INSIDE the module, not the module
itself. If I saw

if (match from pattern.search(data)) is not None:
...

I would guess that it is equivalent to

m = next(pattern.search(data))
if m is not None:
...

i.e. that the target is bound to the next item from an iterable (the
"container").

Cheers,
Nathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings

[Nathan Schneider]

On Sun, Mar 4, 2018 at 11:04 PM, Chris Angelico  wrote:

> On Mon, Mar 5, 2018 at 2:49 PM, Mike Miller 
> wrote:
> > Yes, thanks:
> >
> > [ f(y), g(y) for x, h(x) as y in things ]
> >
> >
> > Dyslexics untie!
>
> :)
>
> Hmm. The trouble here is that a 'for' loop is basically doing
> assignment. When you say "for x, h(x) as y in things", what Python
> does is (simplified):
>
> _it = iter(things)
> while not StopIteration:
> x, (h(x) as y) = next(_it)
> ... loop body ...
>
> So what you're asking for is something that doesn't behave like an
> assignment target, but just does its own assignment. Bear in mind,
> too, that "x = next(_it)" is very different from "x, = next(_it)";
> which one is "x, (h(x) as y) = next(_it)" more like?
>
>
If I understood Mike's proposal correctly it was to allow "," to mean
'given' in this context when followed by EXPRESSION "as" VARIABLE, rather
than its usual iterable-unpacking meaning.

But I think this would cause confusion. Suppose `things` contains
pair-tuples. Then you could have

[ f(y), g(y) for x1, x2, h(x1) as y in things ]

which makes it look like (x1, x2, h(x1)) go together rather than just (x1,
x2).

Nathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add regex pattern literal p""

[Nathan Schneider]

On Sat, Dec 29, 2018 at 12:30 AM Alexander Heger  wrote:

> for regular strings one can write
>
> "aaa" + "bbb"
>
> which also works for f-strings, r-strings, etc.; in regular expressions,
> there is, e.g., parameter counting and references to numbered matches.  How
> would that be dealt with in a compound p-string?  Either it would have to
> re-compiled or not, either way could lead to unexpected results
>
> p"(\d)\1" + p"(\s)\1"
>
> or
>
> p"^(\w)" + p"^(\d)"
>
> regular strings can be added, bu the results of p-string could not - well,
> their are not strings.
>

Isn't this a feature, not a bug, of encouraging literals to be specified as
patterns: addition of patterns would raise an error (as is currently the
case for addition of compiled patterns in the re and regex modules)?
Currently, I find it easiest to use r-strings for patterns and call
re.search() etc. without precompiling them, which means that I could
accidentally concatenate two patterns together that would silently produce
an unmatchable pattern. Using p-literals for most patterns would mean I
have to be explicit in the exceptional case where I do want to assemble a
pattern from multiple parts:

FIRSTNAME = p"[A-Z][-A-Za-z']+"
LASTNAME = p"[-A-Za-z']([-A-Za-z' ]+[-A-Za-z'])?"
FULLNAME = FIRSTNAME + p' ' + LASTNAME # error

FIRSTNAME = r"[A-Z][-A-Za-z']+"
LASTNAME = r"[-A-Za-z']([-A-Za-z' ]+[-A-Za-z'])?"
FULLNAME = re.compile(FIRSTNAME + ' ' + LASTNAME) # success

Another potential advantage is that an ill-formed p-literal (such as a
mismatched parenthesis) would be caught immediately, rather than when it is
first used. This could pay off, for example, if I am defining a data
structure with a bunch of regexes that would get used for different input.
(But there may be performance tradeoffs here.)


> This brings me to the point that
> the key difference is that f- and r- strings actually return strings,
> whereas p- string would return a different kind of object.
> That would seem certainly very confusing to novices - and also for the
> language standard as a whole.
>
>
The b prefix produces a bytes literal. Is a bytes object a kind of string,
more so than a regex pattern is? I could see an argument that bytes is a
particular encoding of sequential character data, whereas a regex pattern
represents a string *language*, i.e. an abstraction over string data.
But...this distinction starts to feel very theoretical rather than
practical. If novices are expected to read code with regular expressions in
it, why would they have trouble understanding that the "p" prefix means
"pattern"?

As someone who works with text a lot, I think there's a decent
practicality-beats-purity argument in favor of p-literals, which would make
regex operations more easily accessible and prevent patterns from being
mixed up with string data.

A potential downside, though, is that it will be tempting to introduce
flags as prefixes, too. Do we want to go down the road of pui"my
Unicode-compatible case-insensitive pattern"?

Nathan


> -Alexander
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: zip(x, y, z, strict=True)

[Nathan Schneider]

On Sat, Apr 25, 2020 at 10:41 AM Steven D'Aprano 
wrote:

> On Thu, Apr 23, 2020 at 09:10:16PM -0400, Nathan Schneider wrote:
>
> > How, for example, to collate lines from 3 potentially large files while
> > ensuring they match in length (without an external dependency)? The best
> I
> > can think of is rather ugly:
> >
> > with open('a.txt') as a, open('b.txt') as b, open('c.txt') as c:
> > for lineA, lineB, lineC in zip(a, b, c):
> > do_something_with(lineA, lineB, lineC)
> > assert next(a, None) is None
> > assert next(b, None) is None
> > assert next(c, None) is None
> >
> > Changing the zip() call to zip(aF, bF, cF, strict=True) would remove the
> > necessity of the asserts.
>
> I think that the "correct" (simplest, easiest, most obvious, most
> flexible) way is:
>
> with open('a.txt') as a, open('b.txt') as b, open('c.txt') as c:
> for lineA, lineB, lineC in zip_longest(a, b, c, fillvalue=''):
> do_something_with(lineA, lineB, lineC)
>
> and have `do_something_with` handle the empty string case, either by
> raising, or more likely, doing something sensible like treating it as a
> blank line rather than dying with an exception.
>
>
This is the sentinel pattern with zip_longest() rather than next(). Sure,
it works, but I'm not sure it's the most obvious—conceptually zip_longest()
is saying "I want to have as many items as the max of the iterables", but
then the loop short-circuits if the fillvalue is used. More natural to say
"I expect these iterables to have the same length from the beginning" (if
that is what the application demands).


> Especially if the files differ in how many newlines they end with. E.g.
> file a.txt and c.txt end with a newline, but b.txt ends without one, or
> ends with an extra blank line at the end.
>
>
Well, this depends on the application and the assumptions about where the
files come from.

I can see that zip_longest() will technically work with the sentinel
pattern. If there is consensus that it should be a builtin, I might start
using this instead of zip() with separate checks. But to enforce
length-matching, it still requires an extra check, plus a decision about
what the sentinel value should be (for direct file reading '' is fine, but
not necessarily for other iterables like collections or file-loading
wrappers). IOW, the pattern has some conceptual and code overhead as a
solution to "make sure the number of items matches".

Given that length-matching is a need that many of us frequently encounter,
adding strict=True to zip() seems like a very useful and intuitive option
to have, without breaking any existing code.

Nathan
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JFEHLFMZ4ENT4DOCELORSA5QRYQ3SSM5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: zip(x, y, z, strict=True)

[Nathan Schneider]

On Thu, Apr 23, 2020 at 3:50 PM Eric Fahlgren 
wrote:

> On Wed, Apr 22, 2020 at 12:23 PM David Mertz  wrote:
>
>> On Wed, Apr 22, 2020, 4:24 AM Antoine Pitrou
>>
>>> But, as far as I'm concerned, the number of times where I took
>>> advantage of zip()'s current acceptance of heteregenously-sized inputs
>>> is extremely small.  In most of my uses of zip(), a size difference
>>> would have been a logic error that deserves noticing and fixing.
>>>
>>
>> Your experience is very different from mine.
>>
>
> I'm in Antoine's camp on this one.  A lot of our work is data analysis,
> where we get for example simulation results as X, Y, Z components then zip
> them up into coordinate triples, so any mismatch is a bug.  Having
> zip_equal as a first-class function would replace zip in easily 90% of our
> use cases, but it needs to be fast as we often do this sort of thing in an
> inner loop...
>

+1

I write a lot of standalone data-munging scripts, and expecting zipped
inputs to have equal length is a common pattern.

How, for example, to collate lines from 3 potentially large files while
ensuring they match in length (without an external dependency)? The best I
can think of is rather ugly:

with open('a.txt') as a, open('b.txt') as b, open('c.txt') as c:
for lineA, lineB, lineC in zip(a, b, c):
do_something_with(lineA, lineB, lineC)
assert next(a, None) is None
assert next(b, None) is None
assert next(c, None) is None

Changing the zip() call to zip(aF, bF, cF, strict=True) would remove the
necessity of the asserts. Moreover, the concept of strict zip or zip_equal
should be intuitive to beginners, whereas my solution of next() with a
sentinel is not. (Oh, an alternative would be checking if a.readline(),
b.readline(), and c.readline() are nonempty, but that's not much better and
wouldn't generalize to non-file iterators.)

Nathan
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WZY55AKLDLGO3GSHSNALNFUV45JBJHSJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

[Nathan Schneider]

On Sun, May 17, 2020 at 6:14 AM Rhodri James  wrote:

> On 16/05/2020 17:14, Guido van Rossum wrote:
> > On Sat, May 16, 2020 at 1:26 AM Steven D'Aprano
> wrote:
> >
> >>> * zip(strict=True)   +1
> >>> * zip(mode='strict') -0
> >>> * itertools.zip_strict() -0.5
> >>> * zip.strict()   -1  (but really, I'd like to make this -1e10)
> >> I spent a significant amount of time and mental energy explaining in
> >> detail why a boolean flag is a poor API and is objectively the wrong
> >> interface here. This is not just a matter of personal taste: there are
> >> reasons why a flag is wrong here.
> >>
> > Clearly it is not the objective truth, otherwise you would have an easier
> > way convincing everyone.:-)
>
> OK, let's put some numbers on this.  We only have 9 votes in, but aside
> from Brandt (whose position is fairly obvious from the PEP) that
> includes most of the people who have expressed strong opinions one way
> or another.  Ignoring the nuances of +/-0, we end up with:
>
> itertools.zip_strict(): +5.5
> zip(strict=True):   +1
> zip.strict():   -1.9
> zip(mode='strict'): -4
>
> (I bet Steven is wishing he hadn't been so generous to the "strict=True"
> option now :-)
>
> Now I'm not fool enough to mistake a public vote for an objective truth
> (::looks pointedly around world politics::) but there are some
> interesting conclusions here.
>
> 1) Nobody (aside from Steven) wants a "mode" keyword.  I suspect this is
> because both of the two main camps (zip(strict=True) and zip_strict())
> have solid reasons against it; for the first, it's an unnecessary
> distraction, and for the second the existence of zip_longest() argues
> against it.
>
> 2) People don't hate zip.strict() as much as I had expected.
>
> 3) The PEP needs to come up with an actual argument against
> itertools.zip_strict().  The current dismissal ain't going to cut it.
>
>
Let me attempt a metaphor, which won't be perfect but may help:

The safety one gets from strictness is a bit like driving a car wearing a
seat belt. It is not fundamentally different from driving a car without a
seat belt, and in most cases you hope the seat belt will not come into
play. But it is a precaution that is worth taking in *most* circumstances
(not all, e.g. for infants a standard seat belt won't work).

The built-in approaches (whether spelled as zip(strict=True), or
zip.strict(), or a new zip_strict() builtin) make it really easy for
everybody to take the safety precaution where it is appropriate. By
contrast, putting it in itertools where it has to be imported is like
requiring someone to rent seat belts in order to use them in their car.
Some safety-conscious folks will go to the trouble; others won't.

itertools.zip_longest() is sort of a power tool for specialized
situations—in our analogy, say, a pickup truck that has to be rented. Yes,
with some work it *can* be used to emulate strict-zip, but most people
won't think of it that way; they will think of it as something you only
need in special situations.

Is there some logic to the objection that it is weird to have two forms of
zip (or one form with two variants) that are built in, and a third that is
in itertools? Sure. But this seems to me a clear case of practicality beats
purity. As an extremely common use case of zip (for many people), it will
be most useful if it is built in.

Nathan


>
> --
> Rhodri James *-* Kynesim Ltd
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/N4QLALMOLUWHYFSLKEONJ7UYF2YBQY4R/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3IPR5FWN7CZUETIPCSACXXOK4BK6TNRF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

[Nathan Schneider]

On Sun, May 17, 2020 at 1:32 PM David Mertz  wrote:

> On Sun, May 17, 2020 at 12:22 PM Nathan Schneider 
> wrote:
>
>> Let me attempt a metaphor, which won't be perfect but may help:
>>
>> The safety one gets from strictness is a bit like driving a car wearing a
>> seat belt. It is not fundamentally different from driving a car without a
>> seat belt, and in most cases you hope the seat belt will not come into
>> play. But it is a precaution that is worth taking in *most* circumstances
>> (not all, e.g. for infants a standard seat belt won't work).
>>
>
> That's a really terrible analogy. :-(
>
> I never drive without a seat belt.  And a never want the seat belt to
> actually matter, of course.  Everyone who want a zip_strict behavior
> (including me) wants to be able either to catch the exception explicitly or
> to have the program fail-fast/fail-hard because of it.
>
> In contrast, as I've said, more than half of the times that *I* use zip()
> it would be BROKEN by using zip_strict() instead (or zip(..., strict=True),
> or whichever spelling).  Raising an exception for something I want to
> succeed, and I want to work exactly as it does (e.g. leave some iterators
> unconsumed) is not a "harmless safety precaution".
>
> If you want a better metaphor: Some door handles include locks, others do
> not.  "Strict" ones have locks.  So yes, it's possible to leave the lock in
> the unlocked position, and then it functions pretty much the same as one
> without a lock.  But likewise, it's possible to leave the door in the
> locked position when you don't have the key on you, and you face a
> significant inconvenience that serves no purpose.
>
> I have some doors with locks, and some other doors without locks.  I have
> both for a good reason, but the reasons are different, and depend on
> various things like whether a particular room is private or contains
> valuables.  In truth though, I don't lock my outside doors because I live
> in a community of "consenting adults" (occasionally I do lock the bathroom
> door for privacy, for a short while... no-locks is definitely strongly my
> default mode, as is no-strict when I zip).
>
>

Good, I think we're getting to the crux of the usability debate.

For some of us, strictness is a property that users often want when they
use zip(), whether they are properly enforcing it or not—so giving them a
really easy way to opt into it would help avoid bugs. (Personally, I cannot
remember the last time I actually wanted non-strict zip.)

I think David is saying that he more often wants non-strict zip, and it
would be tempting and dangerous to make strict-zip too easy to use for
those who aren't thinking carefully about their code, so it would be better
to bury strict-zip in itertools for the power users who really know they
need it. (Is that a fair summary?)

As long as we are not changing the default behavior of zip(), I don't
anticipate a ton of users using strict-zip unthinkingly—I would guess the
risk of uncaught bugs with the status quo is much, much higher. Is there a
precedent where a new non-default option was introduced and incorrect use
of it became widespread?

Nathan
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ATK5DP3YP7ZL55C2Z3I2J5ND2JZFJ6RE/
Code of Conduct: http://python.org/psf/codeofconduct/