The Anglican Ordinataries are actually a rather mild example as they're still under the Roman Catholic church.
The eastern Catholic churches are also in communion with Rome but have a far longer history of independence and also allow married men to become priests, even if they weren't married clergy before joining, which the AO doesn't allow: https://en.wikipedia.org/wiki/Eastern_Catholic_Churches
> Historically this was the result of the fact the church predates modern communications. It was not possible for a Pope to direct things
That's not really accurate. All bishops were essentially "autocephalus" in antiquity. Whether they could even be removed by a council of other bishops was something that was really not resolved for many centuries. There were many occasions of competing councils declaring each other heretics and shenanigans like that.
The Orthodox still practice this system of governance (although sovereignty has been moved up from diocesan bishops to the patriarch of each autocephalus church).
You are right and that history is another reason: the starting point was that. However, even when popes started claiming greater authority there was a practical constraint on centralisation.
Your theory seems to be that the speed of information significantly increased the power the pope can wield and this is what allowed for the centralization of power.
I don't think the historical record shows that. The speed of information changed little from the time of the Nicean council to the council of Trent, yet the primacy of the pope was very much established by the latter, even if it was only formalized in the 1st Vatican council.
Even to this day church politics plays out over many months and years (just look at the recent SSPX situation which was a slow-mo train wreck), the speed of information doesn't seem very significant.
There are many such because the Church's own belief is that a bishop always remains a bishop (even if removed from their diocese) and can make others bishops.
Python certainly has some baggage, especially the typing system (which is still not finished, if you're looking at static typing and so is implemented differently by type checkers) and pip's safety, or lack thereof. But comparing it to PHP or Perl is rhetoric leading you one step too far.
Comparing it with PHP is unfair… to PHP. The amount of hard work that the PHP community has done to advance and keep their language relevant is impressive and admirable, and Python is perhaps the most extreme counterexample there is.
The Python community has spent the last 15 years refusing to improve in any meaningful way, or to learn anything from their peers. As someone who used to choose only jobs that would let me work with Python, I’ve gone through every phase of grief, and now just try to forget that it exists.
Lol, Python has had incredible improvements over the last decade plus, while uv fixed packaging. It's the best/comprehensive glue language ever made, even with a few remaining warts.
Most of the time downvoters don't explain their downvote, but I'll explain mine. I voted this comment down because it's just plain incorrect.I worked with PHP for nearly ten years (and I never want to go back). Maybe PHP has improved since I worked with it (PHP 7.4 was the most recent version when I last worked with it, I have never used PHP 8), but I doubt it.
But to describe the Python community as "spen[ding] the last 15 years refusing to improve in any meaningful way" is just laughably wrong. I can't give details as I haven't been doing much Python work, but even so I know of multiple changes, such as the typing system, or packaging improvements, which have significantly improved the language AFAICT. If there's a reason why you would not consider those to be "improv[ing] in any meaningful way", please enlighten me.
You mentioned two biggies, but also the GIL removal, async, performance improvements, f-string, walrus, fast dicts w. merge ops, data classes, pattern matching, friendlier repl, and hundreds of smaller yearly improvements.
Pattern matching? Nice, I'd managed to miss that one completely, as well as the fact that Python had introduced dictionary-merging (according to a quick search, Python 3.9 introduced the | (pipe) operator for dict unions). I did know about the others you mentioned, but couldn't call them to mind when writing my comment.
But reading through a Python script that I had Claude Code write for me taught me another one: apparently there's now a / operator on strings, because Claude wrote `path = "some" / "dir" / "filename.txt"` without importing anything outside of the stdlib. I presume it is shorthand for calling os.path.join and will therefore apply the correct path separator on Linux vs Windows.
You are both focusing on Python improving in any way but the person you're responding to said "improve in any meaningful way, or to learn anything from their peers"
Which I will say is overstated but I can see where they are coming from even when you bring into scope things like types, async, etc.
First types. This is what the type hints in Python allow you to do:
def foo(x: int) -> int:
return x
foo("hello")
We can say that this is great Python has type hints, but at the same time the lesson they learned is wrong because the feature to have isn't type hints but actually enforcing them so the above code cannot be written. In my eye, this is an anti-feature.
Second async, this is also the wrong lesson to have learned from other languages. Adding async/await is a bandaid over the problem that the synchronous imperative model clashes with asynchronous distributed semantics. The async/await keyword are a way to try to bridge between the two, but it creates a "function coloring" problem that all these languages which added async/await have.
The lesson Python should have learned is to not add these keywords and go back to its glue language root, allowing actually natively asynchronous languages to coordinate asynchronous processes, while Python code handles the synchronous core. Python doesn't have to be everything, the wrong lesson was to try to be the one language to rule them all.
You also brought up the packaging improvements, which I feel were the wrong lesson learned. The problem with the Python packaging ecosystem is well known since it's been expressed in the XKCD comic. The lesson from other languages is: one blessed compiler toolchain integrated into the packaging story makes for a better user experience. This is the npm, cargo lesson. For Python to really learn it, uv or equivalent would be the blessed way of managing Python projects. Instead it's still a very fragmented landscape with many competing solutions, which goes against Python's own zen.
Moving on to pattern matching, again I feel the wrong lesson was learned. Pattern matching is a feature from the functional paradigm that in my opinion became more popular with developers when they became exposed to it in Rust, and so Python joined in and added the feature as well. But the reason it's such a nice feature in Rust is because it will refuse to compile any code that does not do exhaustive matching on all variants. This is great because it catches problems early and forces you to consider the non happy path where things can error. So pattern matching alone isn't the feature it's pattern matching PLUS structured Enums and exhaustive patterns.
So in Python you can do this:
x = 3
match x:
case 1:
print("one")
case 2:
print("two")
print("done")
Output will be "done" rather than an error on the match, which is what should happen if they had learned the right lesson, because without exhaustive matching this is no better than an if or switch. Again I consider this an anti-feature -- better to not have at all if it doesn't work as expected.
Anyway, I'm not trying to say Python is bad, I'm just saying I get where the other poster is coming from when they say Python has refused to learn the right lessons. Although I would not agree they haven't improved a lot over 15 years.
Not every improvement is perfect, that’s true. I in particular fought against walrus syntax and don’t use pattern matching for other reasons. Python is also boxed in by its history. Some of the things you want done are incongruent with its design.
Many people like them however. And you’re being way too charitable to that dumbass comment.
I guess what I’m trying to do is draw a distinction between “improvement” and “change”. We can agree to disagree but my view is the things I called anti-features are not improvements at all, but rather loaded footguns. Python would be more coherent language without async/unenforced type hints/non exhaustive pattern matching. Like you say, it’s constrained by its history and I feel a lot of the recent changes are to make Python more palatable to the devs who are using it for AI and ML rather than keeping it true to to its nature.
Type hints are very helpful on big projects. And are enforced by other tools. Honestly, this kind of criticism shows a lack of experience, and denial of reality for an almost 40 year old language.
It sounds like scoffing at a Silver medalist to me.
In fact, Python is better at what it does than almost anything from the era. That’s why we use it. Nothing is ever going to be perfect because better solutions are emergent, and reverse time travel does not exist.
> Honestly, this kind of criticism shows a lack of experience, and denial of reality for an almost 40 year old language.
Okay that's where you lost me. You can talk about the language from your perspective, and like I said we can agree to disagree, but it crosses a line when you want to comment on others' experience and put them down just because they disagree with you. No on is scoffing here, what I wrote was a considered criticism. Have a nice day.
It’s about as near a well-documented fact as there is in this industry, and not intended to be an insult. Sometimes we need a wake-up call, and yes they’re not usually enjoyable. I know as well as anyone else, having received my share over the years.
It's part of the EU's strategy to catch up by investing in future technology instead of building out present capacity.
I think it's a mistaken strategy but it's hard to suggest anything better when you look at the measly amounts they're investing that would get them very little with existing technology. So, they're forced to gamble on vaporwave tech.
Edit: I'm specifically talking about their semiconductor and computing strategy.
True, but what they do is they invest in fundamental research and then expect magic to happen and that research to lead to economic growth. Unfortunately the wizards that cast the spells live in the US, not Europe.
Citation needed.
And the problem isn't that Europe doesn't have its own wizards, it's that they don't have the mana market to turn those spell ideas into reality.
reply