[Python-ideas] Re: Optional keyword arguments
On Sun, May 17, 2020 at 07:17:00PM -, James Lu wrote: > The Zen of Python states "there shouldn't be two ways to do the same thing." No it doesn't. -- Steven ___ 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/NJ55KZBJGTPSLCLHIV2LPPT4ONJVJEZ5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Ensuring asserts are always on in a file
On Sun, May 17, 2020 at 09:04:50PM -, Alex Hall wrote: > Some people (like myself, or the coworkers of [this > person](https://mail.python.org/archives/list/python-ideas@python.org/thread/PLXOXKACKGXN4ZKISDVXLKMFIETWTF63/)) > > just like to use asserts as a convenient way to check things. We don't > want asserts to ever be turned off. That's not your choice. The choice to turn assertions off belongs to the person running the code, not you. If you are not prepared for the user to turn assertions off, then your code is buggy. > Maybe there could be some kind of > compiler directive which means "in this file, even with -O, keep the > asserts". Maybe the line `assert __debug__`? Indeed this feature already exists. It's written as: if condition: raise Exception and you can control when it is enabled or disabled, the end user can't change that. Even better, you can use the correct, meaningful exception instead of using the wrong, misleading exception. `assert` is for assertions, not error checking. If you don't want the semantics of an assertion, then don't use `assert`. -- Steven ___ 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/LLD3SBBMQQHY7PQPZHN2JRCIH3UDIJTH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
On 2020-05-18 02:25, Greg Ewing wrote:
On 18/05/20 1:59 am, Paul Sokolovsky wrote:
But even
{(int): str} is a better type annotation for a function than
Callable[[int], str].
I don't agree -- it looks more like some kind of dict type, and
would be better reserved for that purpose.
And if we e.g. talk about making "->" a special operator which would
allow it to appear in other contexts
Or maybe we could leverage the new walrus operator and write
str := (int)
It would be closer to the existing annotation if we could write:
[int] -> str
___
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/77OWDBQPQKDDQ3CGHUC4PY6ODI3LUBY3/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
On 18/05/20 1:59 am, Paul Sokolovsky wrote:
But even
{(int): str} is a better type annotation for a function than
Callable[[int], str].
I don't agree -- it looks more like some kind of dict type, and
would be better reserved for that purpose.
And if we e.g. talk about making "->" a special operator which would
allow it to appear in other contexts
Or maybe we could leverage the new walrus operator and write
str := (int)
--
Greg
___
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/ZWUTXNFIA5RRIBJQM2BDGAKMJZ33NIJG/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip
On Sun, 17 May 2020 at 07:10, Christopher Barker wrote: > > > PS. Why wasn't a new builtin zip_strict() on the menu? I think I would have > > given it at least +0.5, because of this rule of thumb. > > I would think that if zip_strict() added as a builtin, then zip_longest() > should too. > > And the fact that zip_longest was not added as a builtin made me think that > it was a non-starter. I think that's just because zip_longest isn't a very compelling alternative to zip. I've known of it for a long time and I don't remember *ever* using it. If builtins had zip_shortest (i.e. current zip), zip_strict and zip_longest then I think I would use zip_strict 95% of the time, zip_shortest 5% of the time and zip_longest 0% of the time. -- Oscar ___ 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/AIP52CKLKOPUOZAOSBFO2SWKJZGKYLHE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Ensuring asserts are always on in a file
On Mon, May 18, 2020 at 8:04 AM Richard Damon wrote:
> If you really what what you describe, add the following to your code:
>
> if not __debug__:
>
> raise AssertionError, "Please don't disable assertions"
>
> (This won't enable the assertions, but will let the user know that you
> need them enabled)
>
As a bonus that also asserts that you're running an ancient version of
Python probably not what you want :)
if not __debug__:
raise AssertionError("Assertions are required for this module,
because it is broken.")
ChrisA
___
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/TF5LWWK7OGGRHQVSUQ5RQAEQZ2YWC7CL/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Ensuring asserts are always on in a file
On 5/17/20 5:04 PM, Alex Hall wrote: > Some people (like myself, or the coworkers of [this > person](https://mail.python.org/archives/list/python-ideas@python.org/thread/PLXOXKACKGXN4ZKISDVXLKMFIETWTF63/)) > just like to use asserts as a convenient way to check things. We don't want > asserts to ever be turned off. Maybe there could be some kind of compiler > directive which means "in this file, even with -O, keep the asserts". Maybe > the line `assert __debug__`? > My answer to that is 'Your doing int wrong', that is like asking for an if statement to not bother checking some of its conditionl. the assert operation has, like forever, been a debugging aid to say this condition should ALWAYS/NEVER occur, check for it in Debug Builds, but not for production builds. In some cases (some languages) the compiler might even optimize to code based on the knowledge that the condition, even in code executed before the condition (if it can be sure the assert will be reached). To quote the documentation: Assertions should *not* be used to test for failure cases that can occur because of bad user input or operating system/environment failures, such as a file not being found. Instead, you should raise an exception, or print an error message, or whatever is appropriate. One important reason why assertions should only be used for self-tests of the program is that assertions can be disabled at compile time. Basically the statement assert cond is the same as if __debug__ and not cond: raise AssertionError If you really what what you describe, add the following to your code: if not __debug__: raise AssertionError, "Please don't disable assertions" (This won't enable the assertions, but will let the user know that you need them enabled) -- Richard Damon ___ 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/JO5EBPHA5IZMG37KNVXMYT5NE2Y4LHIM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Ensuring asserts are always on in a file
Some people (like myself, or the coworkers of [this person](https://mail.python.org/archives/list/python-ideas@python.org/thread/PLXOXKACKGXN4ZKISDVXLKMFIETWTF63/)) just like to use asserts as a convenient way to check things. We don't want asserts to ever be turned off. Maybe there could be some kind of compiler directive which means "in this file, even with -O, keep the asserts". Maybe the line `assert __debug__`? ___ 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/TQKXSCMH7JYCHAE3XN7MCSWVA2UJ4R5G/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip
On Sun, May 17, 2020 at 10:12 PM Ethan Furman wrote: > On 05/17/2020 10:18 AM, Alex Hall wrote: > > > But it's good that we have the assert statement, because it makes it > easy to write safe code and so people are encouraged to do so. > > I could not disagree more strongly with this. Every time I have seen > assert used it was in such a way that the program could easily silently > produce erroneous results or fail far from the error if asserts were turned > off. > I assume you mean that you'd like the condition in the assert to always be checked (-O or not), not that the asserts actually change behaviour. But then, isn't that how all asserts are? The only way turning off an assert can't be a problem is if you're sure the condition is always true, and then it's not needed at all. Anyway, I don't think anyone is arguing that strict zip should be turned off by -O, so for a closer analogy, let's similarly imagine that asserts can't be turned off, and they're just a convenient way to check correctness. In that case assert would probably just be a function `assert(condition, message)` since there wouldn't be a need for a special syntax. We'd be faced with the same choice - builtin or standard library import? Again, I think it'd be best as a builtin to make checking for correctness as frictionless as possible. Actually in that situation many would argue not to include such a feature in the language at all, saying it's easy enough to use an if statement or define your own function. But that would again discourage people when they're feeling lazy and they'd just leave out the check entirely. Back to the real world. Consider the problem I think you're talking about: someone has used assert when you think they should have used if+raise to make sure the check is always there. Sometimes this is because they don't know asserts might be turned off, but there are other times when they know and just don't care enough. I know that's been me sometimes. That's evidence that programmers are lazy and will often choose the *slightly* more convenient option over safety. Also note that no one (AFAIK) solves this problem by writing their own function assert_(condition, message). It would be trivial, but writing it and importing it doesn't feel like it's worth the effort. ___ 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/2QUTXTPNUMUCMGDNQ6ILR2BT72PJ4U7T/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip
On 05/17/2020 10:18 AM, Alex Hall wrote: But it's good that we have the assert statement, because it makes it easy to write safe code and so people are encouraged to do so. I could not disagree more strongly with this. Every time I have seen assert used it was in such a way that the program could easily silently produce erroneous results or fail far from the error if asserts were turned off. -- ~Ethan~ ___ 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/SKVOX2A5MNN3V7IGEUAYC56BSXB2TCXQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Optional keyword arguments
Many a python programmer have tired to see code written like:
def bar(a1, a2, options=None):
if options is None:
options = {}
... # rest of function
syntax if argument is not passed, evaluate {} and store to options
def foo(options:={}): pass
syntax if argument is not passed or is None, evaluate {} and store to options*
def foo(options?={}): pass
The Zen of Python states "there shouldn't be two ways to do the same thing."
Thus, only one of ":=" or "?=" should be adopted. They should be evalued on:
- Which encourages writing better code?
- Which catches mistakes easier?
Do we want to encourage callers to pass None to indicate default arguments?
spam = { data: True } if arg else None
bar(a1, a2, param=spam)
versus
bar(a1, a2, { data: True }) if arg else bar(a1, a2)
versus
_ = foo.curry(a1, a2)
_({data: True}) if arg else _(a1, a2)
Since Python is a strongly typed language, it seems more consistent to me that
this code should throw an error:
def getoptions():
... # code to get options
# whoops! missing return statement
#return os.environ
foo(a1, a2, param=getoptions())
:= should be adopted because it catches mistakes more quickly.
On the other hand, ?= replaces the "if kwarg is not None: kwarg = ..." idiom.
(I propose adopting only ":=". I show "?=" as a strawman.)
___
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/MILIX6HSW3PRUNWWP6BN2G2D7PXYFZJ7/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip
On Sun, May 17, 2020 at 2:09 PM Nathan Schneider wrote: > 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. >> >> 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?) > The API matter is really orthogonal to this. My point here is that Nathan and some other discussants are operating under the assumption that: "Everyone really wants strict-zip but they just haven't had a way to express it conveniently. They all assume their iterables are the same length already, so this just adds a check." I disagree strongly with that assumption. I think that the actual majority of my uses of zip are non-strict. Admittedly, I have not scanned my code to count that; for that matter, most of the code I have written is no longer accessible to me, being written for companies I no longer work for (and not open source). But whatever the actual percentages might be, I COMMONLY want a non-strict zip by actual specific intention, not because I've made a wrong assumption about the nature of the iteratables I use. Of course, I also commonly use zip with the implicit assumption that my iterables are the same length... I have most certainly written many lines where I would appropriately choose strict-zip if it existed (whichever API). To me, itertools is not some hidden vault only accessible after performing Herculean labors. I believe boolean mode switches are usually a bad design for Python. Not always, there are exceptions like open(). And I think Guido made the good point that one of the things that makes mode switches bad is when they change the return type, which the `strict=True` API would not do (but it would create a new kind of exception to worry about). In fact, itertools is pretty much the only module where I occasionally write `from itertools import *`. There are many good things in that module that are general purpose. But namespaces, after all, are a honkin' good idea. I think if `zip()` were proposed today as a brand new function that hadn't existed, I would advocate strongly for putting it inside itertools. Probably `map()` and `filter()` similarly. So I don't want zip_strict() to join built-ins, but it's not because I think it is a niche case, but rather because I think we already have more in built-ins than we should, and some of it could very reasonably live in a more descriptive namespace. I would certainly not mind if we added `zip_shortest()` as a synonym for the current zip to itertools. -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions. ___ 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/VP72ECM5JCHVYPRA55M6EL3YLJJQQRJL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip
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/
[Python-ideas] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip
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). > -- > The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions. ___ 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/FQHSMQO6URCXGBPNIMD4NW2EW33LNR7R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding slice Iterator to Sequences (was: islice with actual slices)
Steven D'Aprano writes: > [Aside: despite what the Zen says, I think *protocols* are far more > important to Python than *namespaces*.] I think you misread the Zen. :-) That-is-my-opinion-I-do-not-however-speak-for-its-author-ly y'rs, ___ 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/2YNQ72AENBVBTMQYDP4ZV5S4MG6VA32Z/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Documenting iterators vs. iterables
Steven D'Aprano writes:
> constructed from
Thank you!
This is what I will use. "Construction" in programming has the strong
connotation of returning a new object (even though, say, int("1")
may return an interned object, so not new in a sense).
I'm not sure whether I'll rely on that looseness in describing the
"iterator constructed from an iterator" or (more likely) treat
iterators as a special case, and put "construction" in scare quotes
if the connotation that an object is, or might be, an iterator is
strong.
Comments?[1]
Steve
Footnotes:
[1] Please don't bother telling me not to use scare quotes that way
because many people are EASL or not well-educated. That is a hill I'm
willing to die on. ;-) Scare quotes a FAQ in my EASL classes (not just
because I use them), so learning to read them is a real need IME.
___
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/BU4TPSKGANREAMJZWSTDEBK62CTJP4D6/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Documenting iterators vs. iterables [was: Adding slice Iterator ...]
Andrew Barnert writes: > >> The answer is that files are iterators, while lists are… well, > >> there is no word. > > > > As Chris B said, sure there are words: File objects are *already* > > iterators, while lists are *not*. My question is, "why isn't that > > instructive?" > > Well, it’s not _completely_ not instructive, it’s just not > _sufficiently_ instructive. > > Language is more useful when the concepts it names carve up the > world in the same way you usually think about it. True. But that doesn't mean we need names for everything. In your "phases of matter" example, there are two characteristics, fluidity (which gases and liquids have, but solids don't) and compressibility (which gases have, but neither solids nor liquids do). Here the tripartite vocabulary makes sense, since they're orthogonal, and (in our modern world) all three concepts are everyday experience. > Yes, it’s true that we can talk about “iterables that are not > iterators”. But that doesn’t mean there’s no need for a word. True, but that also doesn't mean there *is* need for a word. > We don’t technically need the word “liquid” because we could always > talk about “compressibles that are not solid” (or “fluids that are > not gas”) True, but neither "compressibles" nor "fluids" "is a thing". Instead, in everyday language "fluid" is pretty much synonymous with "liquid", and AFAIK there are no compressibles that aren't fluids, so "compressible" is pretty much purely an adjective. OTOH, it's useful to pick out each phase of matter separately. You haven't make an argument that it's useful to pick out "iterables that aren't iterators" separately yet, except that you believe that a word would help (which to me is evidence for the need, but not very strong evidence). The reason I'm quite unpersuaded is that there's also a concept of marked vs unmarked in linguistics. Marked concepts are explicitly indicated; unmarked concepts require an explicit contrast with the marked concept, or they get folded into the generic word, leaving some ambiguity that gets resolved by context. (This can get really persnickety with no obvious rules even in the same domain. For example, with gender, "he" is unmarked, and you need to disambiguate "male person" from "person of unknown gender" fromm context, at least in traditional English grammar. While "she" is marked. By contrast, "male" and "female" are both unambiguous.) Now, it seems to me that we are only ever going to discuss iterators in the context of iteration, which means our domain of discourse is pretty much restricted to iterables. (In the sense that there's nothing left to discuss about iteration once you've classed an entity as "not iterable".) Given the way iterable and iterator are defined, it seems perfectly reasonable to me that iterator would be marked, non-iterator iterable left to its own devices, and the word "iterable" disambiguated from context, or perhaps marked with some fairly clumsy modifier. So how can one explain "the problem with re-iterating files"? Here's how I would (now that I've thought more about it than I should ;-): Student: OK, so we use 'for' to iterate over lists etc. And it's cool that we can do "for line in file". But how come if I need to do it twice, with lists I can just use a new 'for' statement, but with files nothing useful happens? Teacher: That's a good question. You know that "things we can use in a for statement" are called "iterables" right? Well, files are a special kind of iterable called "iterator", and you can "start them where you left off" with a new 'for' statement. Student: But the 'for' statement runs out! You don't want to restart in the middle! Teacher: Exactly! And that's why nothing useful happens when you use a second for statement on an already-open file. But you can use 'break' to stop partway through. Student: Huh? What's that good for? Teacher: [Gives relevant example: paragraph-wise processing in text files with empty line paragraph breaks, message-wise processing in mbox files, etc.] Student: Well, OK. But that's not what I expected or wanted. Teacher: [Presses "play" on Rolling Stones tune cued up for this moment. Continues as voice-over.] True enough. I wasn't there when they designed this interface to files, so I'm not sure all the reasons but I do find it useful for the kind of processing I described earlier. Of course, you can get the effect you want by using 'open' again. It's a little annoying that *you* have to remember to do this. Also, there is a way to reset files the way you want. Just use the '.seek(0)' method on the file before the second 'for' statement. Student: Hey, wait! Suppose I wanted to "restart where I left off" in iterating over a list. I guess that just
[Python-ideas] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip
On Sun, May 17, 2020 at 6: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). > > 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. > Thanks Nathan, I think this is the right idea. To make it a bit less metaphorical, strict zip is essentially an assertion. The language doesn't need assert statements - instead of ``` assert cond, message ``` we could just write [1]: ``` if __debug__ and not cond: raise AssertionError(message) ``` or import an `assert` function and write: ``` __debug__ and assert(cond, message) ``` But it's good that we have the assert statement, because it makes it easy to write safe code and so people are encouraged to do so. Similarly, you can write code without writing tests. Often that's really tempting and writing tests feels a bit pointless. It may be obvious that the code works, and the tests won't reveal anything at the time. But even then it's helpful when someone later makes a breaking change and are alerted immediately. So we need frameworks to make testing as easy as possible so we can fight the temptation to not write tests. The Python community has taken this as far as pytest's AST magic just to be able to write `assert x == y` instead of `self.assertEqual(x, y)`. A strict zip often won't provide any benefit when it's written, as it's 'obvious' that the lengths involved are equal, but just like tests it can prevent regressions. -- [1] Assuming that the compiler optimises away the statement entirely when `__debug__` is False. Right now it seems that CPython can optimise away `if __debug__:` and `if False:` but not `if __debug__ and True:` even though it collapses the condition to a constant False which it immediately tests for: ``` from dis import dis def foo(): if __debug__ or True: print(3) dis(foo) 5 0 LOAD_CONST 1 (False) 2 POP_JUMP_IF_TRUE 4 6 >>4 LOAD_GLOBAL 0 (print) 6 LOAD_CONST 3 (3) 8 CALL_FUNCTION1 10 POP_TOP 12 LOAD_CONST 0 (None) 14 RETURN_VALUE ``` ___ 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/IU4C7Z6HFZQKXEAG7PNBDFKORA5JWEAG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip
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: type hints : I'd like to suggest allowing unicode → as an alternative to ->
On Sun, 17 May 2020 at 15:45, Thierry Parmentelat < thierry.parmente...@inria.fr> wrote: > > > > On 17 May 2020, at 16:31, Bernardo Sulzbach < > berna...@bernardosulzbach.com> wrote: > > > > I would like to comment that the graphical presentation, at least in > IDEs/where the font can be controlled, can be achieved using fonts: > > > > Precisely. Nicer than the arrow symbol, it would be to type "-" + ">" > and get an arrow visually. The same can be done about getting >= as a > single symbol and == and === and <=> as single symbols. It seems like a > matter of code presentation, not code itself. > > well, I'd find it very confusing to not be able to tell visually whether > my code contains `→` or `->’ > so this really is the last thing I’d want to do, personnally at least > > > The '→' is not going to come of nowhere, secondly, your IDE will be quite unhappy when you introduce invalid syntax and it will tell you about it, so you will able to "tell visually" ___ 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/BBBFUJ37APTZ2CQLINGHNBFMJMB3AZW2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
> Before this goes too a big shaky bikeshed over almost nothing, let me
> point out that if you're looking to improve something in type
> annotations, I would suggest to look for true ugliness there.
> Something like Callable[[Dict[str, int], Sequence[Foo]],
> Dict[PrimaryKey, List[int]]]. That's rather unreadable.
totally agree on the awkwardness :-)
> Actually, let me just quote
> https://docs.python.org/3/library/typing.html#typing.Callable
>
>> Callable type; Callable[[int], str] is a function of (int) -> str.
>
> Lolwhat? If it's a function of "(int) -> str", then it should be
> written just about like that. With
> https://www.python.org/dev/peps/pep-0563/ , a lot of things which
> weren't previously possible, are now possible. Somebody should start
> thinking how to take advantage of that, up to allowing "(int) ->
> str”.
would be nice too - although this is orthogonal to my initial proposal, right ?
> Which is apparently not possible currently, as while "evaluation" is
> postponed, it still should parse eagerly as Python syntax. But even
> {(int): str} is a better type annotation for a function than
> Callable[[int], str].
well, {(int): str} already means something; are you suggesting that an
expression like this could have different meanings whether it’s in an
annotation or not ? that sounds scary ...
> And if we e.g. talk about making "->" a special operator which would
> allow it to appear in other contexts than function definition,
> "(int) -> str" (and other interesting annotation syntaxes) would be
> possible.
again, that’s be quite cool for typing function parameters :)
___
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/XT4VZTLLFUT45DOI5MRZPZAMDPBA6IVJ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
> On 17 May 2020, at 16:31, Bernardo Sulzbach > wrote: > > I would like to comment that the graphical presentation, at least in > IDEs/where the font can be controlled, can be achieved using fonts: > > Precisely. Nicer than the arrow symbol, it would be to type "-" + ">" and get > an arrow visually. The same can be done about getting >= as a single symbol > and == and === and <=> as single symbols. It seems like a matter of code > presentation, not code itself. well, I'd find it very confusing to not be able to tell visually whether my code contains `→` or `->’ so this really is the last thing I’d want to do, personnally at least ___ 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/F2U76QZOUPX47WGN3M5LBL7SPOEBLIR7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
> > I would like to comment that the graphical presentation, at least in > IDEs/where the font can be controlled, can be achieved using fonts: > Precisely. Nicer than the arrow symbol, it would be to type "-" + ">" and get an arrow visually. The same can be done about getting >= as a single symbol and == and === and <=> as single symbols. It seems like a matter of code presentation, not code itself. ___ 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/EGNUQPQRONDFJ7SLCOP6CCMLTVH4OJYK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
Hello,
On Sun, 17 May 2020 14:31:34 +0200
Alex Hall wrote:
[]
> If we consider the arrow, what about ≤ instead of <=, ≥ instead of
> >=, ≠ instead of !=, × instead of `*`, and math.π instead of math.pi?
Before this goes too a big shaky bikeshed over almost nothing, let me
point out that if you're looking to improve something in type
annotations, I would suggest to look for true ugliness there.
Something like Callable[[Dict[str, int], Sequence[Foo]],
Dict[PrimaryKey, List[int]]]. That's rather unreadable.
Actually, let me just quote
https://docs.python.org/3/library/typing.html#typing.Callable
> Callable type; Callable[[int], str] is a function of (int) -> str.
Lolwhat? If it's a function of "(int) -> str", then it should be
written just about like that. With
https://www.python.org/dev/peps/pep-0563/ , a lot of things which
weren't previously possible, are now possible. Somebody should start
thinking how to take advantage of that, up to allowing "(int) ->
str".
Which is apparently not possible currently, as while "evaluation" is
postponed, it still should parse eagerly as Python syntax. But even
{(int): str} is a better type annotation for a function than
Callable[[int], str].
And if we e.g. talk about making "->" a special operator which would
allow it to appear in other contexts than function definition,
"(int) -> str" (and other interesting annotation syntaxes) would be
possible.
--
Best regards,
Paul mailto:pmis...@gmail.com
___
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/CTS42YQ6N3Q44WHY2Y4CRAF6NISQNZUW/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
I would like to comment that the graphical presentation, at least in
IDEs/where the font can be controlled, can be achieved using fonts:
https://stackoverflow.com/questions/41774046/enabling-intellijs-fancy-%E2%89%A0-not-equal-to-operator
On Sun, 17 May 2020 at 13:26, Thierry Parmentelat <
thierry.parmente...@inria.fr> wrote:
> well it’s all in the title
>
> the specific character that I am referring to is this one
>
> In [1]: print("\u2192”)
> →
>
> https://unicode-table.com/en/2192/
>
> ——
>
> just curious about how people would feel about taking better advantage of
> non-ascii characters when that seems to make sense
>
>
> fyi here’s how both options appear in a markdown-based website
>
>
>
> thanks !
> ___
> 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/AWXLKPUXSWUXEHMI3FCIJUK25IBPQMGT/
> 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/TICG3HM7HBIKN7S5E6MPFYCVO5NWQSBT/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
> math.π instead of math.pi
That is already possible, just not done in the standard library, no? Your
point still stands, but it's rather different to your other examples, which
are actual changes to syntax.
With regards to the actual proposal, I quite like the idea of being able to
use them, but I don't think it's worth portability issues - style guides
would just end up forbidding it anyway. They're also hard to type, and of
course,
> There should be one-- and preferably only one --obvious way to do it.
On Sun, 17 May 2020 at 13:32, Alex Hall wrote:
> On Sun, May 17, 2020 at 2:24 PM Thierry Parmentelat <
> thierry.parmente...@inria.fr> wrote:
>
>> well it’s all in the title
>>
>> the specific character that I am referring to is this one
>>
>> In [1]: print("\u2192”)
>> →
>>
>> https://unicode-table.com/en/2192/
>>
>> ——
>>
>> just curious about how people would feel about taking better advantage of
>> non-ascii characters when that seems to make sense
>>
>>
>> fyi here’s how both options appear in a markdown-based website
>>
>>
> I'm not a fan of the idea, just in case the code ends up being copied
> somewhere it can't be rendered properly.
>
> If we consider the arrow, what about ≤ instead of <=, ≥ instead of >=, ≠
> instead of !=, × instead of `*`, and math.π instead of math.pi?
> ___
> 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/EKQ4WJDWE2TVCE5SRMOTVW3DC6DNXMLD/
> 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/5MFTCANQYPRA7VFLAAIKBDWZQTVFB6YF/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->
On Sun, May 17, 2020 at 2:24 PM Thierry Parmentelat <
thierry.parmente...@inria.fr> wrote:
> well it’s all in the title
>
> the specific character that I am referring to is this one
>
> In [1]: print("\u2192”)
> →
>
> https://unicode-table.com/en/2192/
>
> ——
>
> just curious about how people would feel about taking better advantage of
> non-ascii characters when that seems to make sense
>
>
> fyi here’s how both options appear in a markdown-based website
>
>
I'm not a fan of the idea, just in case the code ends up being copied
somewhere it can't be rendered properly.
If we consider the arrow, what about ≤ instead of <=, ≥ instead of >=, ≠
instead of !=, × instead of `*`, and math.π instead of math.pi?
___
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/EKQ4WJDWE2TVCE5SRMOTVW3DC6DNXMLD/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] type hints : I'd like to suggest allowing unicode → as an alternative to ->
well it’s all in the title
the specific character that I am referring to is this one
In [1]: print("\u2192”)
→
https://unicode-table.com/en/2192/
——
just curious about how people would feel about taking better advantage of
non-ascii characters when that seems to make sense
fyi here’s how both options appear in a markdown-based website
thanks !___
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/AWXLKPUXSWUXEHMI3FCIJUK25IBPQMGT/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Auto-assign attributes from __init__ arguments
Steven D'Aprano wrote:
> Proposal:
> We should have a mechanism that collects the current function or
> method's parameters into a dict, similar to the way locals() returns all
> local variables.
> This mechanism could be a new function,or it could even be a magic local
> variable inside each function, similar to what is done to make super()
> work. But for the sake of this discussion, I'll assume it is a function,
> parameters(), without worrying about whether it is a built-in or
> imported from the inspect module.
> So given a function signature:
> def func(spam, eggs, cheese=None):
>
> and a call to it func(1, 2), then inside the body of the function,
> calling parameters() will return the dict:
> {'spam': 1, 'eggs': 2, 'cheese': None}
> [...]
> Another pattern would be to pass on your parameters to the superclasses:
> super().method(**parameters())
I took a stab at this. This should work regardless of where the function is
defined.
```
import inspect
def parameters(*, expand_kwargs=True):
frame = inspect.currentframe().f_back
code = frame.f_code
varnames = code.co_varnames
end = code.co_argcount + code.co_kwonlyargcount
result = {
name: frame.f_locals[name]
for name in varnames[:end]
}
# **kwargs
if code.co_flags & inspect.CO_VARKEYWORDS:
index = end
if code.co_flags & inspect.CO_VARARGS:
index += 1
name = varnames[index]
var = frame.f_locals[name]
if expand_kwargs:
result.update(var)
else:
result[var] = name
return result
def foo1(a, b=1, *args, c, **d):
x = 1
y = 2
print(parameters())
print(a, b, c, d)
foo2(**parameters())
def foo2(a, b=1, *args, c, **d):
print(a, b, c, d)
foo1(1, 2, 3, 4, c=5, e=6, f=7)
```
Output:
```
{'a': 1, 'b': 2, 'c': 5, 'e': 6, 'f': 7}
1 2 5 {'e': 6, 'f': 7}
1 2 5 {'e': 6, 'f': 7}
```
Note that `parameters()` intentionally doesn't contain `'args': (3, 4)`
because then `foo2(**parameters())` would see `args` as a keyword argument
within `d` instead of bound to the parameter `*args`. So naturally I tried
`foo2(*args, **parameters())` but that gave me `TypeError: foo2() got
multiple values for argument 'a'`. So if you want to pass all arguments
from one function to another, you need more than a dict if the inner
signature include `*args`, and obviously even more so if it includes
positional only parameters.
___
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/QQKU24OU67ZPPFSWJHN7OCJXR7V2Z62A/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip
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. -- 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] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip
> PS. Why wasn't a new builtin zip_strict() on the menu? I think I would have given it at least +0.5, because of this rule of thumb. I would think that if zip_strict() added as a builtin, then zip_longest() should too. And the fact that zip_longest was not added as a builtin made me think that it was a non-starter. Which kinda brings up a point— in the example string methods (formerly the string module) there are a number of separate functions that could have been one function with flags. And that works well. But partly because it’s a a well defined namespace. We really don’t want to clutter up builtins too much, and having such closely related functions in different namespaces really reduces the usability. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ 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/MFJPBQLJOCNDMLZZFMJGRQOVK6UGNPYE/ Code of Conduct: http://python.org/psf/codeofconduct/
