[Python-ideas] Re: Add function for reading a specific number of bytes/characters from a file object that fails noisily
On Fri, 4 Mar 2022 at 12:10, Christopher Barker wrote: > > 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. For what it's worth, there IS a way to slice it that isn't an extension. Create a separate function like this: def read_chunk(f, size): data = f.read(size) while size >= len(data): data += f.read(size - len(data)) return data Stick that into os or something, and then it would work on anything with a read method (and this has been deliberately written to not care whether it's working in characters or bytes). I think it's better as a method, but if there's an issue with extending the protocol, this might be an alternative. 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/CMWVOCW2TYZRD5AG2CUDLP4SAQQI3HDT/ 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, Mar 03, 2022 at 08:09:00AM -0800, Christopher Barker wrote: > Rather than a new function, maybe a flag? https://martinfowler.com/bliki/FlagArgument.html https://alexkondov.com/should-you-pass-boolean-to-functions/ -- 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/QZB6QQXHUZYFJVJJAOZD33WV7S354QYX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops
On Sat, 5 Mar 2022 at 04:34, Christopher Barker wrote: > > >> > In the status quo, we have a filtered loop written as: >> > >> > for item in items: >> > if condition: >> > block > > > The thing is, if block is more than a couple lines, you need to look down to > see if there’s an else or any number of elif blocks down there— so this isn’t > a clear expression of a filtered iteration after all. Which is why I > suggested that: > > for item in items: > if not condition: > continue > block > > Would be the more direct expression of "filtered iteration" -- still not a > whole lot of code, but a bit more awkward. > > The other thing that I think is relevant is that comprehensions already have > a filtering option -- so while new syntax technically. this proposal would be > familiar and create a bit more consistency in the language. > > Another half formed idea: > > Comprehension can express map-like behavior or map and filter behavior, but > no way to filter without a do nothing map. > > e.g if you want to only filter, you need to do: > > (item for item in items if condition) > > I wonder if there's a way to not need to the "item for item" wasted text: > > (Item in items if condition) > and > [item in items if condition] > maybe?? > > it's not legal syntax now. That would then allow: > Tempting, very tempting. I've been in the situation of wanting this before. Without the word "for", though, it doesn't say that it's a loop, and "item in items" is a condition, "if" can be used as part of an if/else expression, and overall, this is dangerously close to valid syntax. What if omitting the value were to automatically use the loop iterator? [for item in items if condition] But at this point it's not really saving much. 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/OEM5FAKWTGLTRPLKUUHPQHRUDJ762IVE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops
> > In the status quo, we have a filtered loop written as: > > > > for item in items: > > if condition: > > block The thing is, if block is more than a couple lines, you need to look down to see if there’s an else or any number of elif blocks down there— so this isn’t a clear expression of a filtered iteration after all. Which is why I suggested that: for item in items: if not condition: continue block Would be the more direct expression of "filtered iteration" -- still not a whole lot of code, but a bit more awkward. The other thing that I think is relevant is that comprehensions already have a filtering option -- so while new syntax technically. this proposal would be familiar and create a bit more consistency in the language. Another half formed idea: Comprehension can express map-like behavior or map and filter behavior, but no way to filter without a do nothing map. e.g if you want to only filter, you need to do: (item for item in items if condition) I wonder if there's a way to not need to the "item for item" wasted text: (Item in items if condition) and [item in items if condition] maybe?? it's not legal syntax now. That would then allow: for item in (item in items if condition): block which is almost what's being asked for here. But then the repetition again. Which leads us back to the OP’s proposal. I’m actually liking that more now …. -CHB > > but of course you know that already :-) > > > > So how does the proposal differ? > > > > for item in items if condition: > > block > > > > means what, if it isn't merely a reformatting of the status quo? > > Well, if "a + b" is just a reformatting of the BF code you posted, > then yes, it's merely reformatting. > > > > > > 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. > > > > Wait, you are saying that > > > > for item in filter(predicate, items) > > > > *doesn't* express the concept of a loop with a filter? > > > > Then what does it express? > > This does. The trouble is that it ONLY expresses that cleanly in the > case where the predicate is already a function. Otherwise it gets > cluttered with the mess of lambda functions, and it's a lot less > clear. > > > And what do you say to the poster who wrote about "filtered iteration": > > > > [quote] > > ... 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 [filtered iteration] makes sense: functional programming > > languages have an idiom that aligns perfectly with it > > [/quote] > > > > The author of that post certainly sounds like he thinks that the f.p. > > idiom `for item in filter(...)` expresses filtered iteration "perfectly". > > > > (At least for the case where the predicate is a function. I don't think > > he is too fond of lambdas.) > > Exactly. Try the versions where that isn't the case, and you'll see why. > > We have [x + 1 for x in stuff if x % 3] without lambda functions. We > could have just used [x + 1 for x in filter(lambda x: x % 3, stuff)] > but that's just ugly. There is a huge difference between filter() with > an existing, and usefully-named, predicate, and filter() with a lambda > function (or worse, a single-use global function whose entire purpose > is that filtration). > > Lambda functions are extremely useful when they're needed. They are > NOT arbitrary expressions that can be inserted anywhere. > > Blub Paradox has you thoroughly in its grip. > > 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/SRW66ZR6PGSLHVROJHY6C3GR6KOIL2YF/ > 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/OUN6FEEJ3H6BCXQGWT5ZF77MKDZYVIIK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Syntax proposal of for..in..if in regular for loops
This post is rather off topic. If you don't want to get bogged down in
philosophical arguments, you might want to skip this one and come back
to my next reply, which I promise will be more on top.
On Fri, Mar 04, 2022 at 04:39:12AM +1100, Chris Angelico wrote:
> > 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.
No, it expresses the concept of addition of a concrete data type,
integer, not just in the abstract but specifically of one digit decimal
integers. Not numbers in general, or operator overloading, or addition
of matrices, vectors. It is not the abstract commutative, associative
binary operator represented by `+` in abstract algebra. It is the
concrete integer addition.
https://en.wikipedia.org/wiki/Algebraic_structure
Anyway, let's not get too bogged down over semantic disagreements about
what is "concrete" and "abstract", since to some degree these are both
*relative* terms. Addition of integers is concrete compared to addition
in the abstract, and abstract compared to addition in the sense of
adding two apples to three apples and getting five apples.
> On what basis do you consider addition to be a concrete concept?
Baby chickens of only a few days old, with no training, are
instinctively capable of simple addition and subtraction. That's pretty
far from the level of abstraction we find in abstract algebra, or in
Monads (for example).
https://www.quantamagazine.org/animals-can-count-and-use-zero-how-far-does-their-number-sense-go-20210809/
https://wiki.haskell.org/All_About_Monads
> Is Python's idea of addition a single machine instruction?
Yes, it is the BINARY_ADD machine instruction in the Python virtual
machine.
>>> dis.dis('x+y')
1 0 LOAD_NAME0 (x)
2 LOAD_NAME1 (y)
4 BINARY_ADD
6 RETURN_VALUE
Maybe some day, someone will create a physical Python Machine, like
people created physical Lisp Machines and Forth Machines.
> What, in your view, makes one thing abstract and another thing
> concrete?
I think that this discussion is already getting too far off-topic, so
I'm going to decline to answer beyond what I have already said above.
I will respond to the rest of your post shortly.
--
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/JNEXQDX2LGN3OYNJHLLCZK3SH4ZI55Y4/
Code of Conduct: http://python.org/psf/codeofconduct/
