On Thu, Aug 02, 2018 at 11:35:11AM +0200, Ken Hilton wrote: > Where this would benefit: I think the major use case is `f.read() with > open('file') as f`. [...] > Therefore `f.read() with open('file') as f`, I think, would be much > welcomed as the best way to read a file in an expression.
Perhaps so, but do we want to encourage that to the point of adding syntax to make it easier? f.read() is a (mild) code-smell. Unless your file is guaranteed to be smaller than the amount of free memory, it risks starting your OS thrashing. IMO that makes this an idiom only suitable for quick and dirty scripts where the the user knows the limitations of the script and can abide by them. (In these days of computers with multiple gigabytes of RAM, reading in an entire file is not as risky as it used to be. But on the other hand, in these days of terrabyte and even petabyte storage devices, there are more *really large* files too.) Don't get me wrong -- f.read() is not necessarily bad. I often write scripts that slurp in an entire file at once, but they're typically throw-away scripts, and I'm also the user of the script and I know not to call it on files above a certain size. (As Miss Piggy once said, "Never eat more in one sitting than you can lift.") But I'm not sure if this sort of thing is something we want to *encourage* rather than merely *allow*. Best practice for reading files is, after all, a with statement for a reason: we expect to read text files line by line, often wrapped in a try...except to handle exceptions. For your use-case, I suspect the best thing is a utility function: def read(name, size=-1, **kwargs): with open(name, **kwargs) as f: return f.read(size) Not every three-line function needs to be a built-in, let alone given syntax :-) > For those wondering about the scope semantics of the "as NAME", I think > they would be identical to the scope semantics of the "for" expression Its not really a "for expression" -- its a *comprehension*, which is much more than merely a for expression: # this isn't legal result = for x in seq One important difference is that unlike this proposed "with" expression, comprehensions have an obvious pair of delimiters which enclose the expression and give it a natural beginning and end. There's no need to memorise arcane operator precedences and parsing rules to work out where the "with...as" variable will be legal. Another important difference is that while there are good reasons for putting comprehension loop variables in their own sub-local scope, I don't see any such benefit to doing the same for this proposed with expression. I don't think we should encourage the proliferation of more and more layers of extra scopes. We already have six: sublocal (comprehensions) local nonlocal (enclosing functions) class global (module) builtins Let's be cautious about adding more varieties of sublocal scope. -- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/