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/
