[Python-ideas] Re: "Curated" package repo?

[Stephen J. Turnbull]

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 compared to the
review site or the curation very much: some poor rodent(s) still gotta
put the dinger on the feline.

However, in designing those pages, we could explicitly ask for names
of similar packages and recommendations for use cases where an
alternative package might be preferred, and provide links to the
review pages for those packages that are mentioned in the response.
We can also provide suggestions based on comparisons other users have
made.  (Hopefully there won't be too many comparisons like "this
package is the numpy of its category" -- that's hard to parse!)

 > Additionally perhaps the users could give relative valuation,

Not sure asking for rankings is a great idea, globally valid rankings
are rare -- ask any heavy numpy user who occasionally uses the sum
builtin on lists.

 > for example there are A, B, C, D similar packages, users could say:
 > I tried out A and B, and found that A is better then B, and could
 > have some valuation categories: simple, easy, powerful etc. This
 > would show for example that package A is simple, but B is more
 > powerful

These tags would be useful.  I think the explanation needs to be
considered carefully, because absolutes don't really exist, and if
you're comparing to the class, you want to know which packages the
reviewer is comparing to.  I'm not sure many users would go to the
trouble of providing full rankings, even for the packages they've
mentioned.  Worth a try though!

Steve

___
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/MGYK3EEEYKISRQMFJY7U73ID6VBQY4AT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Dom Grigonis]

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 maximum of tuple sums… Elegantly.

But one needs 3 lines of code to resolve default value.

This is an exaggeration, but serves to convey my point.

But again, this is not about this individual case. This thread has started from 
new dict.get method, and not by me. I am just trying to see what is the common 
factor as similar problems have been bothering me too.

To me by now, it is about custom user expressions.

—Nothing ever dies, just enters the state of deferred evaluation—
Dg

> On 24 Jul 2023, at 18:17, Chris Angelico  wrote:
> 
> 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
>> dim4 - frequency of usage
>> dim5 - ...
>> 
> 
> Don't think I fully understand, but aren't three out of those four
> just different forms of brevity? Is that really so important to you?
> 
> 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/6RF4PMZAZQM74OKWCX5HP7ZN5B4Z5C5U/
> 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/YQVMMSOCDWS5IFVZKY7Z42OD74WGV2NH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Chris Angelico]

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
> dim4 - frequency of usage
> dim5 - ...
>

Don't think I fully understand, but aren't three out of those four
just different forms of brevity? Is that really so important to you?

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/6RF4PMZAZQM74OKWCX5HP7ZN5B4Z5C5U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Dom Grigonis]

> 
> 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 actually show a real-world example, it's hard to 
> discuss the *actual* trade-offs.

First library that comes to mind, which has a high level constructor: 
https://github.com/pydata/xarray/blob/main/xarray/core/dataarray.py#L437 


> It's often an anti-pattern to have a function with that many arguments in the 
> first place, so refactoring the code may be a better option).
It often is, but at the same time unavoidable in some cases, i.e. high level 
APIs. Few examples, CLIs (e.g. poetry), constructors of high level objects.

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
dim4 - frequency of usage
dim5 - ...

Of course, not all dimensions can be quantified. And to quantify some of them 
certain definitions would have to be decided on, e.g. what is an operation. 
Also, I do not know what those dimensions should be, they would ideally be 
decided by those who have a very good sense of python’s long-term vision.

Such information could be helpful in having productive discussions regarding 
such considerations and proposals.

In this case I am concerned with a balance of brevity vs complexity of python 
constructs, which is a core building block in a space of constantly increasing 
number of abstraction layers.


—Nothing ever dies, just enters the state of deferred evaluation—
DG___
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/RKMCQSJB36V2WGKABKKEB5SRB6YLIIXA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: "Curated" package repo?

[Chris Angelico]

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 popular and have passed some sort of vetting procedure.
>

Okay, but can you tell me what this vetting procedure proves that
isn't already proven by mere popularity itself?

> For instance, for a very long time Python2 was far more popular than Python3, 
> but any expert in the field would encourage users to move to Python3 sooner 
> rather than later. Python2 is popular, but it wouldn't have made the cut on 
> some expert-curated list.
>

Experts were divided for a very long time. I'm not sure what your
point is here. And are you also saying that packages should be
*removed* from this curated list? Because if so, what's the mechanic
for this? (Python 2 absolutely WOULD have made the cut on any
expert-curated list prior to Python 3's inception.)

> So it helps in that it reranks popular packages (and also excludes some) for 
> those who want to adopt a more strict security / reliability posture.
>
> By no means do I think this would replace pypi as the de-facto packaging 
> repository. Its low barrier to entry is extremely important for a thriving 
> community, but I also wouldn't mind having something a bit more robust.
>
> I also think this project would have to careful not to become yet another 
> "awsome-python-package" collection. Those certainly have value, but based on 
> the initial proposal, I'm interested in something a tad more robust.
>

More robust in what way? What exactly are the requirements to be part
of this list? Will all experts agree? If not, how is it different from
"yet another collection"?

(Also, PLEASE don't top-post. There's no value in it. Show what you're
responding to.)

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/HCTAH2YI2F3AX5POPKMLNJVYKJ7NJPNB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: "Curated" package repo?

[George Fischhof]

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 both popular and have passed some sort of vetting procedure.
>
> For instance, for a very long time Python2 was far more popular than
> Python3, but any expert in the field would encourage users to move to
> Python3 sooner rather than later. Python2 is popular, but it wouldn't have
> made the cut on some expert-curated list.
>
> So it helps in that it reranks popular packages (and also excludes some)
> for those who want to adopt a more strict security / reliability posture.
>
> By no means do I think this would replace pypi as the de-facto packaging
> repository. Its low barrier to entry is extremely important for a thriving
> community, but I also wouldn't mind having something a bit more robust.
>
> I also think this project would have to careful not to become yet another
> "awsome-python-package" collection. Those certainly have value, but based
> on the initial proposal, I'm interested in something a tad more robust.
>
>
... some old stuff cut ...

Hi Folks,

it has got to my mind that even just grouping similar / same goal packages
could help the current situation.
Unfortunately searching by name or category is not enough, and takes much
time.
By linking similar packages together would give the users the possibility
to evaluate all / several of them.

Additionally perhaps the users could give relative valuation, for example
there are A, B, C, D similar packages, users could say: I tried out A and
B, and found that A is better then B, and could have some valuation
categories: simple, easy, powerful etc. This would show for example that
package A is simple, but B is more powerful

BR,
George
___
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/OIX5GLWSJORZXS4DET3YJGKQR7IUFYUE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: "Curated" package repo?

[Jonathan Crall]

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 instance, for a very long time Python2 was far more popular than
Python3, but any expert in the field would encourage users to move to
Python3 sooner rather than later. Python2 is popular, but it wouldn't have
made the cut on some expert-curated list.

So it helps in that it reranks popular packages (and also excludes some)
for those who want to adopt a more strict security / reliability posture.

By no means do I think this would replace pypi as the de-facto packaging
repository. Its low barrier to entry is extremely important for a thriving
community, but I also wouldn't mind having something a bit more robust.

I also think this project would have to careful not to become yet another
"awsome-python-package" collection. Those certainly have value, but based
on the initial proposal, I'm interested in something a tad more robust.

On Mon, Jul 24, 2023 at 8:55 AM Chris Angelico  wrote:

> 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
> system: popular packages are inherently favoured. And we can already
> get a list of popular packages, because download stats are available.
> So how would this scheme help?
>
> 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/LU6BFQGNCMZZVESCUUCPSVKWPKJEJB7H/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
-Dr. Jon Crall (him)
___
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/WRF6VSZ47KMGJI3PZEWBQCHFFGYE7AJ2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: "Curated" package repo?

[Chris Angelico]

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
system: popular packages are inherently favoured. And we can already
get a list of popular packages, because download stats are available.
So how would this scheme help?

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/LU6BFQGNCMZZVESCUUCPSVKWPKJEJB7H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: "Curated" package repo?

[James Addison via Python-ideas]

On Sun, Jul 9, 2023, 23:35 Christopher Barker  wrote:

> On Sun, Jul 9, 2023 at 8:37 AM James Addison via Python-ideas <
> python-ideas@python.org> 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 Guido
 van Rossum or Egg Rando more.
>>>
>>>
> There are 718,155 users on PyPi -- I can't imagine that trying to figure
> out which of those hundreds of thousands of users you trust for
> reviews would be at all helpful -- it simply doesn't scale.
>

The page https://levien.com/free/tmetric-HOWTO.html has 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!

I suppose if my fantasy "curated" site existed, and the curation group
> were of a manageable size, then you could do that, but the point of having
> a modest number of curators is that you can already trust them ;-)
>
> Honestly, I'd be more likely to go with "I can assume that projects that
>>> are dependencies of other projects that I already know are good quality,
>>> are themselves good quality". Which excludes people from the
>>> equation altogether,
>>>
>>
> I there are a number of metrics that could be used -- and "how many
> projects" use this projecct as a dependency" is a good one. -- "which"
> projects would be even stronger. And there are others.
>
> Anything like that it can be gamed, but I"m not sure that's as huge a
> problem as it might be -- what is the incentive to game this system? this
> is all open source, no one's making money, and frankly, having a lot of
> users can be a burden as well!
>
> Sure, many of us would really like a lot of people to use our code, but
> the incentives to cheat to get more users really aren't that strong. -- at
> least if. you can filter out the malware in some other way.
>
> -CHB
>
>
>
>
>
>
>> but which falls apart when I'm looking for a library in a new area.
>>>
>>> Paul
>>>
>>
>> Cautious +1, since PageRank did pretty well for a good stint in a
>> somewhat analogous environment.
>>
>>> ___
>> 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/J5RH7ZGWO23APG42E6ZU5QPRXMYKJ7W4/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
>
___
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/REXQPXKI3IUB3Z5XZ2UTG6WLKWJLOVB5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[Paul Moore]

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:
result = default

Seriously, what is the obsession with putting things on one line here?

If it's because "it works better when there is a long list of such
assignments" then unless you actually show a real-world example, it's hard
to discuss the *actual* trade-offs. And typically with a real-world
example, there are a lot more options available (for example, if this is
defaulting a series of arguments to a function, it's often an anti-pattern
to have a function with that many arguments in the first place, so
refactoring the code may be a better option).

Paul
___
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/7QE4CV2ZXNWAVFLVPXOYBB224447UFNL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposal for get_or function in Python dictionaries

[anthony.flury via Python-ideas]

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 is clever 
enough to diagnose all possible side effects of calling bar() twice, or 
even detect that bar can be cached, so it will always be called twice.


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.


-- 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 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 
achieving benefits of PEP505.




2. result = ifelse(bar is None, default, bar)







So I would vote for something similar to:




result = bar is None ? default : bar






Where default and bar is only evaluated if needed. Although 
not to the extent as initially intended, it would offer 
satisfiable solutions to several proposals.



  Well, default is only evaluated if needed; bar is always 
evaluated.

 What is wrong with the Python equivalent

 result = default if bar is None else bar
 or if you prefer
 result = bar if bar is not None else default

 Perhaps you didn't know about this construction?
 It does exactly the same as the C version and is more readable. 
Or am I missing something?

 Best wishes
 Rob Cliffe
 ___
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/4QBAYBAT6EZFILNS2MCK3D6XW4LNRDZ5/ 

Code of Conduct: http://python.org/psf/codeofconduct/ 



-- Anthony Fluryanthony.fl...@btinternet.com
___
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/552SFNHUTBOON7FHZQLSKKIQNO6ELEGS/
Code of Conduct: http://python.org/psf/codeofconduct/