[Python-ideas] Re: "Curated" package repo?
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
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: > > 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 > Note also that when the condition is a truthiness check -- admittedly not always the case, but it does occur reasonably often -- this can be simplified further to: result = bar or default > ___ 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/Q3P5AQGQV5FRPEBRPHVNG532BPUK2NPE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "Curated" package repo?
On Sun, Jul 9, 2023, 16:25 Paul Moore wrote: > > > On Sun, 9 Jul 2023 at 15:56, Stephen J. Turnbull < > turnbull.stephen...@u.tsukuba.ac.jp> wrote: > >> James Addison via Python-ideas writes: >> >> > The implementation of such a system could either be centralized or >> > distributed; the trust signals that human users infer from it >> > should always be distributed. >> >> 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. So in practice they'll often want to go >> with some kind of publicly weighted average of scores. >> > > I'll also point out that I'm a long-standing Python developer, and a core > dev, and I still *regularly* get surprised by finding out that community > members that I know and respect are maintainers of projects that I had no > idea they were associated with. Which suggests that I have no idea how many > *other* people who I think of as "just another person" might be maintainers > of key, high-profile projects. So I think that a model based round > weighting results based on "who you trust" would have some rather > unfortunate failure modes. > > 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, 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/
[Python-ideas] Re: "Curated" package repo?
I didn't really address your point there; indirectly mine was to reaffirm a sense that not all participants may want to read the opinions of others while learning technologies, and that's why I am skeptical of the suggestions to include subjective user ratings of any kind within Python packaging infrastructure. On Sun, Jul 9, 2023, 16:09 James Addison wrote: > On Sun, Jul 9, 2023, 15:52 Stephen J. Turnbull < > turnbull.stephen...@u.tsukuba.ac.jp> wrote: > >> James Addison via Python-ideas writes: >> >> > The implementation of such a system could either be centralized or >> > distributed; the trust signals that human users infer from it >> > should always be distributed. >> >> 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. So in practice they'll often want to go >> with some kind of publicly weighted average of scores. >> >> To avoid the problem of ballot-box stuffing, you could go the way that >> pro sports often do for their All-Star teams: have one vote by anybody >> who cares to register an ID, and another by verified committers, >> including committers from "trusted" projects as well. >> > > As someone who sometimes prefers to learn independently -- even if that > takes longer and may produce unusual perspectives -- I remember learning > web development by reading the source HTML of websites. > > Maybe that wouldn't be the typical way to learn programming -- but given > the volume of successful and important software that exists in the world > today, I think that having that code and the packages that it is composed > of available to learn from would be highly beneficial to maintainers, > educators and students, and other groups as well. > >> ___ 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/DLH44V4UUDUQN6NCMIXSADM6RE27RIEJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "Curated" package repo?
On Sun, Jul 9, 2023, 15:52 Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > James Addison via Python-ideas writes: > > > The implementation of such a system could either be centralized or > > distributed; the trust signals that human users infer from it > > should always be distributed. > > 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. So in practice they'll often want to go > with some kind of publicly weighted average of scores. > > To avoid the problem of ballot-box stuffing, you could go the way that > pro sports often do for their All-Star teams: have one vote by anybody > who cares to register an ID, and another by verified committers, > including committers from "trusted" projects as well. > As someone who sometimes prefers to learn independently -- even if that takes longer and may produce unusual perspectives -- I remember learning web development by reading the source HTML of websites. Maybe that wouldn't be the typical way to learn programming -- but given the volume of successful and important software that exists in the world today, I think that having that code and the packages that it is composed of available to learn from would be highly beneficial to maintainers, educators and students, and other groups as well. > ___ 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/XRPK7LDU3JMP7NBY75SUOHUSHHW33BKA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "Curated" package repo?
On Sun, Jul 9, 2023, 09:13 Chris Angelico wrote: > On Sun, 9 Jul 2023 at 18:06, James Addison via Python-ideas > wrote: > > > > On Sun, 9 Jul 2023 at 02:11, Cameron Simpson wrote: > > > I have always thought that any community scoring system should allow > > > other users to mark up/down other reviewers w.r.t the scores presented. > > > That markup should only affect the scoring as presented to the person > > > doing the markup, like a personal killfile. The idea is that you can > > > have the ratings you see affected by notions that "I trust the opinions > > > of user A" or "I find user B's opinion criteria not useful for my > > > criteria". > > > > That sounds to me like the basis of a distributed trust network, and > > could be useful. > > > > Why distributed? This sounded more like a centralized system, but one > where you can "ignore reviews from this user" for any other user. > The implementation of such a system could either be centralized or distributed; the trust signals that human users infer from it should always be distributed. And I'd argue that it's more difficult to guarantee that the trust presented to all participants is fair and accurate in either a centralized or a proprietary system. > ___ 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/LAVE5SWYASATB7H3D4CAKZOCZX4GT3SW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "Curated" package repo?
On Sun, 9 Jul 2023 at 02:11, Cameron Simpson wrote: > > On 04Jul2023 17:21, Christopher Barker wrote: > >3) A rating system built into PyPi -- This could be a combination of > >two > >things: > > A - Automated analysis -- download stats, dependency stats, release > >frequency, etc, etc, etc. > > B - Community ratings -- upvotes. stars, whatever. > > > >If done well, that could be very useful -- search on PyPi listed by rating. > >However -- :done well" ios a huge challenge -- I don't think there's a way > >to do the automated system right, and community scoring can be abused > >pretty easily. But maybe folks smarter than me could make it work with one > >or both of these approaches. > > I have always thought that any community scoring system should allow > other users to mark up/down other reviewers w.r.t the scores presented. > That markup should only affect the scoring as presented to the person > doing the markup, like a personal killfile. The idea is that you can > have the ratings you see affected by notions that "I trust the opinions > of user A" or "I find user B's opinion criteria not useful for my > criteria". > > Of course the "ignore user B" has some of the same downsides as trying > individually ignore certain spam sources: good for a single "bad" actor > (by my personal criteria) to ignore their (apparent) gaming of the > ratings but not good for a swarm of robots. Hi Cameron, That sounds to me like the basis of a distributed trust network, and could be useful. Some thoughts from experience working with Python (and other ecosystem) packages: after getting to know the usernames of developers and publishers of packages, I think that much of that trust can be learned by individuals without the assistance of technology -- that is to say, people begin to recognize authors that they trust, and authors that they don't. How to provide reassurance that each author's identity remains the same between modifications to packages/code is a related challenge, though. FWIW, I don't really like many of the common multi-factor authentication systems used today, because I don't like seeing barriers to expression emerge, even when the intent is benevolent. I'm not sure I yet have better alternatives to suggest, though. Your message also helped me clarify why I don't like embedding any review information at all within packaging ecosystems -- regardless of whether transitive trust is additionally available in the form of reviews. The reason is that I would prefer to see end-to-end transparent supply chain integrity for almost all, if not all, software products. I'm typing this in a GMail web interface, but I do not believe that many people have access to all of the source code for the version that I'm using. If everyone did, and if that source included strong dependency hashes to indicate the dependencies used -- similar to the way that pip-tools[1] can write a persistent record of a dependency set, allowing the same dependencies to be inspected and installed by others -- then people could begin to build their own mental models of what packages -- and what specific versions of those packages -- are worth trusting. In other words: if all of the software and bill-of-materials for it became open and published, and could be constructed reproducibly[2], then social trust would emerge without a requirement for reviews. That would not be mutually-exclusive with the presence of reviews -- verbal, written, or otherwise -- elsewhere. Thanks, James [1] - https://github.com/jazzband/pip-tools/ [2] - https://www.reproducible-builds.org/ ___ 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/OOPIHTBTJFHYVJLJVYHWAK4EPYKP6YBH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "Curated" package repo?
On Thu, Jul 6, 2023, 14:22 James Addison wrote: > I agree, we should encourage or await a single organization to reimplement > a packaging ecosystem with a slightly different set of properties that > continue to provide them with editor biasing, preventing eventual global > consensus and system neutrality. > > Is your time available to help build it? > I'd like to apologise for this comment; I don't think that I argued in good faith here. I was frustrated by a sense that many of the more straightforward attempts to make improvements in packaging ecosystems are, in themselves, a reinvention of previously-existing wheels, often producing similarly wonky spokes to previous attempts that result in repeated off-course journeys that, given enough knowledge of the history of technology, seem predictable. To observe that and then to go on to suggest that we simply wait for the next wonky wheel builder doesn't seem like genuine progress, and I should neither argue for that nor ask whether other people want to spend their own valuable time on it. On Thu, Jul 6, 2023, 14:17 Gregory Disney > wrote: > >> why do people insist on reinventing the wheel? Blockchain is not the >> answer for adding trust that is verifiable. Code signing is the answer, >> it’s widely accepted and would be useful in cases of trusted computing and >> other security use cases. >> >> I don’t want to load a hash table to load a third party module on a UEFI >> interface. >> >> On Thu, Jul 6, 2023 at 9:11 AM James Addison via Python-ideas < >> python-ideas@python.org> wrote: >> >>> On Wed, Jul 5, 2023, 19:06 Chris Angelico wrote: >>> >>>> On Thu, 6 Jul 2023 at 03:57, James Addison via Python-ideas >>>> wrote: >>>> > I also agree with a later reply about avoiding the murkier side of >>>> blockchains / etc. That said, it seems to me (again, sample size one >>>> anecdata) that creating a more levelled playing field for package >>>> publication could benefit from the use of some distributed technologies. >>>> Even HTTP mirrors are, arguably, a basic form of that.. there's at least >>>> one question related to recency of data, though. Delaying availability of >>>> a package to an audience -- if it's important enough -- could under some >>>> circumstances become effectively similar to censorship. >>>> > >>>> >>>> A blockchain won't solve anything here. It would be completely and >>>> utterly impractical to put the packages themselves into a blockchain, >>>> so all you'd have is the index, and that means it's just a bad version >>>> of PyPI's own single-page index. >>>> >>>> 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/PTIS3HZHJSFV7ETWE7UP4HKXS4WN2OEO/ >>>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >>> >>> Mostly agreed. A distributed hash table or similar, though, could be >>> appropriate in combination with ideas similar to the accreting layers of >>> self-reinforcing consensus that some blockchain technologies provide. >>> ___ >>> 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/I3CDZAXGYVS33DJ4JEENGYMF4MY6BQ7O/ >>> 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/KAKBDC3WSSUKCAY24SMABP3GIVXXEILD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "Curated" package repo?
I agree, we should encourage or await a single organization to reimplement a packaging ecosystem with a slightly different set of properties that continue to provide them with editor biasing, preventing eventual global consensus and system neutrality. Is your time available to help build it? On Thu, Jul 6, 2023, 14:17 Gregory Disney wrote: > why do people insist on reinventing the wheel? Blockchain is not the > answer for adding trust that is verifiable. Code signing is the answer, > it’s widely accepted and would be useful in cases of trusted computing and > other security use cases. > > I don’t want to load a hash table to load a third party module on a UEFI > interface. > > On Thu, Jul 6, 2023 at 9:11 AM James Addison via Python-ideas < > python-ideas@python.org> wrote: > >> On Wed, Jul 5, 2023, 19:06 Chris Angelico wrote: >> >>> On Thu, 6 Jul 2023 at 03:57, James Addison via Python-ideas >>> wrote: >>> > I also agree with a later reply about avoiding the murkier side of >>> blockchains / etc. That said, it seems to me (again, sample size one >>> anecdata) that creating a more levelled playing field for package >>> publication could benefit from the use of some distributed technologies. >>> Even HTTP mirrors are, arguably, a basic form of that.. there's at least >>> one question related to recency of data, though. Delaying availability of >>> a package to an audience -- if it's important enough -- could under some >>> circumstances become effectively similar to censorship. >>> > >>> >>> A blockchain won't solve anything here. It would be completely and >>> utterly impractical to put the packages themselves into a blockchain, >>> so all you'd have is the index, and that means it's just a bad version >>> of PyPI's own single-page index. >>> >>> 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/PTIS3HZHJSFV7ETWE7UP4HKXS4WN2OEO/ >>> Code of Conduct: http://python.org/psf/codeofconduct/ >> >> >> Mostly agreed. A distributed hash table or similar, though, could be >> appropriate in combination with ideas similar to the accreting layers of >> self-reinforcing consensus that some blockchain technologies provide. >> ___ >> 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/I3CDZAXGYVS33DJ4JEENGYMF4MY6BQ7O/ >> 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/YS3UQFENIAX7GGXD2KCJ3GHZJJJV3KLM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "Curated" package repo?
On Wed, Jul 5, 2023, 19:06 Chris Angelico wrote: > On Thu, 6 Jul 2023 at 03:57, James Addison via Python-ideas > wrote: > > I also agree with a later reply about avoiding the murkier side of > blockchains / etc. That said, it seems to me (again, sample size one > anecdata) that creating a more levelled playing field for package > publication could benefit from the use of some distributed technologies. > Even HTTP mirrors are, arguably, a basic form of that.. there's at least > one question related to recency of data, though. Delaying availability of > a package to an audience -- if it's important enough -- could under some > circumstances become effectively similar to censorship. > > > > A blockchain won't solve anything here. It would be completely and > utterly impractical to put the packages themselves into a blockchain, > so all you'd have is the index, and that means it's just a bad version > of PyPI's own single-page index. > > 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/PTIS3HZHJSFV7ETWE7UP4HKXS4WN2OEO/ > Code of Conduct: http://python.org/psf/codeofconduct/ Mostly agreed. A distributed hash table or similar, though, could be appropriate in combination with ideas similar to the accreting layers of self-reinforcing consensus that some blockchain technologies provide. ___ 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/I3CDZAXGYVS33DJ4JEENGYMF4MY6BQ7O/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "Curated" package repo?
On Wed, Jul 5, 2023, 01:24 Christopher Barker wrote: > Stating a new thread with a correct title. > > On 2 Jul 2023, at 10:12, Paul Moore wrote: > > Unfortunately, too much of this discussion is framed as “someone should”, >> or “it would be good if”. No-one is saying “I will”. Naming groups, like >> “the PyPA should” doesn’t help either - groups don’t do things, people do. >> Who in the PyPA? Me? Nope, sorry, I don’t have the time or interest - I’d >> *use* a curated index, I sure as heck couldn’t *create* one. > > > Well, I started this topic, and I don't *think* I ever wrote "someone > should", and I certainly didn't write "PyPa should". > > But whatever I or anyone else wrote, my intention was to discuss what > might be done to address what I think is a real problem/limitation in the > discoverability of useful packages for Python. > > And I think of it not so much as "someone should" but as "it would be nice > to have". > > Of course, any of these ideas would take a lot of work to implement -- > and even though there are a lot of folks, on this list and elsewhere, > that would like to help, I don't think any substantial open-source project > has gotten anywhere without a concerted effort by a very small group (often > just 1) of people doing a lot of work to get it to a useful state before a > larger group can contribute. So I"m fully aware that nothings going to > happen unless *someone* really puts the work in up front. That someone > *might* be me, but I'm really good at over-committing myself, and not so > great at keeping my nose to the grindstone, so > > And I think this particular problem calls for a solution that would have > to be pretty well established before reaching critical mass to actually be > useful -- after all, we already have PyPi -- why go anywhere else that is > less comprehensive? > > All that being said, it's still worth having a conversation about what a > good solution might look like -- there are a lot of options, and hashing > out some of the ideas might inspire someone to rise to the occasion. > > The :problem", as I see it. > > - The Python standard library is not, and will never be fully > comprehensive -- most projects require *some* third party packages. > - There are a LOT of packages available on PyPi -- with a very wide range > of usefulness, quality and maintenance -- everything from widely used > packages with a huge community (e.g. numpy) to packages that are release > 0.0.1, and never seen an update, and may not even work. > > So the odds that there's a package that does what you need are good, but > it can be pretty hard to find them sometimes -- and can be a fair bit > of work to sift through to find the good ones -- and many folks don't feel > qualified to do so. > > This can result in two opposite consequences: > > 1) People using a package that really isn't reliable or maintained (or not > supported on all platforms, or ..) and getting stuck with it (I've had that > on some of my projects -- I'm pretty careful, but not everyone on my team > is) > > 2) People writing their own code - wasting time, and maybe not getting a > very good solution either. I've also had that problem on my projects... > > To avoid this -- SOME way for folks to find packages that have at least > has some level of vetting would be good -- exactly what level of vetting, > is a very open question, but I think "even a little" could be very helpful. > Doesn't each individual / team / company / organization already discuss and document their preferred packages, and (indirectly or directly) help to evolve them and consider alternatives by doing so? I think it's important that there's a common space where packages can exist and be available. Whether that realtime environment should state its' own preferred packages seems more debatable to me - because it could become a source of contention and gaming similar to search engine optimization. An exception could be software museums: I can see a curated collection of best-known and most-effective libraries used by particular cultures at points-in-time being of interest to future (and some current?) generations. I also agree with a later reply about avoiding the murkier side of blockchains / etc. That said, it seems to me (again, sample size one anecdata) that creating a more levelled playing field for package publication could benefit from the use of some distributed technologies. Even HTTP mirrors are, arguably, a basic form of that.. there's at least one question related to recency of data, though. Delaying availability of a package to an audience -- if it's important enough -- could under some circumstances become effectively similar to censorship. A few ideas that have come up in the previous thread -- more or less in > order of level of effort. > > 1) A "clearing house" of package reviews, for lack of a better word -- a > single web site that would point to various resources on the internet -- > blog posts, etc, that would
[Python-ideas] Re: len(Enum) should raise TypeError
Hi Richard, On Tue, 4 Apr 2023 at 12:49, Richard Hajek wrote: > > I encountered that Enum having a len hid a mistake on my part. If len(Enum) > raised, my mistake would be immediately apparent, however at the end of the > day, my mistake was easily found. Can any Python linting tools (such as pylint) detect a potential problem with the code? Thanks, James ___ 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/QGKXR35IWKPH44QFXKJNZCNFRNE6JJTX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Proposal: -X importcache to supplement -X importtime for loaded modules
On Wed, 15 Feb 2023 at 02:06, Inada Naoki wrote: > > `-X importtime=2` > > This is expert-only tool. So no need for verbose name. +1 that re-using existing parameter names is both concise and also convenient. However: do we have an opportunity to make the parameter _value_ both concise and also memorable? `-X importtime` # existing behaviour (backwards-compatible) `-X importtime=initial` # existing behaviour (memorable) `-X importtime=all` # record timing for every import that happens, including cases when the module is retrieved from cache Regards, James ___ 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/7EDKPWPNYHDRGET575B5MKTVN4G4THPX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Combinations of keywords
On Tue, 21 Feb 2023 at 11:29, Steven D'Aprano wrote:
> Trying to squeeze many lines of code into one line is a bad idea.
Agreed, in most cases - but there can be (no pun intended.. probably)
exceptions to that.
if cloudy or raining:
print("Bring an umbrella")
else:
print("Looks fair out")
In rare cases, vertical screen space -- and/or even file read and
program performance -- can be affected by the number of lines required
to represent a module.
On Mon, 20 Feb 2023 at 15:03, Otomatyk dupont wrote:
>> #import A_WINDOW_MODULE and import A_UNIX_MODULE if except
Here's an attempt to rephrase this slightly, with the following ideas in mind:
* Reduce parser ambiguity
* Support filtering based on specific exception classes
* Rephrase the code to read more closely like natural language
>>> try import A_WINDOW_MODULE but import A_UNIX_MODULE on ImportError
>>> try value = int(x[2]) but value = 0 on IndexError, ValueError
___
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/UKAP4NDEWRKI2KC6XBQJOUWQC6CIIQQY/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Multiple arguments to str.partition and bytes.partition
On Sun, 8 Jan 2023 at 20:20, dn wrote: > > (and hence earlier illustration/question: does the sep belong with the > string forming the left-side of that partition, or the 'right'?) There's no connection implied between each separator and the partitions that surround it in the results. In the username/host case, the '@' in 'user@host' isn't instrinsically linked to either the username or hostname component. (another way to think of it is like a meal-break during a work-day; the meal-break doesn't belong to either the part of the day preceding or the part of the day after the break) > Why limit the implementation to the same sequence as the separators are > expressed in the method-call? > > ie why should the order in which the separator arguments were expressed > necessarily imply the same order-of-appearance in the subject-string? There are two reasons for this, one consumer-side and one implementation-side: 1. It discourages consumers from attempting to partition strings with ambiguously-ordered delimiters 1. It allows the arguments to be scanned (iterated) exactly-once while the input is scanned (also iterated) exactly-once ___ 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/MU4ZSUIIEKTZYQ3CWPD4WOV4POEHDVLX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Multiple arguments to str.partition and bytes.partition
On Sun, 8 Jan 2023 at 08:32, Stephen J. Turnbull
wrote:
>
> Steven D'Aprano writes:
>
> > On Sat, Jan 07, 2023 at 10:48:48AM -0800, Peter Ludemann wrote:
> > > You can get almost the same result using pattern matching. For example,
> your
> > > "foo:bar;baz".partition(":", ";")
> > > can be done by a well-known matching idiom:
> > > re.match(r'([^:]*):([^;]*);(.*)', 'foo:bar;baz').groups()
>
> > I think that the regex solution is also wrong because it requires you
> > to know *exactly* what order the separators are found in the source
> > string.
>
> But that's characteristic of many examples. In "structured" mail
> headers like Content-Type, you want the separators to come in the
> order ':', '=', ';'. In a URI scheme with an authority component, you
> want them in the order '@', ':'.
+1 (while also recognising the caveats you mention subsequently)
> Except that you don't, in both those
> examples. In Content-Type, the '=' is optional, and there may be
> multiple ';'. In authority, the existing ':' is optional, and there's
> an optional ':' to separate password from username before the '@'.
Trying to avoid the usual discussions about permissive parsing /
supporting various implementations in-the-wild: long-term, the least
ambiguous and most computationally-efficient environment would
probably want to reduce special cases like that? (both in-data and
in-code)
> user, _, domain = "example.com".partition('@')
>
> does the wrong thing!
Yep - it's important to choose partition arguments (I'm
mostly-resisting the temptation to call them a 'pattern') that are
appropriate for the input.
Structural pattern matching _seems_ like it could correspond here, in
terms of selecting appropriate arguments -- but it is, as I understand
it, limited to at-most-one wildcard pattern per match (by sensible
design).
> I would prefer "one bite per call" partition
> to a partition at multiple points.
That does seem clearer - and clearer is, generally, probably better.
I suppose an analysis (that I don't have the ability to perform
easily) could be to determine how many regular expression codesites
could be migrated compatibly and beneficially by using
multiple-partition-arguments.
___
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/GLOHDOCG7K3BMDCO7N2Y5BD3SP2X3FSW/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Multiple arguments to str.partition and bytes.partition
On Sun, 8 Jan 2023 at 13:20, Barry Scott wrote:
> Maybe combine the ideas by allowing a tuple where a string is used.
> 'a=b;c'.partition('=', (':',';')) => ('a', '=', b, ';', 'c')
I like that idea - and it seems to fit neatly with the existing
partition contract: the inclusion of the matched-delimiter as an item
in the result-tuple would reduce match ambiguity (rationale: imagining
a use case where a caller would like to provide multiple delimiters
during method invocation, and then subsequently check which delimiter
was used at a given match position).
Since it's both orthogonal to (does not depend-on, nor is it a
dependency-of) multiple-partition-arguments and composible with (can
be combined with) multiple-partition-arguments, perhaps it should be
advocated-for as a separate proposal? (rationale: that would allow
either proposal to advance without delaying the other -- bearing in
mind a hopefully-unlikely chance of merge conflicts if they reach
release-readiness implementation status in parallel)
___
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/5BZWICH7CSJHHGT7XOPVANF74Q4WG7RN/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Multiple arguments to str.partition and bytes.partition
On Sun, 8 Jan 2023 at 03:44, Steven D'Aprano wrote:
>
> Keep it nice and simple: provided with multiple separators, `partition`
> will split the string on the first separator found in the source string.
>
> In other words, `source.partition(a, b, c, d)` will split on a /or/ b
> /or/ c /or/ d, whichever comes first on the left.
Thanks - that's a valid and similar proposal -- partition-by-any-of --
although it's not the suggestion that I had in mind.
Roughly speaking, the goal I had in mind was to take an input that
contains well-defined delimiters in a known order and to produce a
sequence of partitions (and separating delimiters) from that input.
(you and dn have also indirectly highlighted a potential problem with
the partitioning algorithm: how would "foo?a=b&c" partition when using
'str.partition("?", "#")'? would it return a tuple of length five?)
___
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/6DNT7S46SZCQNFKXXBKD5PQ557KQRKEP/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Multiple arguments to str.partition and bytes.partition
Hi folks,
I'd like to gather some feedback on a feature suggestion to extend
str.partition and bytes.partition to support multiple arguments. Please find
the feature described below.
# Feature or enhancement
The str.partition[1] method -- and similarly the bytes.partition[2] method --
is useful when dividing an input into subcomponents while returning a tuple of
deterministic length (currently 3) and potentially retaining the delimiters.
The feature described here adds support for multiple positional arguments to
those methods.
The first positional argument would be applied to the input instance that the
method is called from -- no change from existing behaviour.
Subsequent positional arguments would be applied to the rightmost component of
the previous application of the partition algorithm.
So, for example, in pseudocode:
### Single-argument case (matching existing behaviour)
>>> "foo:bar".partition(":")
>>> # partition 'foo:bar' using ':'
>>> - result = ['foo', ':', 'bar']
>>> # all positional arguments consumed
>>> - return result
### Multiple-argument case (added feature)
>>> "foo:bar;baz".partition(":", ";")
>>> # partition 'foo:bar;baz' using ':'
>>> - result = ['foo', ':', 'bar;baz']
>>> # positional arguments remain; continue
>>> # partition 'bar;baz' using ';'
>>> - result = ['foo', ':', 'bar', ';', 'baz']
>>> # all positional arguments consumed
>>> - return result
# Pitch
Multiple-partition-arguments would provide a shorthand / syntactic sugar to
abbreviate the process of separating inputs with known-delimeters into
components.
For example:
>>> login_string = 'username@hostname:2001'
>>> username, _, hostname, _, port = login_string.partition('@', ':')
Beneficially for the caller, the number of tuple elements can be determined
based on the number of positional arguments. For n arguments, a tuple of length
2n + 1 will be returned.
Thank you for any and all feedback.
James
[1] - https://docs.python.org/3/library/stdtypes.html#str.partition
[2] - https://docs.python.org/3/library/stdtypes.html#bytes.partition
___
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/LEQPGCSAHHG6SFHC5AHCVI7XCX6S4WBW/
Code of Conduct: http://python.org/psf/codeofconduct/
