> 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. > > Just a personal feeling, it's not really thought out.
> > 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/ > > > I'm reading it. The prelude at the beginning then says there are no convincing use case if I get it right? > > 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. > When showing toy examples I thought some people would think "indeed, that happens to me often". > 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. > Indeed, I'm talking about it because I think it all relates to "expressionalize simple statements", that's also why I speak about FP, because that's an "expression-first" paradigm. > > 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 > > > [...] Of course I would do that, i completely agree that refactoring is useful, but as shown in the end of my post: filename = compute_filename(...) lines = compute_lines(...) parsed_data = compute_parsed_data(...) The functions body being a bit too small to be refactored and doesn't really have another meaning of "code to compute filename", I feel like the "filename =" already catches the idea, I feel like repeating myself (DRY). And the function body in those cases is not very reusable so it doesn't make sense to give it a meaningful name. I would do a named function otherwise indeed. > > 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. > Multiline is clearly better yes. When I say 'one line' I'm just saying "using the expression-statement but probably gonna span it on multiple lines because the Expressions are not short. > > > 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. > For 'with', as you all say, it really boils down to finding use cases other than "file manipulation". It's true I can't think of any (expect the fact it does create a function that may not have a meaningful name). > > -- > 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/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
