> > > > > A with-statement is great for when you care about the > implementation details. Somebody has to care about the process of > opening a file, reading from it and closing it. But when you *don't* > care about those implementation details, a simple interface like a > read() function is superior to a with-statement, *or* a with-expression, > which shoves those details in your face. >
Totally agree. In the case where you care about the implementation details. You can explain to a beginner: something = (f.read() with open('...') as f) Is another way to write: with open('filename') as f: something = f.read() Exactly like the ternary if. And I agree that because with is often relevant for "implementation details" or beginning use as a "enter.. exit' statement (like a cpp destructor), it matches more imperative programming. with stack.push_matrix(Scale(4)): triangle = draw_triangle_using(stack) Is used for it's "enter/close" functionality, but can still be used like: triangle = (draw_triangle_using(stack) with stack.push_matrix(Scale(4)) as NotUsed) But the "as close" is useless here. > > > and in most cases when > > reading the code you then have to look at the function to see if > > anything else is done there. > > I doubt that many people really spend a lot of time digging into > functions to see whether they do more than what they say. Unless and > until I ran into unexpected problems, I'd be no more inclined to look > into a function called "read" than I would be to do the same to len or > math.sin. I'm sure it does what it says it does. > Fair point, the "def" statements generally are passed when read so they don't really count as overhead.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/