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/

Reply via email to