[ashishb]

Many famous libraries like Spacy do not support Python 3.13 and are stuck on Python 3.12 (Oct 2023).

So, even if this comes out in Python 3.14, any non-trivial project will have to wait till Oct 2026 (or Oct 2027) to be able to use it.

1 - https://github.com/explosion/spaCy/issues/13658

[arp242]

Good grief that issue is a clusterfuck of bozos.

Sometimes I wish there was a GitHub with entry exam. "A library you use has a bug, you find a find a 3 month old bug report for your exact issue. Do you 1) add a comment with "me too", 2) express your frustration this issue hasn't been fixed yet, 3) demand the maintainers fix it as soon as possible as it's causing issues for you, or 4) do nothing".

Only half joking.

[Hasnep]

The Refined GitHub extension [1] automatically hides comments that add nothing to the discussion. [2]

[1] https://github.com/refined-github/refined-github [2] https://github-production-user-asset-6210df.s3.amazonaws.com...

[bityard]

Wow, that extension is a gold mine of much needed GitHub functionality

[rowanG077]

I actually find that hugely helpful that so many people are actually actively expressing they are hitting this. It's not easy to be able to get an idea what issues people are actually hitting with anything you have made. An issue being bumped with essentially "me too" is a highly valuable signal.

[barotalomey]

That's why github added emoji reactions many years ago, so you can express "me too" without spamming the notification systems.

https://github.blog/news-insights/product-news/add-reactions...

[genewitch]

I very rarely use emojiis on github. If I can't add anything to the discussion / issue, I post nothing. So if there's enough people like me, an issue can languish.

However the barrier to entry for a lot of issues reporting is pretty tall - requiring triplicate documentation of everything. It's like an overreaction to the sort of people that need to be told to unplug something for 30 seconds to continue the support call.

And that's if they even "allow" issues.

I was posting in issues note frequently 1-3 years ago. I'm sure I'd be sheepish about some posts.

[arp242]

Do you really think the maintainers don't understand that "doesn't work with Python 3.13" isn't going to affect tons of people?

There's some bozo asking "any news? I cant downgrade because another lib requirement" just two days after the maintainer wrote several paragraphs explaining how difficult it is to make it work with Python 3.13. This adds no value for anyone and is just noise. Anyone interested in actual useful information (workarounds, pointers on how to help) has to wade though a firehose of useless nonsense to get at anything remotely useful. Any seriously discussions of maintainers wanting to discuss things is constantly interrupted by the seagulls from Finding Nemo: "fix? fix? fix? fix? fix?""

Never mind the demanding nature of some people in that thread.

Just upvote. That's why this entire feature was added.

[madars]

After seeing "Jigar Kumar" cognitive exploits on xz mailing list a maintainer would be excused (and I'd even say, encouraged) to just ignore pressure tactics altogether. It's an open source project - if it works great, if it breaks, you get to keep both pieces.

[throwaway519]

To the non-technical founder, this is doing something.

They will not move to ~~mocking up~~ sketching a wireframe of something.

[rowanG077]

Considering the python ecosystem is not keen on staying updated anyway, I wouldn't be surprised a maintainer doesn't realize a new python version not working is that important.

[hkt]

Reactions, though.

[stingraycharles]

It’s not just that, it’s people commenting “this is unacceptable” and “I hate this library” that add very little value.

Also, you can upvote issues as well / leave reactions without leaving comments. It ensures a better signal:noise ratio in the actual discussion.

[raverbashing]

Geez honestly

This seems to be the issue https://github.com/explosion/spaCy/issues/13658#issuecomment...

And you depend on opinionated libraries that break with newer versions. Why? Well because f you that's why! Because our library is not just a tool, it's a lifestyle

Though it seems that Pydantic 1x does support 3.13 https://docs.pydantic.dev/1.10/changelog/#v11020-2025-01-07

[__mharrison__]

What is the passing answer?

[bagels]

You're missing

5) Do 1, 2, and 3

6) Submit a a tested pull request with a fix

[efitz]

Except when you do 6 the maintainer rejects the request and says that it wasn’t a bug at all, and everyone is stuck with the bug.

[matheusmoreira]

Pull requests should not be normalized. The guy in charge of the code base has complete knowledge of it and can always do a better job than randoms making ad hoc changes to quick fix their own problems. Complaining about bugs and missing features is much easier. It's less of a headache and requires less effort and time investment.

Truth is developers don't want to end up maintaining other people's code anyways. It's gotten to the point I roll my eyes whenever I see people saying "patches welcome". Chances are they're not as welcome as you would think. "Show us the code", and when you do... Nothing. Submitting a pull request is no guarantee that they'll accept it. Hell it's no guarantee they'll even give you the time of day. You can put in a whole lot of effort and still end up getting refused or even straight up ignored.

Even if it's an unambiguous improvement on the status quo. They'll commit code that literally returns "not implemented" directly to master and actually ship it out to users. Your pull request will certainly be held to much higher standards though. And that's if they engage with you in an attempt to get your patches merged. They might just decide to ignore your patch and redo all the work themselves, which is exactly what all the complainers wanted them to do in the first place! If they're really nice they'll even credit you in the commit message!

If you're gonna put in effort into someone else's project, just fork it straight up and make it your own project. Don't waste time with upstream. Don't wait for their blessing. Just start making your own version better for you. Don't even submit it back, they can pull it themselves if they want to.

[bagels]

Boo to you. I've up-streamed patches to scipy and a few other python packages. Nobody ever said no to genuine high quality bug reports that were coupled with good fixes. Not saying that will happen every time, but if you're unsure, ask how receptive they are.

[matheusmoreira]

I've upstreamed patches too and I increasingly feel like it's a waste of time and that it requires far more effort than it's worth. Good maintainers who work with you are rare. I remember the ones who do.

> Nobody ever said no to genuine high quality bug reports that were coupled with good fixes.

Uhuh.

> ask how receptive they are

Doesn't really help much. It's entirely possible for people to tell you it's fine then change their minds after you actually do it and send the code in. Seriously hope you never have to experience anything of the sort.

[LtWorf]

We should normalise GOOD pull requests. And possibly avoid making garbage ones that fail 100% of the testsuite.

[matheusmoreira]

You can put effort into all that, observe all the best practices, follow all the rules, try your very best and still end up with literally nothing to show for it simply because the other guy doesn't want to.

Always fork the project and customize it for yourself. Don't argue with others, don't try to convince them, make your version work better for you. It doesn't matter if they want it or not. You don't even have to publish it.

[eptcyka]

I wish more people attempted to actually grasp their dependencies by the scruff of their neck and got to know them deeply.

[kamray23]

Eh, most of the time you do have to publish it. MIT/BSD/Apache allows you not to, but most big projects are using LGPL or another share-alike license. With those, if you're making a project that you do publish (e.g. a commercial product that uses that library/language/etc.) you do kinda legally have to share that modified source code. It's of course different if you're scripting for your own sake, but the moment you publish anything using them you also have to publish your modified versions of libraries and other stuff.

I do agree with the "fork and make it better for you", but I also think it's common courtesy to throw up issues for the bugs or missing features you encounter, as well as pull requests. If for no other reason then as "prototypes" or "quick fixes" that others can cherry-pick into their own forks. They may get rejected, they may get closed, but you still don't have to sit there arguing about it since you have your own version. From a slightly Kantian angle you have your working version and you've now fulfilled your social duty by offering solutions to problems. You've got no need to campaign for the solutions if they get rejected.

It's virtuous and you get to ignore the github flame wars. There's really no downside beyond taking 5 minutes to be nice and at least put your solution out there. Also fulfills your reciprocal legal duty under LGPL and such.

[LtWorf]

Those are great guidelines for never achieving anything relevant.

Also, the same ideas applied to dating rather than to code are what we call "incels/redpillers" and so on, so you might want to calm down a bit I think.

[throwaway519]

Truth.

[sitkack]

I have been getting paid to write Python since the late 90s and it amazes me how it consistently has these needless own goals, yet still keeps on going in spite of itself. Way to go Python!

spaCy should make Cython optional

hard fork Cython to not used stringitized annotations

stay on Python 3.12 forever and then skip to 3.15

It is like have a crowd of people trying to outdo each other on how much self harm they can induce.

[ChrisMarshallNY]

> It is like have a crowd of people trying to outdo each other on how much self harm they can induce.

See: Lemmings[0]

[0] https://en.wikipedia.org/wiki/Lemmings_(National_Lampoon)

[sitkack]

I am picturing a whole dis track at pycon where we creatively mock everything and everyone.

[martinky24]

What exactly is the own goal here…? They’re making the language better in the upcoming release. This is how normal software works.

In no world is this an “own goal”. God forbid they take on a big task for the betterment of the future language.

[yjftsjthsd-h]

> What exactly is the own goal here…? They’re making the language better in the upcoming release. This is how normal software works.

Backward incompatible changes are an own goal because they either (depending on your view) make the software worse, or make it better and then make those improvements unavailable to users.

[sitkack]

I don’t think you understand the whole issue of why spaCy can’t move to Python 3.13

God forbid.

[rhdunn]

I hit this when upgrading to Ubuntu 25.04 as that upgraded to Python 3.13. I'm running the various python projects I want in a venv. For the projects stuck on 3.12 I ended up building and installing it from source to my local directory (removing the unprefixed links for compatibility) as the ppa for Python ports doesn't (didn't?) support the latest Ubuntu.

I dislike using something like docker or conda as I don't want to install/use a separate distro just to be able to use a different version of Python. My setup is working well so far.

[turbocon]

Everyone has there own preferences, but I'd look into uv if I were you. It allows you to specify the python version, and for scripts you can even specify the python version as part of the shebang

[Imustaskforhelp]

uv is literally the goat except I haven't able to make vllm work in uv for some reason. Though aside from that, I think I need to use shebang more because I don't use it as often right now.

[rtpg]

I was going to write something glib about getting things fixed but that thread looks gnarly!

To be honest I know so many people who use Pydantic and so many people who seem to get stuck because of Pydantic 2. I’m glad I have minimal exposure to that lib, personally.

I suppose the biggest issue really is type annotation usage by libs being intractable

[bsoles]

Does that mean that a point release of Python has breaking changes? If true, that sounds crazy.

[aftbit]

Yes, every Python 3 release for me (at least since 3.6) has had a breaking change or two that affects a library I use. Most of the time, the fix is pretty trivial, but not always.

[dymk]

Yes, things like format string syntax change between 3.10 and 3.11 and it’s incredibly frustrating

[pbronez]

Just ran into something similar with Great Expectations. Python 3.12 is the newest I can run.

[0cf8612b2e1e]

uv seems to have reverted to defaulting to 3.12 instead of 3.13. Which I fully endorse owing to how many packages are not yet compatible.

[ashishb]

Exactly, many compiled languages like Java and Go do not suffer from this issue.

[LtWorf]

It's not about being compiled or not compiled. Python is now making breaking changes on every release instead of piling up a bunch of them and making python 4.

So what we get is a a mini python2/3 situation on every single release instead.

[ashishb]

Yeah.

Even patch version upgrade from 3.12.3 to 3.12.4 broke a lot of packages.

https://github.com/langchain-ai/langchain/issues/22692

[fiddlerwoaroof]

Tell that to all the companies stuck on Java 8 with old versions of Spring and Hibernate. This is the cost of an ecosystem where major libraries make breaking changes.

[lmm]

Spring and Hibernate broke the rules of the language and paid the price, and nevertheless all the companies I'm aware of managed to migrate the best part of a decade ago.