2 of them are forms of brevity.
To me the whole picture is important. And the context as well.
Individual aspect becomes more important when it feels to be an outlier.
I.e.
In 1 line one can create a dictionary, initialise it with reasonable keys and
2-values tuples and find the key of the
On Tue, 25 Jul 2023 at 01:03, Dom Grigonis wrote:
> I think what would be nice to have is a set of dimensions that are deemed to
> be of importance when deciding on a language constructs.
> plot(dim1, dim2, dim3)
> dim1 - number of lines
> dim2 - number of terms
> dim3 - number of operations
>
>
> Seriously, what is the obsession with putting things on one line here?
>
There is no obsession. It is more of a consideration of balance between
operation complexity vs its verbosity.
> If it's because "it works better when there is a long list of such
> assignments" then unless you
On Mon, 24 Jul 2023 at 10:31, anthony.flury via Python-ideas <
python-ideas@python.org> wrote:
> In Python then a better way might be
>
> result = temp := bar() if temp else default
>
> This way only bar() and default are evaluated and invoked once.
>
Or
result = bar()
if not result:
once.
-- Original Message --
From: "Rob Cliffe via Python-ideas"
To: "Dom Grigonis" ; "Jothir Adithyan"
Cc: python-ideas@python.org
Sent: Monday, 17 Jul, 23 At 16:09
Subject: [Python-ideas] Re: Proposal for get_or function in Python
dictionaries
On
On Thu, 20 Jul 2023 at 22:27, Stephen J. Turnbull
wrote:
>
> Chris Angelico writes:
> > On Thu, 20 Jul 2023 at 15:33, Stephen J. Turnbull
> > wrote:
>
> C'mon Chris, "that was then, this is now". Catch up, I've changed my
> position. ;-)
>
That's fair :) Maybe I'll dust off that proposal
Chris Angelico writes:
> On Thu, 20 Jul 2023 at 15:33, Stephen J. Turnbull
> wrote:
C'mon Chris, "that was then, this is now". Catch up, I've changed my
position. ;-)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an
Ok, this is tricky.
So pretty much impossible, given that `Break`, if it was to work has to be
evaluated in reference scope, while other delayed objects in their definition
scope.
--
Back to deferred evaluation.
--
Giving it a rest for a while. Thank you
On Thu, 20 Jul 2023 at 19:34, Dom Grigonis wrote:
> And ideally, adding 2 builtin(or imported from stdlib) functions: `Break` and
> `Continue`, which if called act as `break` and `continue` statements.
>
How would they work? Would every function call have to provide the
possibility to return to
I have looked more properly at deferred evaluation and late-bound defaults.
Deferred-eval is overkill for what I need and isn’t likely to come about soon,
while deferred only solves a very small part of what I am looking at. Also, it
lacks ability to enforce default from outside, which is a bit
On Thu, 20 Jul 2023 at 18:16, Greg Ewing wrote:
>
> On 20/07/23 6:30 pm, James Addison via Python-ideas wrote:
> > result = default if bar is None else bar
> > or if you prefer
> > result = bar if bar is not None else default
>
> Would it shut anyone up if we had another logical
On 20/07/23 6:30 pm, James Addison via Python-ideas wrote:
result = default if bar is None else bar
or if you prefer
result = bar if bar is not None else default
Would it shut anyone up if we had another logical operator:
x otherwise y
equivalent to
x if x is not None
On Thu, 20 Jul 2023 at 17:09, Dom Grigonis wrote:
>
> On 20 Jul 2023, at 09:48, anthony.flury wrote:
> In Python then a better way might be
>
> result = temp := bar() if temp else default
>
> This way only bar() and default are evaluated and invoked once.
>
I presume you want a more complicated
From: "Rob Cliffe via Python-ideas" <mailto:python-ideas@python.org>>
> To: "Dom Grigonis" mailto:dom.grigo...@gmail.com>>;
> "Jothir Adithyan" mailto:adithyanjot...@gmail.com>>
> Cc: python-ideas@python.org <mailto:python-ideas@python.org>
&g
On Thu, 20 Jul 2023 at 15:33, Stephen J. Turnbull
wrote:
> I didn't like that PEP then; I was in the camp of "let's get genuine
> Deferreds, and use them to cover some of the use cases for PEP 671."
You're almost certainly never going to get that, because "genuine
Deferreds", as well as being
> result = bar or default
I used to do this, but dropped this habit. Just to be on the safe side if in
the future I extend bar to take value for which truth test evaluates to False.
And for consistency across the codebase.
___
Python-ideas mailing
> I think that's reasonable. But I don't think Python is the language
> for that. There are too much existing contrasts, such as loop vs.
> comprehension and conditional statement vs. ternary expression. Guido
> deliberately chose to vary those expression syntaxes from their
> statement
On Thu, Jul 20, 2023, 01:19 Rob Cliffe via Python-ideas <
python-ideas@python.org> wrote:
>
>
> On 15/07/2023 21:08, Dom Grigonis wrote:
>
> Just to add. I haven’t thought about evaluation. Thus, to prevent
> evaluation of unnecessary code, introduction of C-style expression is
> needed anyways:
Dom Grigonis writes:
> The thing I am not content with (to make it common practice in my
> coding style) is inconsistencies between a) order of terms
> and b) functionality, of statements and their analogous
> expressions.
I think that's reasonable. But I don't think Python is the language
On 15/07/2023 21:08, Dom Grigonis wrote:
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
I understand.
As I have already said, I am not exactly proposing more terse if-else
expression. It’s just where I got to going down the path of several PEPs,
proposals and my own 'struggles’.
My point was more along the lines, that these are the examples, where several
users and PEP writers
Dom Grigonis writes:
> > But "encourages one-liners" is generally considered an
> > anti-pattern in Python. Let's see why,
> Here I am a bit confused, how is this the case in the language
> containing list comprehensions?
I don't think of list comprehensions in terms of line count. I
Ok, fair I am confusing definitions.
Expressiveness, defined by modern dictionary: “the quality of effectively
conveying a thought or feeling”.
Let me correct myself.
Although I see that expressiveness is important, I think variable:
Functionality / verbosity - can be as important.
> On 18
On Wed, 19 Jul 2023 at 06:41, Dom Grigonis wrote:
>
> When you put it from this perspective, it seems to make sense, however, I do
> not agree.
>
> To me, from first principles it seems it’s all about condensing more
> complexity in smaller modular packages.
>
> That is why I am a bit confused,
When you put it from this perspective, it seems to make sense, however, I do
not agree.
To me, from first principles it seems it’s all about condensing more complexity
in smaller modular packages.
Leaving modularity aside, condensing more complexity in smaller packages in
programming area is
On Tue, 18 Jul 2023 at 16:13, Dom Grigonis wrote:
> To me, they are in the inverse relationship.
>
> Terseness ~ 1 / expressiveness.
>
No, they are unrelated (in general).
Terseness is nothing more than "can I use fewer characters?" and is almost
always the wrong thing to do in isolation (yes,
To me, saying it’s about expressiveness but not brevity sounds similar to e.g.
“we are in compliance with green policies of EU, but we are not making effort
to save nature.”
Well, you might not consciously intend to save nature, but those who gave you
presentation about green legislation had
To me, they are in the inverse relationship.
Terseness ~ 1 / expressiveness.
Maybe I am not getting something.
But surely if list comprehension took 5 lines to write, it wouldn’t be
justifiable? So, even if implicit, brevity and its relation to complexity is
always a factor.
> On 18 Jul
> A plain async function pretty much IS a generator, but without the
> risk of removing the last await point and having the function stop
> being a generator.
I am still lost in async space. From my initial benchmarking it seems that the
complexity that async is introducing hardly justifies
On Wed, 19 Jul 2023 at 00:55, Dom Grigonis wrote:
> Here I am a bit confused, how is this the case in the language containing
> list comprehensions?
>
Do you understand the difference between expressiveness and terseness?
You still seem to be focused on the completely wrong thing here. List
Thanks for reply,
I can see most of what you have written.
> But "encourages one-liners" is generally considered an anti-pattern in
> Python. Let's see why,
Here I am a bit confused, how is this the case in the language containing list
comprehensions?
I would understand if it was swapped with
On Tue, 18 Jul 2023 at 23:41, Stephen J. Turnbull
wrote:
> 2. Comparing floats, even against zero, is a bad idea. So I would
> wrap them in math.isclose:
>
> val = a ? (not isclose(c, 0) ? c : d) : (not isclose(d, 0) ? d : c)
That's overly simplistic; there are a lot of times when it's
Dom Grigonis writes:
> I came to this, because people seem to want one-liners for certain
> things and what I came up with is that maybe more concise if-else
> expression could help.
But "encourages one-liners" is generally considered an anti-pattern in
Python. Let's see why,
> # Fairly
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
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
> 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
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
>
> 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
On 15 Jul 2023, at 23:14, Dom Grigonis wrote: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
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
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
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 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
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
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,
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
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
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, David Mertz, Ph.D. 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 the first place (if it depends
This is basically PEP 505 – None-aware operators (
https://peps.python.org/pep-0505/).
I've generally been opposed to that, but clearly some serious and smart
Pythonistas have supported it. That PEP is a bigger lift than your
suggestion, but correspondingly more general.
On Mon, Jul 10, 2023,
On Tue, 11 Jul 2023 at 08:05, Jothir Adithyan 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 `None`.
> - You want to avoid the hassle of using
62 matches
Mail list logo
