[Python-ideas] With expressions

[Robert Vanden Eynde]

This brings the discussion of variable assignement in Expression. Functional
programming community seems to be more interested in python.

lines = (f.readlines() with open('hello') as f)
digit = (int('hello') except ValueError: 5)
value = (x+y**2 where x,y = (2,4))
values = [x+y**2 for x in range(5) for y in range(7)]
values = [x+y**2 for x,y in product (range(5), range(7))]
y = 5 if condition else 2
y = (lambda x: x+2)(x=5)

vs

with open('hello') as f:
    lines = f.readlines()
del f  # f is leaked !

x,y = 2,4
value = x+y**2
del x, y  # x,y are leaked !

try:
    digit = (int('hello')
except ValueError:
    digit = 5

if condition:
    y = 5
else:
    y = 2

def f(x):
    return x+2
y = f(x=2)
del f  # we want an anonymous function !

Those "oneliners" is not only the will to be quicker in interactive mode,
it's the way functional programming Thinks.

If we add one, it's Logical to add the others to be consistent.

Of course, one can always write functions like read_text but the ide of
those construction is like the lambda, we want anonymous.

Le jeu. 2 août 2018 à 13:56, Steven D'Aprano <steve at pearwood.info> a écrit :

> 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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180802/390f7f66/attachment-0001.html>