The challenge with anything like
result = default if bar is None else bar
or
result = bar if bar else default
or even
result = bar is None ? default : bar
is that sure default is only evaluated once - but in all cases 'bar' is
evaluated twice, and if bar is a function call then no parser
On Mon, 24 Jul 2023 at 10:31, anthony.flury via Python-ideas <
[email protected]> 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:
On Sun, Jul 9, 2023, 23:35 Christopher Barker wrote:
> On Sun, Jul 9, 2023 at 8:37 AM James Addison via Python-ideas <
> [email protected]> wrote:
>
>> ISTM the primary use cases advanced here have been for "naive" users.
Likely they won't be in a position to decide whether they trust
On Mon, 24 Jul 2023 at 21:02, James Addison via Python-ideas
wrote:
> ... some thoughts on how to build a scalable, resilient trust network based
> on user ratings; I can't guarantee that it'll change your opinion, though!
>
This still has the fundamental problems of any sort of user rating
syst
If popular packages weren't favored that would be a problem. Popularity
should be correlated with "trustworthiness" or whatever the metric this
curated repo seeks to maximize. I think the important thing is that the
packages are both popular and have passed some sort of vetting procedure.
For inst
Jonathan Crall ezt írta (időpont: 2023. júl. 24., H,
15:29):
> If popular packages weren't favored that would be a problem. Popularity
> should be correlated with "trustworthiness" or whatever the metric this
> curated repo seeks to maximize. I think the important thing is that the
> packages are
On Mon, 24 Jul 2023 at 23:28, Jonathan Crall wrote:
>
> If popular packages weren't favored that would be a problem. Popularity
> should be correlated with "trustworthiness" or whatever the metric this
> curated repo seeks to maximize. I think the important thing is that the
> packages are both
>
> 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 actual
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
> di
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 max
George Fischhof writes:
[For heaven's sake, trim! You expressed your ideas very clearly, the
quote adds little to them.]
> it has got to my mind that even just grouping similar / same goal
> packages could help the current situation.
This is a good idea. I doubt it reduces the problem compar
11 matches
Mail list logo
