[Python-Dev] Re: Having Sorted Containers in stdlib?
I'll join Christopher Barker and Chris Angelico in voicing scepticism -- personally, I feel like I'm yet to be persuaded that the use case is strong enough. sortedcontainers is a wonderful package, and I would completely support a prominent link to the library in the Python documentation. But the use case seems too niche and specific, in my opinion, for the library to be added to the standard library. I see the standard library as a collection of basic building blocks that can be used to create a multitude of other things. sortedcontainers feel like a specialised solution to a small collection of problems, rather than a general solution to a large collection of problems. PyPI feels like the right place for this library. Best, Alex On Thu, Nov 11, 2021 at 12:33 PM Paul Moore wrote: > On Thu, 11 Nov 2021 at 11:51, Antoine Pitrou wrote: > > > > On Wed, 10 Nov 2021 21:12:17 -0600 > > Tim Peters wrote: > > > [Bob Fang ] > > > > This is a modest proposal to consider having sorted containers > > > > (http://www.grantjenks.com/docs/sortedcontainers/) in standard > library. > > > > > > +1 from me, but if and only if Grant Jenks (its author) wants that too. > > > > > > It's first-rate code in all respects, including that it's a fine > > > example _of_ Python programming (it's not written in C - in Python). > > > > Agreed with Tim. This is a perfect example of some basic and perennial > > facility that would fit very well in the stdlib. > > I agree as well. Is anyone interested enough to ask the library author > if he supports doing this? That seems to be the main unanswered > question here. > > But if anyone wants to argue the "the stdlib should be shrinking, not > growing" position, I suggest they do so *before* someone reaches out > to the module author. No point in us making the suggestion and then > being forced to withdraw it. > > Paul > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/5SURNB4C5FGJ6LSXUPVW2EFP22ERKSGB/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EM3CCN2YNKVUUQIGNXE5XIIR5TJKSTCZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Increase of Spammy PRs and PR reviews
Nikita found a very real (and slightly embarrassing!) bug in a patch I wrote for the enum module a few months back, due to his efforts to improve test coverage. And there is an entire section of the DevGuide devoted to "Improving test coverage", stating that PRs such as the ones Nikita has been filing are valuable.I have seen multiple PRs by other authors closed or criticised because they tried to change things in too many modules at once, or make "broad and sweeping" changes. Nikita, however, has always taken care to make his PRs easy to review, by keeping them small and focused.His mentor has already stated that he specifically asked Nikita to cc him in whenever he filed PRs (and I certainly didn't get a "bad impression about his intentions" from the fact he was cc'ing in his mentor, which seems like a very reasonable thing for a new member of the triage team to do).I'm only a triager (like Nikita), but I really don't see any problem here, personally.Best wishes, Alex Original message From: Nikita Sobolev Date: 01/02/2022 04:14 (GMT+00:00) To: python-dev@python.org Subject: [Python-Dev] Re: Increase of Spammy PRs and PR reviews Hi, my name is Nikita and I think that I am the person behind these spammy PRs.Link: https://github.com/python/cpython/pulls/sobolevnFirst of all, Lrupert, sorry for all the noise and inconvenience I caused to you personally and to other community members! This totally was **not** my intention. You could have reached out to me earlier via email or directly in some PR to share your concerns, maybe we could have this whole situation avoided.Secondly, thanks for letting me know about how others might feel about my work. Feedback is always important. I hope I can learn a lot from this case.But, I can tell you honestly that I've never been to a situation like this before and I don't know exactly how to handle it and what to improve in this specific case.Third, I agree that almost all my PRs were about some trivial things. Mostly because I was reading through typeshed code (which requires looking through multiple CPython modules at a very high level) and test code for these modules where I've spotted quite a lot of details to fix.I cannot obviously judge the quality of my work (except for being ok-ish), so I will leave this part out of scope. The only thing I can say here is that it's a bit sad thread to read on python-dev mailing list, but I will keep my optimism for the future :)So, to sum things up:- I am open to any feedback: if others also think that my work does not bring any value - this is fine! I can totally improve or work on something simpler / some other project. Anyone interested can write me a direct email: m...@sobolevn.me- I am sorry for causing this thread. It is far from being a pleasant or technical readBest Regards,Nikita Sobolevhttps://github.com/sobolevn___Python-Dev mailing list -- python-dev@python.orgTo unsubscribe send an email to python-dev-leave@python.orghttps://mail.python.org/mailman3/lists/python-dev.python.org/Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LF7V3ZASXK6DGD5MBBXP3YKHGOLW36D5/Code of Conduct: http://python.org/psf/codeofconduct/___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/S772DSPACD6346E7TIG5EL47CBQ4JWU6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Restrict the type of __slots__
I'm +1 on disallowing strings specifically. The unexpected behaviour that ensues if you try to iterate over a class's slots is a footgun that I've trodden on a few times, and it's always been annoying. But I don't see any particular reason to disallow any other kind of iterable, and I'm definitely -1 on disallowing using a dictionary for __slots__. Using a dictionary for __slots__ as a way to document attributes is a feature I very much like. Best, Alex > On 18 Mar 2022, at 20:59, Guido van Rossum wrote: > > >> On Fri, Mar 18, 2022 at 9:40 AM Paul Bryan wrote: >>> On Fri, 2022-03-18 at 09:35 -0700, Guido van Rossum wrote: >>> The motivation has been explained already. >> >> In this thread? > > Yes, Eric's message. > >>> What on earth did your test do that got a speedup by using sets? Was it >>> repeatedly checking whether a variable was in a slot? The other thing this >>> does is rearrange the order in which slots appear from run to run (since >>> set order is affected by hash randomization) and you might have gotten >>> lucky with a popular attribute being moved to the front, where it's more >>> likely to be in the memory cache already (cache lines being 64 bytes and >>> pointers being 8 bytes nowadays). >> >> I created objects in a tight loop, populating attributes, noting the elapsed >> time. > > It does not make sense that that is correlated to the type of __slots__, > since __slots__ is not used for instance creation at all (it is only used to > create the class). I stick to my likely explanation. > > Regarding Serhiy's proposal, I'm +0 on disallowing strings, and +0 on > disallowing things that can't be reiterated (but it's not a problem in > practice). Given other responses the status quo is likely best. > > -- > --Guido van Rossum (python.org/~guido) > Pronouns: he/him (why is my pronoun here?) > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/EYZ32GBU4QUTRPU26BDCYYMKG4GX633N/ > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PO32SWLW27Y2MUWROXD7UUPTUTXTDEEE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]
There's also the "Experts index" in the devguide: https://devguide.python.org/experts/#expertsBest, Alex Original message From: Skip Montanaro Date: 29/03/2022 22:36 (GMT+00:00) To: "Eric V. Smith" Cc: Python Dev Subject: [Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module] There's the CODEOWNERS file: https://github.com/python/cpython/blob/main/.github/CODEOWNERSThanks. Never would have thought there was such a thing. I was looking for files with "maintain" in them. Skimming it, it would seem that most of the stuff in Lib or Modules isn't really associated with a particular person or small group.Skip ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/CN7SXNP2D4ML4U2OBIUC4DGQOKEYNSKE/ Code of Conduct: http://python.org/psf/codeofconduct/
