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 <st...@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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
