I am well aware of that.
I just argue that it is not very pleasant to read.
Personally, I am not a big user of it.
C’s although maybe doesn’t have words to read, but is much more pleasant in
both conciseness and logical sequence.
Maybe it is not a big issue for others, but if C’s style conditi
On Sat, 15 Jul 2023 at 21:09, Dom Grigonis wrote:
> So I would vote for something similar to:
>
> result = bar is None ? default : bar
>
>
result = default if bar is None else bar
Python has a conditional expression already.
Paul
___
Python-ideas maili
Just to add. I haven’t thought about evaluation. Thus, to prevent evaluation of
unnecessary code, introduction of C-style expression is needed anyways:
> 1. result = bar is None ? default : bar
The below would have to evaluate all arguments, thus not achieving benefits of
PEP505.
> 2. result = i
> I understand your perspective, but the fact is that this makes the code
> lengthier and adds an extra step to what I am already trying to do.
> Additionally, if I understand correctly, I could implement a built-in method
> as a function that takes in the key and uses a try-except block to get
On Sun, 16 Jul 2023 at 04:07, Jothir Adithyan wrote:
>
> Chris Angelico wrote:
> > On Tue, 11 Jul 2023 at 08:05, Jothir Adithyan adithyanjot...@gmail.com
> > wrote:
> > > Assumptions:
> > > The problem statement is based on a few assumptions:
> > >
> > > You prefer chaining `get` statements for c
def fu(bar, default=1):
bar = bar or default
return bar
print(fu(None)) # 1 - as expected
print(fu(2)) # 2 - as expected
print(fu(0)) # 1 - not as expected
class A:
def __bool__(self):
return False
print(fu(A()) # 1 - not as expected
So it onl
Dom Grigonis wrote:
> I like this. Something that I would use for sure.
> I have used a lot of:
> ```
> (value: None | object ) or default
> ```
> , but I stopped for obvious reasons. However, I miss those days, when I was
> ignorant that this is not a good idea.
> > On 11 Jul 2023, at 01:17, Davi
Chris Angelico wrote:
> On Tue, 11 Jul 2023 at 08:05, Jothir Adithyan adithyanjot...@gmail.com wrote:
> > Assumptions:
> > The problem statement is based on a few assumptions:
> >
> > You prefer chaining `get` statements for cleaner code.
> > You expect at least some of the `get` methods to return
Dom Grigonis wrote:
> This feels superfluous. Instead of creating new dict class I would propose
> either:
> 1. Not to have None values
> a) It is most likely possible to pre-delete all None values before you use
> the dict = {k: v for k, v in dict if v is not None}
> b) Not to create them in
