Re: for -- else: what was the motivation?
On 2022-10-22 15:04:58 +0200, Peter J. Holzer wrote: > On 2022-10-19 12:10:52 +1100, Chris Angelico wrote: > > On Wed, 19 Oct 2022 at 12:01, Peter J. Holzer wrote: > > > On 2022-10-17 09:25:00 +0200, Karsten Hilbert wrote: > > > > http://literateprogramming.com/ > > > > > > Right. That's one of the inspirations for my comment. > > > > > > But literate programming is of course still very much rooted in the > > > "linear text representation" paradigm. You have one definite source > > > which is a linear text. > > > > > > In a world of IDEs, databases and hypertext that's probably not the best > > > we can do. As Raymond Hettinger would say, "there must be a better way". > > > > > > It would be very different from mainstream programming languages, > > > however. And ideally you would want it to integrate with a lot of other > > > infrastructure. So that alone might make it a non-starter, even if it > > > was really good (which realistically early iterations wouldn't be). > > > > There are special-purpose languages like Scratch which are not simple > > text in that form. > > Yes, I know. > > It has a different goal though: Scratch tries to establish a friendly > learning environment. Get rid of typing and syntax errors that beginners > find so frustrating. > > What I'm interested in is an enviroment for developing medium-sized real > applications. Late addendum: Watch ["Stop Writing Dead Programs" by Jack Rusher (Strange Loop 2022)](https://www.youtube.com/watch?v=8Ab3ArE8W3s) for an overview of some ideas about programming environments. hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | [email protected] |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Need help with custom string formatter
On 2022-11-05 11:07, Stefan Ram wrote: Robert Latest writes: result += ' ' *( length - len( result )) Nice, I didn't know that one could multiply strings by negative numbers without error. Thanks, but today I thought that maybe there might be a solution for getting a field of a fixed length that is even shorter. It uses Python's string formatting, here in the form of an "f" string. main.py def f( result, length ): # get a field with the given length from the string "result" # - as used in postings from october result = result[ :length ] result += ' ' *( length - len( result )) That can be done more compactly as: result = result[ : length].ljust(length) return result [snip] -- https://mail.python.org/mailman/listinfo/python-list
Re: an oop question
[email protected] (Stefan Ram) writes: > Julieta Shem writes: >>[email protected] (Stefan Ram) writes: >>>Later, I looked at a book in a bookstore; it was a book >>>about programming by Barbara Liskov that came out after the >>>LSP was already mentioned often, and as far as I could see, >>>that book did not mention the LSP at all, although it >>>actually had a chapter about subtypes! >>Do you remember the book's title? > > Unfortunately, no. I might have seen it between 1995 and 2010, > so it could have been > > Program Development in Java: > Abstraction, Specification, and Object-Oriented Design > by John Guttag and Barbara Liskov, > June 2000 > > . It has this predecessor: > > Abstraction and Specification in Program Development > by Barbara Liskov and John Guttag, > March 1986 > > . But I also found this paper, which I recommend to look at > in this regard: > > A Behavioral Notion of Subtyping, > Barbara Liskov and Jeannette M. Wing, > 1994 > > . It contains the quite readable > > |Subtype Requirement: Let φ(z) be a property provable about > |objects x of type T. Then φ(y) should be true for objects y > |of type S where S is a subtype of T. Thank you so much for the references! [...] -- https://mail.python.org/mailman/listinfo/python-list
comprehension parsing
The two comprehensions: all((srt(n, m) in c_np) == (srt(a, b) in c_ap) for (m, b) in na) all( srt(n, m) in c_np == srt(a, b) in c_ap for (m, b) in na) parse differently but I am unclear what the second one produces since I thought it would be the same as the first. Any ideas how the second one parses? -- https://mail.python.org/mailman/listinfo/python-list
Re: comprehension parsing
On Saturday, 5 November 2022 at 16:06:52 UTC, cactus wrote: I should have quoted the full comprehensions: all((srt(m, n) in c_np) == (srt(a, b) in c_ap) for (m, a), (n, b) in combinations(na8, 2)) all( srt(m, n) in c_np == srt(a, b) in c_ap) for (m, a), (n, b) in combinations(na8, 2)) -- https://mail.python.org/mailman/listinfo/python-list
Re: comprehension parsing
On 2022-11-05 18:52, cactus wrote:
On Saturday, 5 November 2022 at 16:06:52 UTC, cactus wrote:
I should have quoted the full comprehensions:
all((srt(m, n) in c_np) == (srt(a, b) in c_ap) for (m, a), (n, b) in
combinations(na8, 2))
all( srt(m, n) in c_np == srt(a, b) in c_ap) for (m, a), (n, b) in
combinations(na8, 2))
The comparison operators can be chained, so:
a == b == c
is equivalent to:
(a == b) and (b == c)
except that the common term ('b' in this case) is evaluated only once.
'in' is one of those comparison operators, so:
srt(m, n) in c_np == srt(a, b) in c_ap
is equivalent to:
(srt(m, n) in c_np) and (c_np == srt(a, b)) and (srt(a, b) in c_ap)
except that the common terms ('c_np' and 'srt(a, b)') are evaluated only
once.
Chaining makes most sense with multiple '==' or a series of '<' and/or
'<=' or a series of '>' and/or '>=', as in '1 <= n <= 10'.
--
https://mail.python.org/mailman/listinfo/python-list
Re: comprehension parsing
On 05/11/2022 22:11, MRAB wrote:
On 2022-11-05 18:52, cactus wrote:
On Saturday, 5 November 2022 at 16:06:52 UTC, cactus wrote:
I should have quoted the full comprehensions:
all((srt(m, n) in c_np) == (srt(a, b) in c_ap) for (m, a), (n, b)
in combinations(na8, 2))
all( srt(m, n) in c_np == srt(a, b) in c_ap) for (m, a), (n, b)
in combinations(na8, 2))
The comparison operators can be chained, so:
a == b == c
is equivalent to:
(a == b) and (b == c)
except that the common term ('b' in this case) is evaluated only once.
'in' is one of those comparison operators, so:
srt(m, n) in c_np == srt(a, b) in c_ap
is equivalent to:
(srt(m, n) in c_np) and (c_np == srt(a, b)) and (srt(a, b) in c_ap)
except that the common terms ('c_np' and 'srt(a, b)') are evaluated only
once.
Chaining makes most sense with multiple '==' or a series of '<' and/or
'<=' or a series of '>' and/or '>=', as in '1 <= n <= 10'.
Thanks for a most helpful explanation
--
https://mail.python.org/mailman/listinfo/python-list
