3 ms·

> From a steering council perspective we effectively view a 703 threading enabled interpreter at a high level as a fork of the CPython VM. "Fork" and "effort"

> From a steering council perspective we effectively view a 703 threading enabled interpreter at a high level as a fork of the CPython VM. "Fork" and "effort" are different problems. It's reductive to say that effort alone is the tldr. If the 2007 article and the linked current FAQ seem too old to be relevant, you're not really understanding what the steering committee is saying today.

soulbadguy 3y ago
> "Fork" and "effort" are different problems. It's reductive to say that effort alone is the tldr. It's very unclear what you mean here, what does that have to do with the problem. Pep 703 is not a fork of CPython. Sam had (very highly impressive) protype of a gil-less cpython. It clearly demonstrate the feasibility and viability of nogil. It can be a drop in replacement, with the disabled/enable-gil option. Pep 703 is about integrating it into the main cpython codebase... > If the 2007 article and the linked current FAQ seem too old to be relevant I never said that the age of the article make irrelevant . What i said is that a lot of things change in 18 years, and it might not represent the current thinking of the person today. So i was trying to charitable to guido perspective. But in the article (from 2007) that linked it's clear that from his perspective the time/effort investment is not worth the pay out. > you're not really understanding what the steering committee is saying today. > It only takes a couple of minutes to educate yourself on this topic You keep insinuating that my current view on the situation is rooted in some kind of ignorance or some kind of misunderstanding. But you still haven't really made clear and cogent arguments for your point of view...
- nunuvit 3y ago
  GVR called it a fork two weeks ago in his justification for not accepting it [1]. If that surprises you, the backstory is summarized pretty well in the article [2] and FAQ [3]. I'm really not trying to be secretive. We can debate whatever you want, but we have to at least acknowledge CPython's stated position. [1] https://github.com/python/steering-council/issues/188#issuecomment-1575106739 https://github.com/python/steering-council/issues/188#issuec... [2] https://www.artima.com/weblogs/viewpost.jsp?thread=214235 https://www.artima.com/weblogs/viewpost.jsp?thread=214235 [3] https://docs.python.org/3/faq/library.html#can-t-we-get-rid-of-the-global-interpreter-lock https://docs.python.org/3/faq/library.html#can-t-we-get-rid-...
  - soulbadguy 3y ago
    > but we have to at least acknowledge CPython's stated position. We know the council and cpython stated position. None of the arguments in [1],[2] or [3] are new... The point is we disagree with it... You seem to imply that because GVR and/or the council call it a fork, then it is a fork... Again, we understand the position, we just think is not a valid point... > We can debate whatever you want You haven't debated anything yet... you just repeat/link what member of the council says and somehow call that an argument... This is very confusing
    - nunuvit 3y ago
      The usual way to dispute a decision is to start by refuting the justification. I think that's a reasonable ask.
      - soulbadguy 3y ago
        It was never my intention to dispute the council decision (choice really). One can disagree with a decision without needing to dispute it. Concerning the justifications, here again i am a bit confused, because all references you are giving, point to the amount of effort as being one (if not the biggest) concerns... which the what i am saying. But to take a step back, my main point was about the OP who described the situation as some cancer-cure level of complexity, comparing it to moving 300 million people from the imperial system to the metric system... : And i am saying that the situation here is not that complicated all the technical problem s can be address "at the same time" , but at the price a very large dev. effort and increase in complexity of the code base. The council doesn't think that gil-less is worth that amount of trouble.
        nunuvit 3y ago
        Completely agree with you about it not being technically complex. I responded to your other comment, so let's move it over there.
- kortex 3y ago
  703 is probably the right path towards true gilless python, but to quote Greg Smith (gpshead) on the PR, > We're not ready to simply pronounce on 703 as it has a HUGE blast radius. 703 isn't even out of draft PEP status. I think they need to come to consensus on 703, or modify it until it is acceptable, and then figure out how to merge the code and release it. I don't know for sure, but it looks like even with the compile nogil flag off, there are enough low-level API changes that extensions would break. If they can do it without breaking extensions with the flag off, I can see this happening over the next few years. But it's no small feat.
  - soulbadguy 3y ago
    I don't think anybody is saying to accept PEP 703 (and i don't want to make this conversation just about PEP 703, there was many other promising gil-less proposals) tomorrow. The main complain of the author of PEP (and other people as well) is the lack of clarity on the criteria for inclusion, as well as the constant goal post moving. > it looks like even with the compile nogil flag off, there are enough low-level API changes that extensions would break. From my understand, after testing from the author (and couple of other people on the discord thread) no case have been found yet. Greg's point is that the blast radium is so large that there is high probability that this might happen. We won't know until we test in the wild... And we won't test in the wild until the council arrives at a conclusion. The burden of proof here is so absurdly high, and has to be paid be Sam alone here that this will essentially kill this proposal.
    - nunuvit 3y ago
      > the lack of clarity on the criteria for inclusion, as well as the constant goal post moving This is where I think Sam is being unfair. He's asking for a breaking change. For 25 years, CPython has consistently and clearly said that they fully support no-gil in other implementations, and have a minimum criteria of no performance regressions for CPython. He made his performance demonstration before getting real buy-in. I understand he made that choice because of how his funding works, and now he's desperate to get a result. They acknowledged his demo and said they're considering it. Lashing out and accusing them of unclear criteria and moving goalposts misrepresents the situation. It's not his decision to risk burning the community on a breaking change. He knows they haven't decided on it. It's reasonable to expect someone to do that work. He hasn't done it, so they will have to do it. The steering committee also has to consider how this change will impact pursuing other goals. It doesn't exist in a vacuum all by itself. They reiterated that they do in fact want to remove the gil, even after noting how much work it will be to do due diligence. They've also said they want to take in big projects like creating a JIT. Seems to me like effort itself isn't an issue. By calling it a fork, coming from the steering committee, they're saying either the transition plan is non-existent, or it's the wrong design for their goals, or it's coming at a bad time. Maybe all of them. His task was to convince the committee to remove the gil. He interpreted that as simply doing a technical demonstration. Not sure why, especially given the history.

soulbadguy 3y ago

> "Fork" and "effort" are different problems. It's reductive to say that effort alone is the tldr. It's very unclear what you mean here, what does that have to do with the problem. Pep 703 is not a fork of CPython. Sam had (very highly impressive) protype of a gil-less cpython. It clearly demonstrate the feasibility and viability of nogil. It can be a drop in replacement, with the disabled/enable-gil option. Pep 703 is about integrating it into the main cpython codebase... > If the 2007 article and the linked current FAQ seem too old to be relevant I never said that the age of the article make irrelevant . What i said is that a lot of things change in 18 years, and it might not represent the current thinking of the person today. So i was trying to charitable to guido perspective. But in the article (from 2007) that linked it's clear that from his perspective the time/effort investment is not worth the pay out. > you're not really understanding what the steering committee is saying today. > It only takes a couple of minutes to educate yourself on this topic You keep insinuating that my current view on the situation is rooted in some kind of ignorance or some kind of misunderstanding. But you still haven't really made clear and cogent arguments for your point of view...

nunuvit 3y ago
GVR called it a fork two weeks ago in his justification for not accepting it [1]. If that surprises you, the backstory is summarized pretty well in the article [2] and FAQ [3]. I'm really not trying to be secretive. We can debate whatever you want, but we have to at least acknowledge CPython's stated position. [1] https://github.com/python/steering-council/issues/188#issuecomment-1575106739 https://github.com/python/steering-council/issues/188#issuec... [2] https://www.artima.com/weblogs/viewpost.jsp?thread=214235 https://www.artima.com/weblogs/viewpost.jsp?thread=214235 [3] https://docs.python.org/3/faq/library.html#can-t-we-get-rid-of-the-global-interpreter-lock https://docs.python.org/3/faq/library.html#can-t-we-get-rid-...
- soulbadguy 3y ago
  > but we have to at least acknowledge CPython's stated position. We know the council and cpython stated position. None of the arguments in [1],[2] or [3] are new... The point is we disagree with it... You seem to imply that because GVR and/or the council call it a fork, then it is a fork... Again, we understand the position, we just think is not a valid point... > We can debate whatever you want You haven't debated anything yet... you just repeat/link what member of the council says and somehow call that an argument... This is very confusing
  - nunuvit 3y ago
    The usual way to dispute a decision is to start by refuting the justification. I think that's a reasonable ask.
    - soulbadguy 3y ago
      It was never my intention to dispute the council decision (choice really). One can disagree with a decision without needing to dispute it. Concerning the justifications, here again i am a bit confused, because all references you are giving, point to the amount of effort as being one (if not the biggest) concerns... which the what i am saying. But to take a step back, my main point was about the OP who described the situation as some cancer-cure level of complexity, comparing it to moving 300 million people from the imperial system to the metric system... : And i am saying that the situation here is not that complicated all the technical problem s can be address "at the same time" , but at the price a very large dev. effort and increase in complexity of the code base. The council doesn't think that gil-less is worth that amount of trouble.
      - nunuvit 3y ago
        Completely agree with you about it not being technically complex. I responded to your other comment, so let's move it over there.
kortex 3y ago
703 is probably the right path towards true gilless python, but to quote Greg Smith (gpshead) on the PR, > We're not ready to simply pronounce on 703 as it has a HUGE blast radius. 703 isn't even out of draft PEP status. I think they need to come to consensus on 703, or modify it until it is acceptable, and then figure out how to merge the code and release it. I don't know for sure, but it looks like even with the compile nogil flag off, there are enough low-level API changes that extensions would break. If they can do it without breaking extensions with the flag off, I can see this happening over the next few years. But it's no small feat.
- soulbadguy 3y ago
  I don't think anybody is saying to accept PEP 703 (and i don't want to make this conversation just about PEP 703, there was many other promising gil-less proposals) tomorrow. The main complain of the author of PEP (and other people as well) is the lack of clarity on the criteria for inclusion, as well as the constant goal post moving. > it looks like even with the compile nogil flag off, there are enough low-level API changes that extensions would break. From my understand, after testing from the author (and couple of other people on the discord thread) no case have been found yet. Greg's point is that the blast radium is so large that there is high probability that this might happen. We won't know until we test in the wild... And we won't test in the wild until the council arrives at a conclusion. The burden of proof here is so absurdly high, and has to be paid be Sam alone here that this will essentially kill this proposal.
  - nunuvit 3y ago
    > the lack of clarity on the criteria for inclusion, as well as the constant goal post moving This is where I think Sam is being unfair. He's asking for a breaking change. For 25 years, CPython has consistently and clearly said that they fully support no-gil in other implementations, and have a minimum criteria of no performance regressions for CPython. He made his performance demonstration before getting real buy-in. I understand he made that choice because of how his funding works, and now he's desperate to get a result. They acknowledged his demo and said they're considering it. Lashing out and accusing them of unclear criteria and moving goalposts misrepresents the situation. It's not his decision to risk burning the community on a breaking change. He knows they haven't decided on it. It's reasonable to expect someone to do that work. He hasn't done it, so they will have to do it. The steering committee also has to consider how this change will impact pursuing other goals. It doesn't exist in a vacuum all by itself. They reiterated that they do in fact want to remove the gil, even after noting how much work it will be to do due diligence. They've also said they want to take in big projects like creating a JIT. Seems to me like effort itself isn't an issue. By calling it a fork, coming from the steering committee, they're saying either the transition plan is non-existent, or it's the wrong design for their goals, or it's coming at a bad time. Maybe all of them. His task was to convince the committee to remove the gil. He interpreted that as simply doing a technical demonstration. Not sure why, especially given the history.