[Python-Dev] Re: [python-committers] Sad news from Zurich

May he rest in peace, I can't even fathom the impact PIL has had on Python over the years. On Fri, Dec 10, 2021 at 3:20 PM Guido van Rossum wrote: > A former core dev who works at Google just passed the news that Fredrik > Lundh (also known as Effbot) has died. > > Fredrik was an early Python

[Python-Dev] Re: peps, devguide, voters repositories: master branch renamed to main

Thanks for the update! Although possibly a minor inconvenience to some, I am certainly of the belief that our choice in language has a subtle, yet powerful effect on our perception of the world around us, so although some may see it as needless, I think small changes such as "master" to "main" are

[Python-Dev] Re: Please be careful about changing PEPs post-submission to the SC

FWIW that seems like a reasonable approach, at least to me. On Thu, Nov 18, 2021, 5:29 PM Guido van Rossum wrote: > I know PEP 646 was one of these. In our defense, we *did* notify the SC > that there was a pending issue ( >

[Python-Dev] Re: Remove asyncore, asynchat and smtpd modules

I think it would be fine to wait just one release, until 3.12. Makes no substantial maintenance difference and maybe easier for users with more advanced notice, especially for module removal. I also wonder if maybe we should scale delay between dep -> removal based on maintenance burden estimate,

[Python-Dev] Re: The Steering Council elections.

On Mon, Nov 15, 2021 at 10:49 AM Thomas Wouters wrote: > > Just a reminder that the nomination period for the next SC ends *today* > (AoE), so if you're intending to nominate (yourself or someone else), > please get those posts in. (No need for a long post before the deadline, it > can be

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On Sat, Nov 13, 2021 at 5:04 PM wrote: > > > def 횑퓮햑풍표(): > > try: > > 픥e헅핝횘︴ = "Hello" > > 함픬r퓵ᵈ﹎ = "World" > > ᵖ햗퐢혯퓽(f"{헵ｅ퓵픩º_}, {햜ₒ풓lⅆ︴}!") > > except 퓣핪ᵖｅ햤헿ᵣ햔횛 as ⅇ헑c: > > 풑rℹₙₜ("failed: {}".핗헼ʳᵐªｔ(ᵉ퐱퓬)) > > > > if _︴ⁿ퓪푚핖__ == "__main__": > >

[Python-Dev] Re: pre-PEP: Unicode Security Considerations for Python

I'd suggest both: briefer, easier to read write up for average user in docs, more details/semantics in informational PEP. Thanks for working on this, Petr! On Tue, Nov 2, 2021 at 2:07 PM David Mertz, Ph.D. wrote: > This is an amazing document, Petr. Really great work! > > I think I agree with

[Python-Dev] Re: Bug fixed in the bugs.python.org OAuth-based authentication: user logged as the wrong account

Thanks for the fix! This could have caused some serious issues, so glad we were able to address it ahead of time. On Mon, Sep 13, 2021 at 5:06 AM Victor Stinner wrote: > Hi, > > A bug has been identified and *fixed* in the OAuth-based > authentication code used on the Python bug tracker

[Python-Dev] Re: python-dev thread w/ Marco Sulla

I can agree with the general premise of what Antoine is saying, but to me even as a non-participant, the following quote from the thread Brett linked seems a clear CoC violation: I repeat, even the worst AI will understand from the context what I meant. > But let me do a very rude example: > >

[Python-Dev] Re: Bug report

On Wed, Jul 21, 2021 at 12:19 PM Nguyen Do Minh Duc < gd.minhduc1...@gmail.com> wrote: > Hi, > > When I find what's new in 3.10 beta in > https://docs.python.org/whatsnew/3.10.html > It redirected me to https://docs.python.org/3/whatsnew/3.10.html which > shows 404 error not found nginx. Can you

[Python-Dev] Re: Is the Python review process flawed?

On Thu, Jul 1, 2021 at 10:49 AM Victor Stinner wrote: > What happens usually is that some modules have no maintainer. Once you > merge a single change in a module, boom! You are now the new > maintainer for your entire life time! More and more people will ask > you to look at their "very

[Python-Dev] Re: Why list.sort() uses mergesort and not timsort?

On Sun, Jun 6, 2021 at 7:09 PM Dan Stromberg wrote: > I've got a comparison of sort algorithms in both Cython and Pure Python > (your choice) at: > https://stromberg.dnsalias.org/~strombrg/sort-comparison/ > ...including a version of timsort that is in Cython or Pure Python. > Thanks for

[Python-Dev] Re: PEP 661: Sentinel Values

As someone who's had to make use of the pattern `_sentinel = object()` a few times within stdlib code, I'd like to give a strong +1 for the proposal to add a new `sentinel()` function. This is much more intuitive, easier to look up, etc. From my experience, it's a common enough pattern to be well

[Python-Dev] Farewell, for now :)

Hi all, Last week, I started a new thread on discuss.python.org about my intention to take a further extended break from open source to continue my mental health healing process. Just wanted to announce it in the other channels as well

[Python-Dev] The importance of mental health

Hey all, In these last few months, I have been in the process of healing from some pretty heavy past trauma. And now that I am on the road to recovery, I want to share my journey with the Python community in hopes that it may reach those that are struggling with their own mental health battles,

[Python-Dev] Re: Please explain how to migrate when a function is removed, thanks ;-)

On Jan 20, 2021 at 9:51 PM Chros Jerdonek wrote: > Is there / would it make sense to have a section analogous to "Porting to > Python X" that covers "Make All DeprecationWarnings Go Away in X"? If we > had such a section, the "Porting to" section could be constructed by > copying the relevant

[Python-Dev] Re: Please explain how to migrate when a function is removed, thanks ;-)

Thanks for bringing attention to this, Victor, and to Ken Jin (GH: Fidget-Spinner) for the PR. I've just completed reviewing and merging the PR, so hopefully anyone affected will now have a more clear idea of how to migrate their asyncio code to 3.10. Having the porting method explicitly

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On Sun, Nov 15, 2020 at 1:56 AM Chris Angelico wrote: > On Sun, Nov 15, 2020 at 4:28 PM Kyle Stanley wrote: > > > > FWIW, I'd like to add my +1 to usage of "as" for spelling class capture > patterns. This is by far the clearest and easiest to read form I've se

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On Sat, Nov 14, 2020 at 7:54 AM Nick Coghlan wrote: > On Sat, 14 Nov 2020 at 09:51, Greg Ewing > wrote: > > > > On 14/11/20 7:45 am, Brandt Bucher wrote: > > > with (using your own syntactic flavor): > > > ``` > > > case >first, *>middle, >last: > > > rebuilt = first, *middle, last > > >

[Python-Dev] Re: Please do not remove random bits of information from the tutorial

Rather than trying to specifically transform the existing tutorial into a guide exclusively aimed at beginners, I think that we should use the guideline of: "Is this useful information in 95% of real-world use cases or does it have a strong niche purpose that will be useful at *some *point for

[Python-Dev] Re: Please do not remove random bits of information from the tutorial

On Sun, Nov 8, 2020 at 8:17 PM Inada Naoki wrote: > OK. Since checking all mails in the long thread is tedious job, I will > pick some up and leave a comment in the b.p.o. > Personally, I think that just linking to the python-dev thread in bpo (and/or PR) is adequate for most cases, especially

[Python-Dev] Re: Who is target reader of tutorial?

I can't speak for all of the members of the upcoming documentation WG, but as someone that will be on it (based on our discussions at the recent core dev sprint), my personal vote would be for keeping it as a comprehensive guide for beginners of Python. Detailed enough that it covers the

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

+1 to remove support for Solaris going forward. 4 years is plenty of time to wait for someone to volunteer to maintain it, IMO. So my preference would be for option 3 to remove it now, but I wouldn't be opposed to option 2 either w/ deprecating support and waiting a couple versions to remove it.

[Python-Dev] Re: Core Dev Sprint: Collecting Discord usernames

On Fri, Oct 2, 2020 at 2:07 AM Kyle Stanley wrote: > Prior to joining Python Discord, I recommend checking out the Discord > setup guide that I recently finished: > https://python-core-sprint-2020.readthedocs.io/communication.html#discord-setup-guide. > The part on the priv

[Python-Dev] Core Dev Sprint: Collecting Discord usernames

87A9Y9. As a reminder, potential participants include Python core developers, triagers, and those in a core dev mentorship. If you haven't already signed up and are interested in attending, please do so at https://forms.gle/fhzJdpRHR4GtSRCk9. Regards, Kyle Stanley _

[Python-Dev] Re: Doc tests failing for many PRs on GitHub

Thanks for reverting the setuptools version Ned, and to Victor for opening a PR to make the fix for the latest version. I'm always amazed by the efforts made and quick responses to keep things running smoothly. :-) On Tue, Sep 1, 2020 at 5:56 AM Ned Deily wrote: > On Sep 1, 2020, at 05:47, Ned

[Python-Dev] RSVP: 2020 Python Core Dev Sprint

limitation, but for the purposes of scheduling the best possible times for everyone, it is requested that participants do so at their earliest convenience. Regards, Kyle Stanley ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send

[Python-Dev] Re: Pay for PR review and merging for VxWorks RTOS

What exactly does the PR involve? Is it a relatively simple compatibility patch or something that adds significant amounts of platform-specific code? The former can be reviewed (and potentially merged) by any core dev knowledgeable in the areas being changed, but the latter requires long-term

[Python-Dev] Re: [OT] I'm unsubscribing from this tire fire (formerly known as python-dev)

> > I'm using my mailer's "ignore thread" feature and counting on the fact > that the flamers will eventually exhaust themselves (most already have). > Yep, not all threads are going to be equally worthwhile for everyone to read. If a thread is going nowhere productive, the best course of action

[Python-Dev] Re: Recent PEP-8 change

> Basically, it feels like we were lied to. And if that wasn't bad enough, to see that Guido accepted that vitriolic commit message and merged it in ... it makes me embarrassed to be a Python supporter. Only Guido could attest to this, but as someone who spoke in support of the change, I

[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

I tend to keep out of these types of discussions because they have a tendency to be rather polarizing, and when introduced in an unrelated environment (such as python-ideas or python-dev), tend to do nothing other than set people against each other. But, after the above message, I feel obligated

[Python-Dev] Re: PEP 622: Structural Pattern Matching

Thank you very much to Brandt, Tobias, Ivan, Guido, and Talin for the extensive work on this PEP. The attention to detail and effort that went into establishing the real-world usefulness of this feature (such as the many excellent examples and code analysis) helps a lot to justify the complexity

[Python-Dev] Re: When can we remove wchar_t* cache from string?

t more vigilant in ensuring that everyone has had a chance to migrate from those APIs, and delaying the removal if not. On Sun, Jun 14, 2020 at 9:34 PM Inada Naoki wrote: > On Sat, Jun 13, 2020 at 8:20 PM Inada Naoki > wrote: > > > > 2020年6月13日(土) 20:12 Kyle Stanley : > &g

[Python-Dev] Re: When can we remove wchar_t* cache from string?

rnings have already been in place. +1. On Sat, Jun 13, 2020 at 7:20 AM Inada Naoki wrote: > > > 2020年6月13日(土) 20:12 Kyle Stanley : > >> > Additionally, raise DeprecationWarning runtime when these APIs are used. >> >> So, just to clarify, current usage of th

[Python-Dev] Re: When can we remove wchar_t* cache from string?

> Additionally, raise DeprecationWarning runtime when these APIs are used. So, just to clarify, current usage of these 7 unicode APIs does not emit any warnings and would only start doing so in 3.10? If so, I think we may want to consider giving users until 3.12 until they're removed. Especially

[Python-Dev] Re: [python-committers] Please welcome our next Release Manager, Pablo!

> In light of the release of Python 3.9b1, let’s take a moment to celebrate all the great work that our Python 3.8 and 3.9 release manager Łukasz has done. Thank you so much to Łukasz for a fantastic 3.8 release, and for the smooth transition into 3.9 beta. :-) > Please join me in welcoming

[Python-Dev] Re: Deprecate os.removedirs() and os.renames()

Serhiy Storchaka wrote: > I propose to deprecate these functions and remove them in future Python versions. +1, assuming the deprecation lasts for at least two versions and the available alternatives are explicitly mentioned in the What's New entry (for both the version they're initially

[Python-Dev] Re: Comments on PEP 554 (Multiple Interpreters in the Stdlib)

Mark Shannon wrote: > If `run()` can raise > an exception, why not let it return values? If there's not an implementation detail that makes this impractical, I'd like to give my +1 on the `Interpreter.run()` method returning values. From a usability perspective, it seems incredibly convenient to

[Python-Dev] Re: PEP 554 comments

Eric Snow wrote: > We will mark it "provisional" in the docs, which I expect will include > info on what that means and why it is provisional. If you'd like an example format for marking a section of the docs as provisional w/ reST, something like this at the top should suffice (with perhaps

[Python-Dev] Re: Improvement to SimpleNamespace

Raymond Hettinger wrote: > Yes, I get that. Just want to point-out that working with heavily nested dictionaries (typical for JSON) is no fun with square brackets and quotation marks. I can certainly agree with that sentiment, especially when working with something like GraphQL that tends to

[Python-Dev] Re: Improvement to SimpleNamespace

Guido van Rossum wrote: > I've seen this pattern a lot at a past employer, and despite the obvious convenience I've come to see it as an anti-pattern: for people expecting Python semantics it's quite surprising to read code that writes foo.bar and then reads back foo['bar']. Would it be

[Python-Dev] Re: Need help with test_ctypes failing on Windows (test_load_dll_with_flags)

Looking over the commit history for the PR ( https://github.com/python/cpython/pull/18239/commits), it looks like that specific Azure Pipelines failure did not start occurring until upstream/master was merged into the PR branch (

[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name

Ivan Pozdeev wrote: > More information is not better if that information is harmful rather than helpful. While that argument does apply in some cases, I'd have to very much disagree that "" is harmful in comparison to just "1"; it clearly shows the value on the right side of the colon. As for the

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

> -1 on "cut*" (feels too much like what .partition() does) > -0 on "trim*" (this is the name used in .NET instead of "strip", so I > foresee new confusion) > +1 on "remove*" (because this is exactly what it does) I'm also most strongly in favor of "remove*" (out of the above options). I'm

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

lit', 'rstrip', 'split', 'splitlines', 'startswith', 'strip', 'swapcase', 'title', 'translate', 'upper', 'zfill'] On Sun, Mar 22, 2020 at 12:17 AM Kyle Stanley wrote: > Ivan Pozdeez wrote: > > I must note that names conforming to > https://www.python.org/dev/peps/pep-0008/#f

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

Ivan Pozdeez wrote: > I must note that names conforming to https://www.python.org/dev/peps/pep-0008/#function-and-variable-names would be "strip_prefix" and "strip_suffix". In this case, being in line with the existing string API method names take priority over PEP 8, e.g. splitlines, startswith,

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

Nick Coghlan wrote: > The example where the new function was used instead of a questionable use of replace gave me an idea, though: what if the new functions were "replacestart()" and "replaceend()"? > > * uses "start" and "with" for consistency with the existing checks > * substring based, like

[Python-Dev] Re: Proliferation of tstate arguments.

ith asyncio and concurrent.futures. Although it's relevant, it's very different in terms to implementation details. Also, I'm substantially more interested in the Python parts of the stdlib rather than the C internals or extension modules, but I certainly have an interest in learning more. Regard

[Python-Dev] Re: Proliferation of tstate arguments.

we could also see example(s) which address those scenarios with a thread-local variable instead of a tstate parameter, I think it would allow for more objective comparison between them. Regards, Kyle Stanley On Wed, Mar 18, 2020 at 6:36 AM Mark Shannon wrote: > > > On 17/03/2020 7:00 pm

[Python-Dev] Re: New discuss.python.org category: Core Dev

Thanks for adding the new section, Brett. :) Was the name "Core Development" also considered? To me, it seems like "Core Dev" could be interpreted as abbreviating "Core Developer", which seems roughly equivalent to the existing "Committers" category (at least based on the name alone). I'm sure

[Python-Dev] Re: How to respond to repeated bad ideas

> In most cases of a first-time poster that I've seen, the poster probably doesn't have the understanding needed to conduct a proper search of the mailing list. That's why I suggest responding with some genuine help (i.e. taking their idea at face value and explaining what's wrong with it). It

[Python-Dev] Re: Accepting PEP 584: Add Union Operators To dict

> So I've also never come across "|=" being used for this purpose. IIRC, the JavaScript implementation of "|=" can potentially be used in the way Claudio described it, instead it's based on the truthiness of the left-hand operand rather than it being "unset". But it works in that context because

[Python-Dev] Re: Merging PRs without CLA signed

nflict of one another regarding the CLA policy. [2] - Discretion to determine triviality based on best judgement, and whether or not they personally consider merging any PRs without the CLA signed. On Mon, Feb 24, 2020 at 1:54 PM Terry Reedy wrote: > On 2/23/2020 11:44 PM, Guid

[Python-Dev] Re: Merging PRs without CLA signed

e than anything, I'd just like the policy to be made clear for future PRs so that I can provide an accurate answer to newer contributors. On Sun, Feb 23, 2020 at 11:44 PM Guido van Rossum wrote: > On Sun, Feb 23, 2020 at 8:11 PM Kyle Stanley wrote: > >> In a recently opened typo fixing

[Python-Dev] Re: Merging PRs without CLA signed

and then the label updated to signed within a couple days after signing the CLA. This has also been the case in the majority of PRs I've reviewed from first-time contributors. On Sun, Feb 23, 2020 at 11:24 PM Ivan Pozdeev via Python-Dev < python-dev@python.org> wrote: > > On 24.02.2020 7:07,

[Python-Dev] Merging PRs without CLA signed

IMO, it comes across as more respectful to the efforts made by the author, as even the smallest of PRs can require substantial efforts from first-time contributors that are entirely unfamiliar with the workflow; regardless of how small the change is. [3] - https://devgu

[Python-Dev] Re: Three trivial PRs from first-timers in need of merging!

Thanks for bring attention to these PRs, Brandt! I think the second one should be particularly uncontroversial, seeing as it's just applying PEP 409 (raise from None) to an existing exception in an argparse unit test to clean up some unhelpful context clutter in the traceback. On Thu, Feb 20,

[Python-Dev] Re: Regarding SSL installation in python

Hey Chaitanya, The "python-dev" mailing list is specifically for the development *of* Python itself, not for general help with Python. "comp.lang.python" or "python-help" is more likely the list you're looking for. Also, for general information on the purpose of each of the primary mailing

[Python-Dev] Re: Azure Pipelines PR: Unresponsive agent

it'll be recreated automatically. Thanks for the advice! I figured this would be the best option in this situation, but since I wasn't sure about how exactly the agents worked, it seemed like a good idea to ask first. On Sat, Feb 1, 2020 at 6:27 AM Steve Dower wrote: > On 01Feb2020 184

[Python-Dev] Azure Pipelines PR: Unresponsive agent

In a recent PR (https://github.com/python/cpython/pull/18057), I received the following error message in the Azure Pipelines build results: ##[error]We stopped hearing from agent Azure Pipelines 5. Verify the agent machine is running and has a healthy network connection. Anything that terminates

[Python-Dev] Re: Python Language Summit at PyCon 2020

On the attendance application, there is currently an incorrect link to the informational page for the Language Summit: " https://us.pycon.org/2020/events/language-summit/;. Either the link could be changed to " https://us.pycon.org/2020/events/languagesummit/; or "

[Python-Dev] Re: Should set objects maintain insertion order too?

> The only `OrderedSet` use I have seen in the wild is https://github.com/python-hyper/uritemplate/search?q=orderedset_q=orderedset . A more generalized Python code search across GitHub of "orderedset" returns ~500k results: https://github.com/search?l=Python=orderedset=Code . Of course, a

[Python-Dev] Re: Should set objects maintain insertion order too?

Tim Peters wrote: > Sorry! A previous attempt to reply got sent before I typed anything :-( No worries, I only saw the link in the footer to the PSF CoC, and I was mildly concerned for a moment. My first thought was "Oh no, what did I do?". Thanks for clearing that up (: > The collision

[Python-Dev] Re: Should set objects maintain insertion order too?

0003268 Some more in-depth comparisons might be required for addition of single items to the containers. I might experiment further with this at some point in the next week or so, likely with implementing proper tests that omit the time to initialize the container. On Mon, Dec 23, 2019 at 1

[Python-Dev] Re: Should set objects maintain insertion order too?

Add" ones. This should provide a decent general idea though. On Mon, Dec 23, 2019 at 8:12 PM Guido van Rossum wrote: > To begin with, please compare performance of dict-with-None-values to that > of a set, for operations that can be expressed by both (e.g. both have > update()). &

[Python-Dev] Re: Should set objects maintain insertion order too?

Larry Hastings wrote: > a hypothetical collections.OrderedSet would probably work just fine. I'm also in agreement with adding a collections.OrderedSet. There certainly seems to be a practical use case for a Set that preserves insertion order, but with significant push back to modifying the

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

Kyle Stanley wrote: > or making *object* a positional only argument. Typo: I meant "positional only parameter", not "argument". On Mon, Dec 16, 2019 at 4:39 AM Kyle Stanley wrote: > > Inada Naoki wrote: > > If we find it broke some software, we can step back

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

Inada Naoki wrote: > If we find it broke some software, we can step back to regular > deprecation workflow. > Python 3.9 is still far from beta yet. That's why I'm +1 on these proposals. IMO, since this would be changing a builtin function, we should at least use a version+2 deprecation cycle

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

; You can get an error here if you run Python with -bb. This is a > temporary option to catch common errors of porting from Python 2. Huh, interesting. On Mon, Dec 16, 2019 at 3:59 AM Serhiy Storchaka wrote: > 16.12.19 02:55, Kyle Stanley пише: > > I'd much prefer to see something

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

for the insight. On Mon, Dec 16, 2019 at 3:43 AM Eric V. Smith wrote: > On 12/16/2019 3:05 AM, Kyle Stanley wrote: > > Chris Angelico wrote: > > ANY object can be passed to str() in order to get some sort of valid > > printable form. The awkwardness comes from the fact that st

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

user meant str(bytes_obj, encoding='utf-8') Personally, I'm more in favor of (1) since it's much more explicit and obvious, but I think (2) would at least be more useful than the current behavior. On Sun, Dec 15, 2019 at 8:13 PM Chris Angelico wrote: > On Mon, Dec 16, 2019 at 12:00 PM Kyle Stan

[Python-Dev] Re: Parameters of str(), bytes() and bytearray()

Serhiy Storchaka wrote: > Forbids calling str() without object if encoding or errors are > specified. It is very unlikely that this can break a real code, so I > propose to make it an error without a deprecation period. +1, I suspect that nobody would intentionally pass an argument to the

[Python-Dev] Re: Travis CI for backports not working.

hat keeps the breakage from landing on > master? > > On Thu, Dec 12, 2019 at 5:46 PM Kyle Stanley wrote: > >> Victor Stinner wrote: >> > What is the issue? Can someone please open a bug report at >> https://bugs.python.org/ so I can try to investigate? >> >&g

[Python-Dev] Re: Travis CI for backports not working.

Victor Stinner wrote: > What is the issue? Can someone please open a bug report at https://bugs.python.org/ so I can try to investigate? >From my understanding, it looks to be pyenv related and not something we can fix on our end, at least based on the build logs:

[Python-Dev] Re: PEP 611 -- why limit coroutines and classes?

"coroutine object limits" is likely to come up again in the future. On Wed, Dec 11, 2019 at 4:46 PM Antoine Pitrou wrote: > On Mon, 9 Dec 2019 21:42:36 -0500 > Kyle Stanley wrote: > > > > (b) Why limit coroutines? It's just another Python object and has no >

[Python-Dev] Re: PEP 611 -- why limit coroutines and classes?

//linux.die.net/man/2/fcntl). Note: I was unable to find a credible source on the minimum memory usage per additional FD, so clarification on that would be appreciated. On Wed, Dec 11, 2019 at 5:06 PM Andrew Svetlov wrote: > On Wed, Dec 11, 2019 at 11:52 PM Antoine Pitrou >

[Python-Dev] Re: Dropping coroutines from PEP 611.

With the removal of the coroutine limit, I think that PEP 611 will be a lot easier to consider. Personally, I've gone from -1 to +0. But, with the class limit also being rather controversial, I think the PEP would benefit significantly from backing that up with some form of analysis on memory

[Python-Dev] Re: PEP 611 -- why limit coroutines and classes?

ld consider that to further reinforce my previous statement that we should have some form of concrete evidence; to prove that imposing the limits will provide tangible benefits to the vast majority of Python users. On Tue, Dec 10, 2019 at 4:45 AM Steven D'Aprano wrote: > On Mon, Dec 09, 2019 at 11

[Python-Dev] Re: Please be more precise when commenting on PEP 611.

Chris Angelico wrote: > We have people who believe that a bit > mask will slow things down, others who claim that improved cache > locality will speed things up, and Mark asks us to please justify our > objections with numbers. But surely it's up to Mark to show numbers > first? +1. While it

[Python-Dev] Re: PEP 611 -- why limit coroutines and classes?

> I also would suggest for PEP 611 that any limits are discoverable (maybe in sys) so it can be used by other implementations like Jython. I agree, I think that sys would likely be the most reasonable place to read these limits from. Also, it seems like a good location for setting of the limits,

[Python-Dev] Re: PEP 611 -- why limit coroutines and classes?

; > > On Mon, Dec 9, 2019, 18:48 Kyle Stanley wrote: > >> > (b) Why limit coroutines? It's just another Python object and has no >> operating resources associated with it. Perhaps your definition of >> coroutine is different, and you are thinking of OS threads? >&g

[Python-Dev] Re: PEP 611 -- why limit coroutines and classes?

> (b) Why limit coroutines? It's just another Python object and has no operating resources associated with it. Perhaps your definition of coroutine is different, and you are thinking of OS threads? This was my primary concern with the proposed PEP. At the moment, it's rather trivial to create one

[Python-Dev] Re: Travis CI for backports not working.

e checks is typically a last resort since intermittent regression test failures are a concern, but it's highly useful when the failure is occurring due to external factors (such as a recently merged PR or issues with the CI service itself). On Fri, Dec 6, 2019 at 1:33 PM Steve Dower wrote: >

[Python-Dev] Re: Should we require all deprecations to have a removal version that we follow through on?

Victor Stinner wrote: > Isn't it already the current unwritten deprecation process? Personally, I don't think we should rely on an unwritten process for something as important and potentially breaking as a deprecation process. Regardless of the outcome of this discussion, I think we should try to

[Python-Dev] Re: Travis CI for backports not working.

Steve Dower wrote: > As a related aside, I've been getting GitHub Actions support together > (which I started at the sprints). Would adding support for GitHub Actions make it easier/faster to temporarily disable and re-enable specific CI services when they're having external issues? IIUC, that

[Python-Dev] Re: Deprecating the "u" string literal prefix

> BTW, I think 2to3 can help to move from 2&3 code to 3-only code. > Instead, we can do: > * Don't recommend u-prefix except in Python 2&3 code. > * Provide a tool to remove the u-prefix. +1, this seems like the smoothest way of handling it and has very minimal impact on users. In 5+ years from

[Python-Dev] Re: PEP proposal to limit various aspects of a Python program to one million.

> The number of live coroutines in a running interpreter. Could you further elaborate on what is meant by "live coroutines"? My guesses (roughly from most likely to least likely) would be: 1) All known coroutine objects in a state of either CORO_RUNNING or CORO_SUSPENDED, but *not*

[Python-Dev] Re: Implementation of PEP-0604

> I agree with Nick, this is indeed big, but not impossible. If you are not sure yet whether you will work on implementation, you can focus on polishing the PEP text, and then if it is accepted and you will decide to give implementation to someone else, we will find a volunteer. Unless I'm

[Python-Dev] Re: A much better tokenize.untokenize function

> This is all irrelevant if you haven't signed the CLA*. IMO, this shouldn't be an argument against the proposed changes, as the CLA is fairly straightforward and only takes 24-48 hours to process. Unless the OP specifically is unable to or doesn't want to sign the CLA, it won't be a significant

[Python-Dev] Re: Allow custom headers in `http.server`

> Probably python-list/comp.lang.python mailing list/news group is the best place Since this involves a potential suggested change (adding a feature to assign custom headers to http.server), python-ideas or the "Ideas" section of https://discuss.python.org/ would also be appropriate. On Sat, Oct

[Python-Dev] Re: Awareness creation of a new IDE

> You don't need permission to support Python in a commercial IDE. It's open source. Adding to this, see https://docs.python.org/3/license.html#terms-and-conditions-for-accessing-or-otherwise-using-python for the complete licensing information on Python. On a somewhat related note to the

[Python-Dev] Re: Need help to fix test_asyncio issues

> Recently, I started to experiment "./python -m test [options] -F -j100" to attempt to reproduce some tricky race conditions: -j100 spawns 100 worker processes in parallel and -F stands for --forever (run tests in loop and stop at the first failure). Interesting, even as someone who has recently

[Python-Dev] Re: Currently working on the release of Python 3.8.0rc1

> Can you help with the "What's New" document? After seeing this, I went through the whatsnew for 3.8 and found a couple of typos and broken links (from Sphinx roles that were slightly off). I opened a PR to fix as many as I was able to: https://github.com/python/cpython/pull/16535. Raymond will

[Python-Dev] Re: Adding GitHub usernames to the developer log

ted contributing to Python). This would be a non-issue with a public listing of core developer real names -> GitHub usernames that isn't dependent on bpo. On Wed, Sep 25, 2019 at 7:12 AM Victor Stinner wrote: > Le mer. 25 sept. 2019 à 08:24, Kyle Stanley a écrit : > > Recently, Brett upd

[Python-Dev] Re: Adding GitHub usernames to the developer log

> But I will say that listing our GitHub usernames with our real names is not required to tell who is a core developer. In GitHub's UI there are multiple places it will tell you if a person is a member of the repository/team Within the GitHub UI if you're not a member of the organization, it

[Python-Dev] Adding GitHub usernames to the developer log

Recently, Brett updated the developer log in the devguide (https://devguide.python.org/developers/) to fetch the names of each core developer and the date they were given commit privileges from the private python-committers repository. I think it would also be quite useful to include GitHub

[Python-Dev] Re: static variables in CPython - duplicated _Py_IDENTIFIERs?

> How easy would it be to search the sources and the docs for the ones that are currently public but not documented? Comparing the docs and .c files for functions that are not documented would be fairly trivial, but it's very difficult to define something as being public if it's not documented,

[Python-Dev] Re: The Python 2 death march

Benjamin, what are you thoughts on usage of the "needs backport to 2.7" label? For most of the PRs I've reviewed I tend to avoid adding it myself, but I've seen it used periodically. It seems to be used rather infrequently (

[Python-Dev] Re: Python for Windows (python-3.7.4.exe) location confusing

Terry Jan Reedy wrote: > "This installer also installs the multiversion py.exe launcher if doing so would not be a downgrade. If you have admin access, we recommend installing one py.exe for all users. See xxx for how to use py.exe. [ ] Install py.exe for all users. +1, Particularly on this

[Python-Dev] Re: Announcing the new Python triage team on GitHub

> For instance, I don't think a triager should be able to edit other users' comments or lock conversations, but I'm afraid GitHub > doesn't provide that level of granularity (correct?). You are correct in that GitHub does not allow customization of the permissions, but those with the "Triage"

  1   2   >