21–30 of 105 posts
System python at least is generally only recommended to be used for system libs, and that's a relatively supportable set. Developers use virtualenv's and their own specific interpreter, but it would certainly move the needle on what language people were by default scripting and thinking in.
If users are gaining performance, they will bend over backward porting their code to this new version.
At minimum, I predict, all FAANGMULA would jumped in the bandwagon and create a pretty big ripple effect.
Why is it never mentioned that Sam the lone genius Gross who is "interested in PyTorch training workflows" is a fulltime Facebook employee? Not that it's bad but it should be mentioned that it's a corporate initiative.
Just came in here briefly to opine that there is a very real risk of fork if the Python core community does not at least offer a viable alternative expediently. The economic pressures surrounding the benefits of gross’s changes will likely influence this more than any tears shed over subtle backwards incompatibility. I believe it was Dropbox that famously released their own private internal Python build a while back…
It might not matter much if Canonical or IBM decided to port a critical mass of open source extensions/packages. Then they could ship the new CPython in place of the old one and mention the differences in the release notes. With one or both throwing their weight behind it, it would gain significant momentum above and beyond the original project.
"On a personal level, we are impressed by Sam’s work so far and invited him to join the CPython project. I’m happy to report he is interested, and to help him ramp up to become a core developer, I will be mentoring him. Guido and Neil Schemenauer will help me review code for the interpreter bits I’m unfamiliar with."
1. Supposing this method doesn't currently crash under GIL python, would it be true that this method will also run without crashing on the non-GIL python interpreter?
2. Would it be true that the non-GIL python interpreter will introduce a race to this method (resulting in a runtime error) that didn't exist under the GIL interpreter?
Earlier quoted context omitted.
> I believe it was Dropbox that famously released their own private internal Python build a while back and included some concurrency patches. Google also had their Unladen Swallow version, but it seems they lost interest at some point.
Unladen Swallow is a 20% project. Besides, LLVM's JIT turns out to be an disappointment and I believe that no modern interpreted language uses LLVM's JIT at this moment.
Just came in here briefly to opine that there is a very real risk of fork if the Python core community does not at least offer a viable alternative expediently. The economic pressures surrounding the benefits of gross’s changes will likely influence this more than any tears shed over subtle backwards incompatibility. I believe it was Dropbox that famously released their own private internal Python build a while back…
> there is a very real risk of fork It might not matter much if Canonical or IBM decided to port a critical mass of open source extensions/packages. Then they could ship the new CPython in place of the old one and mention the differences in the release notes. With one or both throwing their weight behind it, it would gain significant momentum above and beyond the original project.
The lifeblood of Canonical and Red Hat / IBM is long term platform support for companies that want their most critical code to not break underneath them.
Even if the open source libraries get ported, there are still plenty of proprietary C extensions out there for which this would be a breaking change - the "dark matter" referred to in this post.
It would make zero sense for them to "throw their weight around" and _unilaterally_ break their customers' code if even the upstream devs didn't want to go through with the changes.
Earlier quoted context omitted.
Is there some particular reason to believe the Python team is even able to get good insight into regressions in the long tail of python packages? Also it's important to remember that a lot of of material contributions to the community (either to the foundation, via jobs, or even open-sourcing part of their internal stack) might be coming from closed source in some way. It's not wise to ignore that & I think the core…
Concurrency is impossible to prove sound without language-level guarantees. https://www2.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-... I'm astounded that a change which will release untold heisenbugs into the wild is being considered. It changes my view of Python. In terms of inducing subtle, silent breakage in existing code, it reminds me of this horrifying change from PHP 8: https://www.php.net/manual/en/migra…
Just came in here briefly to opine that there is a very real risk of fork if the Python core community does not at least offer a viable alternative expediently. The economic pressures surrounding the benefits of gross’s changes will likely influence this more than any tears shed over subtle backwards incompatibility. I believe it was Dropbox that famously released their own private internal Python build a while back…