>> # Code becomes easily read when there is a nice alignment in horizontal >> space. e.g.: >> >> variable = None >> length_1 = None >> somethin = None >> > > variable = length_1 = somethin = None
Obviously they would not all be None, just chosen None as `any dummy value`, mistake on my part - None is not suitable for that. >> foo = var1 if a == 0 else default >> bar = variable2 if a == 0 else default2 >> >> # As opposed to >> >> foo = a == 0 ? var1 : default >> bar = a == 0 ? variable2 : default2 > > As opposed to > > if a == 0: > foo, bar = var1, variable2 > else: > foo, bar = default, default2 Again, one is `a == 0`, another is `b == 0`. I didn’t do a good job conveying this did I… Will try to be more precise and leave less room for misinterpretation. foo = foo3 if foo2 == 0 else default bar = barbarbar if bar2 == 0 else default2 # As opposed to foo = foo2 == 0 ? foo3 : default bar = bar2 == 0 ? barbarbar : default2 >> From what I have gathered, these: >> https://peps.python.org/pep-0505/ >> https://peps.python.org/pep-0463/ >> , and certain number of proposals in this group at their root are pointing >> approximately to the same direction. I.e. some things are too verbose (and >> too many lines of code) given the simplicity of what is needed to be done. > > Both of those are about *expressiveness*. This is not the same thing > as compactness. The two do sometimes align but the purpose is > different. I don’t think it is that easy to draw the line here. Everything in both of those PEPs can be expressed using current constructs. So maybe they are about more compact expressions? Same as proposal regarding more expressive dict.get from which my train of thought has started. Is it a request for: a) more expressive dict.get? b) more concise way do what can be done in a several lines of code anyways? I just can’t see any substance that you are coming from with this… Was python made for conciseness or expressiveness? Everything it does can already be done in C isn’t it? So I would argue any abstraction is really more about conciseness. Expressiveness is more about incorporation of what is already there, but not in the abstraction, i.e. extension. But python being interpreted language written in another language, I really FAIL to see how is all of this NOT about conciseness and modularity? I agree that there are other dimensions, but I always thought python being closer to unix than windows... > On 18 Jul 2023, at 03:08, Chris Angelico <ros...@gmail.com> wrote: > > On Tue, 18 Jul 2023 at 08:34, Dom Grigonis <dom.grigo...@gmail.com> wrote: >> >> I still feel that compared to list comprehension and other functional and >> elegant python constructs, python's if-else expression is lacking. I often >> choose to go multi-line much more verbose code as opposed to more brief >> constructs just because it becomes unreadable - a more elegant and logically >> convenient expression would change the decision ratio significantly, at >> least for me. >> > > You choose to go multi-line because the one-liner becomes less > readable? Then that's a win for the current system. This is NOT a > problem to be solved. Everything is working correctly. You have chosen > the readable option over the compact one! > >> # Code becomes easily read when there is a nice alignment in horizontal >> space. e.g.: >> >> variable = None >> length_1 = None >> somethin = None >> > > variable = length_1 = somethin = None > >> # I often take this into account on variable name selection. Now: > > Poor choice IMO. You could have had more consistent variable names by > taking advantage of chained assignment. > >> foo = var1 if a == 0 else default >> bar = variable2 if a == 0 else default2 >> >> # As opposed to >> >> foo = a == 0 ? var1 : default >> bar = a == 0 ? variable2 : default2 > > As opposed to > > if a == 0: > foo, bar = var1, variable2 > else: > foo, bar = default, default2 > >> From what I have gathered, these: >> https://peps.python.org/pep-0505/ >> https://peps.python.org/pep-0463/ >> , and certain number of proposals in this group at their root are pointing >> approximately to the same direction. I.e. some things are too verbose (and >> too many lines of code) given the simplicity of what is needed to be done. > > Both of those are about *expressiveness*. This is not the same thing > as compactness. The two do sometimes align but the purpose is > different. > >> https://peps.python.org/pep-0308/#detailed-results-of-voting >> It seems that C’s expression was ranked 2nd most favourable… The decision >> was 3rd. This kinda suggests that I am not as delusional as I initially >> thought I might appear to be with this... >> > > Like I said, people who are *already familiar with* C's syntax find it > more comfortable than those who are not. > > But also - this ship has sailed. There's not a lot of point discussing > this. If Python had decided against having any conditional expression, > then maybe you could reopen the discussion (and I'll be honest, it > would have been reopened already by now); but we have a perfectly good > conditional expression, so the chances of getting a duplicate syntax > added are slim to Buckley's. Adding another way of writing the same > thing doesn't materially improve expressiveness. > > ChrisA > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/DUPGM2O6WWC64XDIMVKJ6OUHTW7KQBM7/ > Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3CKT74RKKVBEEMTQYUEUCQ6WIQ5ULQNG/ Code of Conduct: http://python.org/psf/codeofconduct/
