[Python-ideas] Re: Add function for reading a specific number of bytes/characters from a file object that fails noisily
On Thu, Mar 3, 2022 at 9:58 AM Kevin Mills wrote: > I actually initially was going to suggest a `strict` flag get added, but I > figured that would be impractical. I was mostly concerned about classes > that mimic file objects, because (obviously) their read methods wouldn't > include a `strict` flag and you couldn't pass such objects to functions > using the flag. > you couldn't pass them to functions using a new method, either. No matter how you slice it, this would be an extension to the existing file-like object "protocol" I use quotes because I don't think it's a clearly defined protocol. -CHB > ___ > 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/2GYOXX5XNKN276ITAMZPIUJXIAJU6WPB/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) 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/RXAZY3BYEYASTC6W5ALLV5VUO4MVHWFK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add function for reading a specific number of bytes/characters from a file object that fails noisily
+0.1? > The code I'm currently working on involves parsing binary data. If I > ask for, say, 4 bytes, it's because I actually need 4 bytes and if the > file doesn't have 4 bytes for me, it's malformed. Because `f.read(4)` > can silently return less than 4 bytes and I don't want to have to > explicitly double check every read, I'm using a wrapper function. Without taking a position on whether this is worth it in the standard library, it should be noted that Rust's stdlib does include a read_exact function working in much the same way (though of course with a Result instead of an exception, and it should be noted that Rust, as a systems language, is far more likely to be used to parse binary formats). -- Lincoln Auster They/Them ___ 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/SCKHQHJEZXDKPBVEXOA2HXU74FEQ3M2O/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add function for reading a specific number of bytes/characters from a file object that fails noisily
I actually initially was going to suggest a `strict` flag get added, but I figured that would be impractical. I was mostly concerned about classes that mimic file objects, because (obviously) their read methods wouldn't include a `strict` flag and you couldn't pass such objects to functions using the flag. ___ 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/2GYOXX5XNKN276ITAMZPIUJXIAJU6WPB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops
On Fri, 4 Mar 2022 at 02:48, Steven D'Aprano wrote: > > On Thu, Mar 03, 2022 at 10:30:32PM +1100, Chris Angelico wrote: > > On Thu, 3 Mar 2022 at 21:14, Steven D'Aprano wrote: > > > What did I say that made you think I denied the existence of filtered > > > iteration? Was it the post where I pointed out we've been able to do > > > filtered iteration going back to Python 1.x days? > > > > ANYTHING can be done by composing concepts. We don't need anything > > more advanced than Brainf*. Why do we have better concepts? Because > > they do a better job of expressing abstract concepts. > > They also do a better job of expressing *concrete* concepts, like > addition. > > I believe this is a BF program to read two single digit numbers, add > them, and print the result: > > ,>,[<+>-]<. This is a BF program that expresses an abstract concept of addition. On what basis do you consider addition to be a concrete concept? Is Python's idea of addition a single machine instruction? What, in your view, makes one thing abstract and another thing concrete? I put it to you that "add two numbers" is an abstract concept. Even more so, "add two things" is definitely an abstract concept, and we have a clean way of expressing this, regardless of whether it's string concatenation, list extension, or numeric arithmetic. The BF program you show clearly demonstrates that there are concrete actions that BF is capable of, and they can be composed into the abstract idea of integer addition. Composition can do anything! Why do we need better languages? Because they are better able to express abstract concepts like "add two integers". Calling addition "concrete" because it has a simple spelling *in Python* is the Blub Paradox at its best. You are denying features that don't exist because composition can create them, and dismissing the exact same argument about features that do exist, simply because... they do exist. Addition is no more or less abstract than iteration, or than filtered iteration, or than anything else. It's not a question of "this is abstract, this is concrete". It's that pretty much everything we ever think about is an abstract concept, to be implemented by the compiler/interpreter in its own concrete way. The real question is: Which abstract concepts deserve syntax? (In fact, even BF's fundamentals could be considered abstract concepts. But doing so would require that you be willing to consider "concrete" to be the level of electrical engineering. Or domino engineering. A half-adder can be implemented using a few square meters of racing dominoes, and once you design that abstract concept, you can build a four-bit adder with a full room of dominoes. When you think on THAT scale, even a simple 'or' gate is a very abstract concept!!) > I don't think that the difference between the status quo and the proposal: > > # status quo for a filtered loop > for item in items: > if condition: > block > > # proposal for a filtered loop > for item in items if condition: > block > > is comparable to the difference between BF and Python. How about you? There is a difference of degree, to be sure. But in the status quo, the programmer has to put the condition into the body, since there's no way to express it in the header. A for loop can be implemented more concretely using a while loop and iter/next. We don't work that way. Why? Because it doesn't adequately express the *concept* that we're trying to get across. Programming is about expressing the ideas that we programmers have, in ways that other programmers AND a computer will be able to understand. Please can you stop blub-paradoxing yourself by assuming that what exists is completely different from what doesn't exist? > > > To be clear, there are lots of concepts in coding. Not all of them > > > require their own specialised syntax. We don't have specialised syntax > > > for a try...except block inside a loop, we use composition by putting a > > > try...except block inside a for loop. > > > > > > Composition of statements is not a bug to be fixed. > > > > Indeed, but I'm putting the viewpoint - which a number of other people > > have also put - that filtered iteration DOES deserve a better way of > > expressing it. > > Better than the three or four ways we already have? Okay. > > To me, comprehensions were a significant improvement over the Python 1.x > status quo, because they permitted us to write list builders as > expressions, which could then be embedded directly in statements or > other expressions without needing temporary variables. > > Generators and iterators were significant improvements, because they > allow us to do things we couldn't do (easily, or at all) before. > > Context managers were another significant improvement. > > Aside from saving one line and one indent level, what *significant* > improvement does the proposed change give us? This is not a rhetorical
[Python-ideas] Re: Add function for reading a specific number of bytes/characters from a file object that fails noisily
Rather than a new function, maybe a flag? read(n, strict=True) (Not sure if a block flag would also be useful, but maybe) -CHB -- Christopher Barker, PhD (Chris) 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/D63IOGCQF7XGR4JIPZ2BH3ELOHAMBWVB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops
On Thu, Mar 03, 2022 at 10:30:32PM +1100, Chris Angelico wrote: > On Thu, 3 Mar 2022 at 21:14, Steven D'Aprano wrote: > > What did I say that made you think I denied the existence of filtered > > iteration? Was it the post where I pointed out we've been able to do > > filtered iteration going back to Python 1.x days? > > ANYTHING can be done by composing concepts. We don't need anything > more advanced than Brainf*. Why do we have better concepts? Because > they do a better job of expressing abstract concepts. They also do a better job of expressing *concrete* concepts, like addition. I believe this is a BF program to read two single digit numbers, add them, and print the result: ,>,[<+>-]<. And if you think that is nasty, you should see Malbolge. I don't think that the difference between the status quo and the proposal: # status quo for a filtered loop for item in items: if condition: block # proposal for a filtered loop for item in items if condition: block is comparable to the difference between BF and Python. How about you? > > To be clear, there are lots of concepts in coding. Not all of them > > require their own specialised syntax. We don't have specialised syntax > > for a try...except block inside a loop, we use composition by putting a > > try...except block inside a for loop. > > > > Composition of statements is not a bug to be fixed. > > Indeed, but I'm putting the viewpoint - which a number of other people > have also put - that filtered iteration DOES deserve a better way of > expressing it. Better than the three or four ways we already have? Okay. To me, comprehensions were a significant improvement over the Python 1.x status quo, because they permitted us to write list builders as expressions, which could then be embedded directly in statements or other expressions without needing temporary variables. Generators and iterators were significant improvements, because they allow us to do things we couldn't do (easily, or at all) before. Context managers were another significant improvement. Aside from saving one line and one indent level, what *significant* improvement does the proposed change give us? This is not a rhetorical question. > > Nobody said that the idea of filtered looping doesn't make sense. > > They're only questioning whether it needs its own syntax instead of > > composing existing syntax. > > Yes. And it keeps coming up, so I think you should probably > acknowledge the fact that maybe, just maybe, this is more significant > than "one newline". I have repeatedly said that it also saves an indent level. I never bothered to mention the saving of one colon, because I thought that even for Python-Ideas that would be too trivially unimportant to mention. What else does it give us? The one-line proposal and the two line status quo express exactly the same concept: a loop with a filter. The functional programming idiom using filter() is even better at expressing that concept, at least for the case where the predicate is a function, but many people have an unfortunate aversion to f.p. idioms and so won't use it. > > > You're thinking FAR FAR too concretely about this. It's not about > > > newlines. > > > > Of course it is. The whole point of the proposal is to move a two line > > statement into a single line. Earlier in this thread, I pointed out that > > this proposal adds no new functionality to Python. It doesn't allow us > > to do anything we can't already do, or even make it easier to do it. > > > > Literally all it saves is a newline and an indent. > > No, it is not. It is expressing the concept of filtered iteration. Which the existing idioms already do. So we have three or four ways of expressing filtered iteration, and the proposal is for another way of expressing filtered iteration which differs in that it saves a line and an indent level, and let's not forget that vitally important colon. Is there any other difference that I have missed? > Do you, or don't you, accept that that is a concept? One moment you say > that it is a concept but you think it shouldn't get dedicated syntax, Yes. Many concepts don't have dedicated syntax. We don't have dedicated syntax for, say, recursion. (We just use a function call.) Or for getting the length of a sequence (another function call). Or sorting. > then the next, you imply that it isn't even a concept, Citation required. > and all we're > doing is reformatting code. That is simply not the case. Okay, now we're getting somewhere! So there is a semantic difference between the status quo and the new proposal. I'm sorry, I missed that! Mea culpa. Please take pity on me and explain what I have missed. In the status quo, we have a filtered loop written as: for item in items: if condition: block but of course you know that already :-) So how does the proposal dif
[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops
What I said: "Python, for good or ill, is an opinionated language regarding indentation and statements." And then Greg refuted something I never said: > So if Python is opinionated about line lengths, it's rather > selectively opinionated. The Python language isn't opinionated about line lengths, except as a coding standard. So whatever point you think you are making about line lengths, it is not refuting anything I have said. PEP 8 isn't mandatory, but lots of people follow it. Even those who don't still try to avoid writing 800-column lines. Greg, I trust that you will agree that even if the interpreter allows them, long one-liners with semicolons are not considered Pythonic. -- Steve ___ 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/SKBNGI4TDMW6F7X4QMMA46XANGLHC4FH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add function for reading a specific number of bytes/characters from a file object that fails noisily
On Thu, 3 Mar 2022 at 20:28, Steven D'Aprano wrote: > > On Thu, Mar 03, 2022 at 08:27:50AM -, Kevin Mills wrote: > > > The code I'm currently working on involves parsing binary data. If I > > ask for, say, 4 bytes, it's because I actually need 4 bytes and if the > > file doesn't have 4 bytes for me, it's malformed. Because `f.read(4)` > > can silently return less than 4 bytes and I don't want to have to > > explicitly double check every read, I'm using a wrapper function. > > This is not a terrible idea. Other languages, like Pascal, have facility > for reading fixed-size chunks from a file, reading integers or floats > from a file. But there are some design questions that need to be sorted > out. > > If you're reading from, say, a serial port, and it only has three bytes, > should it hang until a fourth byte is available, or raise an exception > (thus losing the first three bytes)? > My preferred colour for this particular bikeshed: Block. This API doesn't make sense for with non-blocking FDs (just use normal read() and accept short returns), so what it does in that situation probably doesn't matter; I'd be inclined to have it return the three bytes, and document that for non-blocking FDs, this is equivalent to read(n) and may not return the full length. I'd be most likely to use this sort of API with pipes, where the normal thing to do is to block until the other process has pushed the next block of data out. 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/XH6AANQ2XSROANNOGA7GQML46YE6ATQO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops
On Thu, 3 Mar 2022 at 21:14, Steven D'Aprano wrote: > What did I say that made you think I denied the existence of filtered > iteration? Was it the post where I pointed out we've been able to do > filtered iteration going back to Python 1.x days? ANYTHING can be done by composing concepts. We don't need anything more advanced than Brainf*. Why do we have better concepts? Because they do a better job of expressing abstract concepts. > To be clear, there are lots of concepts in coding. Not all of them > require their own specialised syntax. We don't have specialised syntax > for a try...except block inside a loop, we use composition by putting a > try...except block inside a for loop. > > Composition of statements is not a bug to be fixed. Indeed, but I'm putting the viewpoint - which a number of other people have also put - that filtered iteration DOES deserve a better way of expressing it. > Nobody said that the idea of filtered looping doesn't make sense. > They're only questioning whether it needs its own syntax instead of > composing existing syntax. Yes. And it keeps coming up, so I think you should probably acknowledge the fact that maybe, just maybe, this is more significant than "one newline". > > You're thinking FAR FAR too concretely about this. It's not about > > newlines. > > Of course it is. The whole point of the proposal is to move a two line > statement into a single line. Earlier in this thread, I pointed out that > this proposal adds no new functionality to Python. It doesn't allow us > to do anything we can't already do, or even make it easier to do it. > > Literally all it saves is a newline and an indent. No, it is not. It is expressing the concept of filtered iteration. Do you, or don't you, accept that that is a concept? One moment you say that it is a concept but you think it shouldn't get dedicated syntax, then the next, you imply that it isn't even a concept, and all we're doing is reformatting code. That is simply not the case. > > It's about expressing programmer concepts. > > Right. And composing a for-loop with a if statement expresses that > concept perfectly. As does filter(). No, it doesn't. > > > Fresh strawberries are great. Mushroom sauce is great. But strawberries > > > with mushroom sauce is ... not. > > > > > > > You DO know that you just made several people think "hmm, maybe I > > should try strawberries with mushroom sauce", right? > > :-) > I love how utterly unapologetic you are. And I really hope that someone actually tries it, and reports back to the list. Who knows? Maybe we'll start a new fad! 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/XJGDTBA3SWENLPWMVXOY2PHGKWC33SMH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops
On 3/03/22 9:50 pm, Steven D'Aprano wrote:
While you can put the block on the same line as the colon using
semicolons:
if condition: print(1); print(2) # Legal.
and there's nothing to stop you from making arbitrarily long
lines using this feature...
if condition: print(1); print(2); print(buckle); print(my_shoe);
print("Is this line long enough yet?")
So if Python is opinionated about line lengths, it's rather
selectively opinionated.
--
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/X6QQV5GDVCIVIDFYS6G5WEMUG2WG65BH/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops
On Thu, Mar 03, 2022 at 08:04:57PM +1100, Chris Angelico wrote: > Python has a history of making conceptual actions shorter than the > mere combination of their parts. For instance, we don't have this > construct: > > for i in range(len(stuff)) using thing = stuff[i]: Rather than inventing new (fake) syntax to illustrate your point, a better example would be: for i in range(len(stuff)): thing = stuff[i] which is real code that people have written (including me!), and two statements. Just like the for... if... compound statement being debated now. And we did take that two-line idiom from Python 1.x and turn it into a one-line *functional* style in Python 2, using enumerate(). > No, we have this: > > for i, thing in enumerate(stuff): Indeed. What we *didn't* do is invent new syntax for i in range(len(stuff)) using stuff[i] as thing we just came up with a function, enumerate(). If only Python had a function that would allow us to combine iteration and filtering... *wink* > No matter how much you personally pooh-pooh the idea, filtered > iteration is a very real concept, o_O What did I say that made you think I denied the existence of filtered iteration? Was it the post where I pointed out we've been able to do filtered iteration going back to Python 1.x days? To be clear, there are lots of concepts in coding. Not all of them require their own specialised syntax. We don't have specialised syntax for a try...except block inside a loop, we use composition by putting a try...except block inside a for loop. Composition of statements is not a bug to be fixed. [...] > There's an inefficient and verbose option of the genexp, but I don't > think many people like it: > > for thing in (thing for thing in stuff if isinteresting(thing)): Indeed. But if you combine map() and filter() with the iteration, it becomes very powerful: for thing in (expression for x in stuff if isinteresting(x)): And with the walrus operator, you can filter on the mapped value as well: for thing in (y:=expression for x in stuff if isinteresting(x or y)): > although when it's actually a function like this, you have this option: > > for thing in filter(isinteresting, stuff): > > which actually looks good. I think this is a pretty clear indication > that the idea makes sense: functional programming languages have an > idiom that aligns perfectly with it, it's just that Python's lambda > syntax is too clunky for inline expressions to look as good. Nobody said that the idea of filtered looping doesn't make sense. They're only questioning whether it needs its own syntax instead of composing existing syntax. > for thing in filter(lambda n: n % 7 < 2, stuff): Looks fine to me. But you could also use: for thing in (n for n in stuff if n%7 < 2): which also looks fine to me. > I do not think Python should have a syntax which is merely removing a > newline from what can already be done. But a proper syntax for > filtered iteration WOULD be of extreme value. We have proper syntax: compose the for loop with the filter. Or use the functional idiom with filter(func, items). Or various other options such as generators. These are all "proper" syntax. They're just not *dedicated specialist syntax* for filtered iteration. With so many options to choose from, I don't think we need dedicated syntax for this operation. What does it add, aside from bloat? > What Python needs is not a way to cram more onto one line. What Python > needs is a way to express an abstract concept: "iterate over the > interesting parts of this collection". Something like composition of a for-loop and an if, or filter(). Yes, if only we were capable of doing filtered iteration in Python! Then at last Python would be Turing Complete and a Real Programming Language!!! *wink* > > A compound statement that ends with a colon is either either followed by > > a newline and one indent, or a series of semicolon separated simple > > statements. Never by another compound statement. > > You're thinking FAR FAR too concretely about this. It's not about > newlines. Of course it is. The whole point of the proposal is to move a two line statement into a single line. Earlier in this thread, I pointed out that this proposal adds no new functionality to Python. It doesn't allow us to do anything we can't already do, or even make it easier to do it. Literally all it saves is a newline and an indent. > It's about expressing programmer concepts. Right. And composing a for-loop with a if statement expresses that concept perfectly. As does filter(). > > Fresh strawberries are great. Mushroom sauce is great. But strawberries > > with mushroom sauce is ... not. > > > > You DO know that you just made several people think "hmm, maybe I > should try strawberries with mushroom sauce", right? :-) -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscr
[Python-ideas] Re: Add function for reading a specific number of bytes/characters from a file object that fails noisily
On Thu, Mar 03, 2022 at 08:27:50AM -, Kevin Mills wrote: > The code I'm currently working on involves parsing binary data. If I > ask for, say, 4 bytes, it's because I actually need 4 bytes and if the > file doesn't have 4 bytes for me, it's malformed. Because `f.read(4)` > can silently return less than 4 bytes and I don't want to have to > explicitly double check every read, I'm using a wrapper function. This is not a terrible idea. Other languages, like Pascal, have facility for reading fixed-size chunks from a file, reading integers or floats from a file. But there are some design questions that need to be sorted out. If you're reading from, say, a serial port, and it only has three bytes, should it hang until a fourth byte is available, or raise an exception (thus losing the first three bytes)? -- Steve ___ 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/MDK4XPQXMHVUZHG75XYKHSOJAJEKT6PQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops
On Thu, 3 Mar 2022 at 19:54, Steven D'Aprano wrote:
>
> On Thu, Mar 03, 2022 at 02:32:25AM +, Rob Cliffe via Python-ideas wrote:
>
> > But the proposal would give people the choice of
> > Saving a level of indentation at the cost of having two
> > suite-introductions on the same line.
> > Keeping the two suit-introductions on separate lines (as now) at
> > the cost of an extra level of indentation.
>
> Why only two? Why not more than two?
>
> for item in seq: if cond: while flag: with something as x: for y in
> x.thing(): if condition:
> block
>
> Many other languages allow developers to cram code into enormous
> one-liners. Should we do the same?
>
> This is not a rhetorical question. And I have a non-rhetorical answer.
>
> In my opinion, no we should not.
Python has a history of making conceptual actions shorter than the
mere combination of their parts. For instance, we don't have this
construct:
for i in range(len(stuff)) using thing = stuff[i]:
No, we have this:
for i, thing in enumerate(stuff):
No matter how much you personally pooh-pooh the idea, filtered
iteration is a very real concept, and people do it as best they can
with the idioms available. In Python, that usually means putting part
of the iteration code into the body of the loop:
for thing in stuff:
if not isinteresting(thing): continue
There's an inefficient and verbose option of the genexp, but I don't
think many people like it:
for thing in (thing for thing in stuff if isinteresting(thing)):
although when it's actually a function like this, you have this option:
for thing in filter(isinteresting, stuff):
which actually looks good. I think this is a pretty clear indication
that the idea makes sense: functional programming languages have an
idiom that aligns perfectly with it, it's just that Python's lambda
syntax is too clunky for inline expressions to look as good.
for thing in filter(lambda n: n % 7 < 2, stuff):
I do not think Python should have a syntax which is merely removing a
newline from what can already be done. But a proper syntax for
filtered iteration WOULD be of extreme value.
In bracey languages, I'll often combine the 'if' and 'for' onto one
line, because newline flexibility lets me write filtered iteration
that way. It's not ideal but it's a lot better than nothing:
for () if (...) {
...
}
What Python needs is not a way to cram more onto one line. What Python
needs is a way to express an abstract concept: "iterate over the
interesting parts of this collection".
> A compound statement that ends with a colon is either either followed by
> a newline and one indent, or a series of semicolon separated simple
> statements. Never by another compound statement.
You're thinking FAR FAR too concretely about this. It's not about
newlines. It's about expressing programmer concepts.
> Fresh strawberries are great. Mushroom sauce is great. But strawberries
> with mushroom sauce is ... not.
>
You DO know that you just made several people think "hmm, maybe I
should try strawberries with mushroom sauce", right?
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/JQGDLV5UVVVFTL7QHN5REOOPHQUX6XG5/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops
On Thu, Mar 03, 2022 at 02:32:25AM +, Rob Cliffe via Python-ideas wrote: > But the proposal would give people the choice of > Saving a level of indentation at the cost of having two > suite-introductions on the same line. > Keeping the two suit-introductions on separate lines (as now) at > the cost of an extra level of indentation. Why only two? Why not more than two? for item in seq: if cond: while flag: with something as x: for y in x.thing(): if condition: block Many other languages allow developers to cram code into enormous one-liners. Should we do the same? This is not a rhetorical question. And I have a non-rhetorical answer. In my opinion, no we should not. Python, for good or ill, is an opinionated language regarding indentation and statements. The general rule for compound statements is that the statement that introduces the block must appear on its own line. While you can put the block on the same line as the colon using semicolons: if condition: print(1); print(2) # Legal. you can't introduce a new block: if condition: for x in loop: # Not legal. A compound statement that ends with a colon is either either followed by a newline and one indent, or a series of semicolon separated simple statements. Never by another compound statement. This is, I believe, partly to keep the parser simple, and partly to keep the code easy to read, write and reason about. Could we do something different? Of course we could. But would the result still feel like Python? I don't think so. Ultimately, the choice comes down to taste. Python is not Perl, or APL, or Forth, or Hyperscript, or Inform. Anyone who has been reading my emails over the years knows that I am particularly fond of Forth and Hyperscript, and yet I would not want Python to be more like either of them. You don't have to think that a syntactic feature is *bad* to think that it doesn't belong in Python. Fresh strawberries are great. Mushroom sauce is great. But strawberries with mushroom sauce is ... not. -- Steve ___ 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/VHVDFWLVTH76WZZ4UXAA4QDGACDGDB4R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Add function for reading a specific number of bytes/characters from a file object that fails noisily
The code I'm currently working on involves parsing binary data. If I ask for,
say, 4 bytes, it's because I actually need 4 bytes and if the file doesn't have
4 bytes for me, it's malformed. Because `f.read(4)` can silently return less
than 4 bytes and I don't want to have to explicitly double check every read,
I'm using a wrapper function.
def read_exact(f, size):
data = f.read(size)
if len(data) < size:
raise EOFError(f"expected read of size {size}, got {len(data)}")
return data
I don't think my scenario of "give me exactly the number of bytes/characters I
asked for or fail noisily" is particularly uncommon, so I think that a similar
function should be added to the standard library somewhere. I guess as a
function in `io`?
Admittedly, as my own code demonstrates, implementing it yourself if you need
it is trivial, so it may not actually be worth adding.
___
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/3T2N6QRXR7SQVFGEBLG5HZSPI235D44R/
Code of Conduct: http://python.org/psf/codeofconduct/
