4 ms·

It only takes a couple of minutes to educate yourself on this topic. After reading it, let me know if you still think they don't want to compromise. https://ww

It only takes a couple of minutes to educate yourself on this topic. After reading it, let me know if you still think they don't want to compromise. https://www.artima.com/weblogs/viewpost.jsp?thread=214235 https://www.artima.com/weblogs/viewpost.jsp?thread=214235

soulbadguy 3y ago
> It only takes a couple of minutes to educate yourself on this topic. You can disagree without assuming that i am not familiar with the subject. The link you provided is from 2007 so i am not sure how fair it is to quote guido from then. But i am not sure the link demonstrate the point you are trying to make, from guido himself : > While it is my personal opinion, based upon the above considerations, that there isn't enough value in removing the GIL to warrant the effort. Edit : If you want a newer reference, this HN threads and the links discribe the situation well https://news.ycombinator.com/item?id=36240998 https://news.ycombinator.com/item?id=36240998 Which is the point i am making... This is not really a technical issue, the python just doesn't think it's worth the effort.
- nunuvit 3y ago
  > 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.

soulbadguy 3y ago

> It only takes a couple of minutes to educate yourself on this topic. You can disagree without assuming that i am not familiar with the subject. The link you provided is from 2007 so i am not sure how fair it is to quote guido from then. But i am not sure the link demonstrate the point you are trying to make, from guido himself : > While it is my personal opinion, based upon the above considerations, that there isn't enough value in removing the GIL to warrant the effort. Edit : If you want a newer reference, this HN threads and the links discribe the situation well https://news.ycombinator.com/item?id=36240998 https://news.ycombinator.com/item?id=36240998 Which is the point i am making... This is not really a technical issue, the python just doesn't think it's worth the effort.

nunuvit 3y ago
> 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.