On Tue, 18 Jul 2023 at 14:07, Dom Grigonis wrote:
> PEP505 would solve this nicely, but it only applies to None and would not
> apply to say user-defined sentinels and many other cases where permutations
> of different conditionals arise.
>
PEP 671 would solve this nicely too.
ChrisA
Ok, thanks. I think what I am aiming at is that there is a pool of suggestions
and PEPs that are pointing towards very similar direction and I find myself
often wandering in the same space, just trying to figure out what it exactly is.
It sometimes feels more verbose than it could be for what
On 18/07/23 10:30 am, Dom Grigonis wrote:
Although, the argument that python is meant to be read as english is
very much valid, but I do not see why it has to be an overarching one if
the opportunity cost of it is too great in other dimensions.
It's not overarching. Many things in Python
Much of what you respond to me indicates that you did not properly read what I
have written and did not really understand where I am coming from.
> On 18 Jul 2023, at 04:04, Chris Angelico wrote:
>
> On Tue, 18 Jul 2023 at 10:37, Dom Grigonis wrote:
>> As opposed to
>>
>> if a == 0:
>>
On Tue, 18 Jul 2023 at 10:37, Dom Grigonis wrote:
> 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
>> # 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
On Tue, 18 Jul 2023 at 08:56, Dom Grigonis wrote:
>
> Just to add, I think your statement actually works in my favour rather than
> against my proposal.
>
> People from this group are potentially biased and lack objectivity against
> what I am proposing because they are familiar with python and
On Tue, 18 Jul 2023 at 08:38, Dom Grigonis wrote:
>
> > Was that really the intention? Because I was there when PEP 572 was
> > written, and I don't recall "beautiful one-liners" as one of the
> > justifying reasons. Use around if/while conditions was a strong
> > reason, and yes, that can save a
On Tue, 18 Jul 2023 at 08:34, Dom Grigonis 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
What I meant is that it is not affected by prejudices to such a degree that a
'challenger' wanted to make it look.
“I find it more readable” is a fair statement. The recognition of subjectivity
is very transparent in it. In other words, such statement is not trying to be
bigger than it
Just to add, I think your statement actually works in my favour rather than
against my proposal.
People from this group are potentially biased and lack objectivity against what
I am proposing because they are familiar with python and more experienced ones
participated in “carved in stone”
On Tue, 18 Jul 2023 at 04:37, Dom Grigonis wrote:
> > This is why, I would dare to say that this preference of mine is not
> affected by prejudices.
>
Of course it's affected by prejudices -- all our preferences are. A sample
of one "I find it more readable" is about as useful as any sample of
> Was that really the intention? Because I was there when PEP 572 was
> written, and I don't recall "beautiful one-liners" as one of the
> justifying reasons. Use around if/while conditions was a strong
> reason, and yes, that can save a line, but "beautiful one-liners"
> hasn't generally been a
Ah, I can’t do that post-publish. This will have to suffice for now.
If this got to a point where there was a case to revise 2005 decision or
introduce an alternative (which I very much doubt can happen any time soon),
much more elaborate research and survey would have to be done and all
A bit disappointing, but very much expected. I just though a bit of effort is
worth even for 0.1% probability of success. At least from where I stand, such
change would make a fairly big impact on the things I do, given my expected
relationship with python.
I haven’t studied much of a history
Hello all,
Please Dom Grigonis add choices :
- "No preference" choice to first question
- "I don't know" or "I can't tell" to third question
And I will answer to your poll and probably other people will feel and
do the same.
I agree that question 2 makes me prefer C syntax.
But C is not the
I found the original discussion about the ternary addition, FWIW:
https://mail.python.org/pipermail/python-dev/2005-September/056846.html.
I don't see myself participating in the discussion (maybe it's in a
different thread), but I'm delighted to remember that the message Guido
posted a couple
On Tue, Jul 18, 2023 at 07:09:54AM +1000, Chris Angelico
wrote:
> On Tue, 18 Jul 2023 at 06:43, Dom Grigonis wrote:
[skip]
> > https://q5yitzu62.supersurvey.com
>
> Your second example needs a "both are abhorrently unreadable" option.
+1
[skip]
> ChrisA
Oleg.
--
Oleg Broytman
> Never said C was your first language, only that you're familiar with
> it.
But that is more like an obvious fact about everything rather than a
counter-argument. Your e-mail, at least how I interpreted it, was a fairly
straight forward accent on my strong bias with a flavour of making it an
This ship has sailed and the ternary operator isn't going to change.
Seriously, let it go.
I forget the PEP, but this was well discussed long ago when the ternary was
added. In general, Python prefers words to punctuation symbols for most of
its constructs. So the decision was consistent with
On Tue, 18 Jul 2023 at 06:43, Dom Grigonis wrote:
>
> Hi everyone,
>
> I am not very keen on long discussions on such matter as I do not think there
> is much to discuss: there is no technical complexity in it and it doesn’t
> really change or introduce anything new. It is only a matter of
On Tue, 18 Jul 2023 at 06:40, Dom Grigonis wrote:
>
> We even got a new operator “:=“ to help us with those beautiful one-liners
> (or not) to move towards aesthetics and brevity.
>
Was that really the intention? Because I was there when PEP 572 was
written, and I don't recall "beautiful
On Tue, 18 Jul 2023 at 04:37, Dom Grigonis wrote:
>
> This is NOT a good example, my first language was R, second - python, third
> matlab, etc.
>
> I only became familiar with C/C++ after several years of coding experience.
>
> This is why, I would dare to say that this preference of mine is
Hi everyone,
I am not very keen on long discussions on such matter as I do not think there
is much to discuss: there is no technical complexity in it and it doesn’t
really change or introduce anything new. It is only a matter of opinion &
style/design preferences with respect to logical order
>
> Why are we trying to write one-liners in the first place? Conditional
> expressions are a rare spice that should be used sparingly. No matter the
> syntax, three of them nested together isn't readable code, it's a puzzle.
>
Why are they a rare spice that should be used sparingly? Is it in
On 7/17/23 1:10 PM, Dom Grigonis wrote:
This whole thing started from dict’s `get` extension:
def get_substitute(self, key, default=None, subs=()):
return keyin self ? (self[key] := valin subs? subs[val] : val) :
default
I dare you to do a 1-liner with current if-else.
Why are we
This is NOT a good example, my first language was R, second - python, third
matlab, etc.
I only became familiar with C/C++ after several years of coding experience.
This is why, I would dare to say that this preference of mine is not affected
by prejudices.
> On 17 Jul 2023, at 20:44, Chris
On Tue, 18 Jul 2023 at 03:13, Dom Grigonis wrote:
> Maybe for someone who majored in languages python’s if-else is more easily
> understood. To me, personally, 2nd one is unbearable, while 1st one is fairly
> pleasant and satisfying.
>
This is a REALLY good example of how hard it is to be
On 2023-07-17 18:10, Dom Grigonis wrote:
It does exactly the same as the C version and is more readable. Or am
I missing something?
My point is exactly that it is not easily readable compared to C
version. Also, unnecessarily verbose. The order of components is rather
awkward.
I came to
> It does exactly the same as the C version and is more readable. Or am I
> missing something?
My point is exactly that it is not easily readable compared to C version. Also,
unnecessarily verbose. The order of components is rather awkward.
I came to this, because people seem to want
30 matches
Mail list logo
