61–70 of 105 posts
Earlier quoted context omitted.
Embrace, extend, extinguish. Sam will be in for a rude awakening with these people.
This is python, not Microsoft we are talking about
The situation is even worse now.
The site is currently past its hosting limit for the day. https://archive.md/Zb8p2 (Archived through google cache, so two layers of cache.)
I can't help but read all the interjections from the core developers as a strong indication of why all these sorts of things tend to fail on the vine. From Unladen Swallow onward there have been these groups off doing interesting and awesome experiments to try and make Python faster, and they never actually make it into something that Python end-users can use (yes, I know US had shortcomings). This is the work of one…
> Would you prefer to support some weird arbitrary nameless closed source extensions, or have a multicore Python? There's nothing wrong with staying on an older LTS version of Python. Let the people with the nameless closed-source stuff stick with that. The beauty of open source is that they can fork the older, GIL-ful version of Python and maintain it, if they like. Multicore would be a tremendous boon to the langua…
Earlier quoted context omitted.
> Would you prefer to support some weird arbitrary nameless closed source extensions, or have a multicore Python? There's nothing wrong with staying on an older LTS version of Python. Let the people with the nameless closed-source stuff stick with that. The beauty of open source is that they can fork the older, GIL-ful version of Python and maintain it, if they like. Multicore would be a tremendous boon to the langua…
> an older LTS version of Python There was an older LTS version of Python called Python 2.7. Last I checked people hated the transition and were still bitching about it in 2021.
My chief complaint was that there was a decent syntactic change for 0 benefit for me, and many Python users. F-strings, swapping strunicode, print function. All white superficial stuff, at least as far as my domain is concerned (data science).
It felt like “hey other languages are getting breaking changes, we should too”.
This is completely different. Single core speeds have not increased for years (decades?), any language with performance vaguely on the list must have an answer to multicore computation. I’d put up with a fair amount of pain for this.
Perhaps, dunno, web devs would complain that this change doesn’t help them, and is only a pain. That’s what I disliked in 2->3. I was told that I’m a dinosaur and should put up and shut up. Which eventually I did. But this is my answer to the naysayers this time.
Of course this might still fail in technical grounds but I’m hopeful, sounds solid.
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…
I mean, PyPy is over a decade old now, and micropython is a mere 7 years old. What's another fork? If anything, I strongly prefer languages that have more than one implementation.
What popular languages fall into this category ? I can only think of C/C++ and JavaScript - both seem like terrible examples of languages that took forever to evolve (people still compile down JS to ES5). I'm not sure what the Java story is but I would argue it has been terrible at evolving the language as well.
I much prefer languages that have one implementation as a de facto standard, worked on by core team (eg. C#, Rust, TypeScript). Sure they might be a few random implementations - but the language is basically what the main compiler supports. Standards and specifications add so much overhead and I really don't see the value.
The site is currently past its hosting limit for the day. https://archive.md/Zb8p2 (Archived through google cache, so two layers of cache.)
Thanks for the link. I just moved the website to Netlify from Fastmail. Hopefully the DNS on your side will update soon.
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…
The only thing horrifying to me is that that behaviour was there in the first place!
I would be 100% behind those fixes, I assume from your response that you would not do them in the sake of backwards compatibility.
What would be your solution? To always have these idiosyncrasies in the language, or did you have a problem with how the fixes were implemented or rolled out?
I can't help but read all the interjections from the core developers as a strong indication of why all these sorts of things tend to fail on the vine. From Unladen Swallow onward there have been these groups off doing interesting and awesome experiments to try and make Python faster, and they never actually make it into something that Python end-users can use (yes, I know US had shortcomings). This is the work of one…
Taking a highly conservative approach to breaking changes is absolutely not the same thing as being indecisive. The Python team has learned from experience how disruptive breaking changes can be.
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…
Not sure I understand that. The proposal is not to simply get rid of the GIL, but to have a two-tier mechanism that ensures correctness with all the C source that uses the macros it should use and doesn’t mess with refcounts behind Python’s back (doing sketchy stuff usually ends up in pain)
I think there's a pretty good chance this stuff gets incorporated: "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."
12 references to people in one statement, 5 referring to the post author, 1 reference to social fraternity membership, 1 statement of authority. I'm not sure if there is a common name for this particular source of discomfort, but that quote definitely contains a lot of it. I'm a historical contributor to the Python source repository, but something about the social structure of the project has changed significantly in…