[Python-ideas] With expressions

[Steven D'Aprano]

On Fri, Aug 03, 2018 at 12:49:24PM +0200, Robert Vanden Eynde wrote:

> Le ven. 3 août 2018 à 03:07, Steven D'Aprano <steve at pearwood.info> a écrit :
> 
> > On Thu, Aug 02, 2018 at 03:13:25PM +0200, Robert Vanden Eynde wrote:
> >
> > > This brings the discussion of variable assignement in Expression.
> > Functional
> > > programming community seems to be more interested in python.
> >
> > I'm not sure what you mean there. Your English grammar is just slightly
> > off, enough to make your meaning unclear, sorry.
> >
> 
> When I say "functional programming", I speak about the paradigm used in
> language like Haskell.

I know what functional programming is. What I don't understand is what 
you mean when you say that the F.P. community "seems to be more 
interested in python". Surely they are more interested in functional 
languages than a multi-paradigm language like Python which does not 
privilege functional idioms over imperative idioms.


[...]
> > try...except exceptions have been proposed before and rejected.
> 
> I'm wondering why, that must have been the same reasons of not accepting
> "with".

Read the PEP. Or the (long!) discussions on Python-Ideas and Python-Dev.

https://www.python.org/dev/peps/pep-0463/


> > > value = (x+y**2 where x,y = (2,4))
> >
> > A "where" *statement* is interesting, but this is not a good example of
> > it. The above is better written in the normal syntax:
> >
> >     value = 2 + 4**2
> 
> 
> That's the discussion we had on the list called "variable assignement in
> expressions". What you did here is inlining the variables, technically it's
> not possible if you're calling a function and using the variable more than
> once.

Which is why I said it was not a good example. If you're going to 
propose syntax, you ought to give good examples, not bad examples.

In any case, this is not a proposal for a "where" expression. You aren't 
going to convince people to add a "with" expression by showing them 
expression forms of "if", "for" or hypothetical "where". Each feature 
must justify itself, not sneak in behind another feature.


[...]
> > > with open('hello') as f:
> > >     lines = f.readlines()
> > > del f  # f is leaked !
> >
> > 99% of the time, I would think that "del f" was a waste of time. If that
> > code is in function, then f will be closed when the "with" block is
> > exited, and garbage collected when the function returns.
> 
> Yes of course, but what if "f" was defined before? We lose its value, even
> if "f" was created only as a temporary variable to have the variables lines.
[...]
> But maybe we are in a script and we have a lots of
> variables? That kind of questions arise, when we wanted a temporary
> variable.

Then don't use f. Use F, fi, fp, fileobj, f_, f1, ϕ, фп, or 
myfileobject. Surely you haven't used them all. There is no shortage of 
useful identifier names.

Or factor your code into named functions with isolated namespaces, so 
the f in one function doesn't clobber the f in another function. 
Structured programming won the debate against unstructured programming a 
long time ago.

https://en.wikipedia.org/wiki/Structured_programming#History


[...]
> One difficultly of finding use cases, it that it's about changing the
> paradigm, probably all cases have a really readable implementation in
> current python / imperative style. But when I see:
> 
> try:
>     a_variable = int(input("..."))
> except ValueError:
>     try:
>        a_variable = fetch_db()
>     except DbError:
>        a_variable = default
> 
> I really think "why can't I put it one one line like I do with if".
> 
> a_variable = (int(input("...")) except ValueError:
>                        fetch_db() except DbError:
>                        default)

Whereas when I see somebody using a double if...else expression in a 
single line, I wish they would spread it out over multiple lines so it 
is readable and understandable, instead of trying to squeeze the maximum 
amount of code per line they can.


> For "with", I'm just wondering "why do I have to indent, it will lose the
> focus of the reader on the result itself".

If this is a problem, then you can easily focus the reader on the 
result by factoring the code into a named function.

    text = read('filename')

requires no indentation, no complicated new syntax, and it is easily 
extensible to more complex examples:

    text = (prefix + (read('filename') or 'default') + moretext).upper()

This argument isn't about whether it might occasionally be useful to use 
a with expression, but whether it is useful *enough* to justify adding 
new syntax to the language.


-- 
Steve