[-]

Twirrim@reddit

immediately raise an issue on their github and complain loudly

What... no. How about ask nicely instead. No reason to complain loudly at all, doubly so if it's an open source project you're not paying for.

[-]

chinawcswing@reddit (OP)

Maintainers should absolutely be on top of having their libraries ready and compatible for the next version.

This is a fundamental responsibility of a maintainer.

If you are a maintainer, and you stop all of your users from upgrading because you failed to make it compatible, or in the worst case you failed to do something as simple as release a binary wheel, you are doing it wrong.

[-]

sawser@reddit

This is only appropriate for paid libraries you've purchased from someone.

If you're a maintainer you have a. Obligation to address security issues immediately, but other than it's a choosing begger situation.

[-]

chinawcswing@reddit (OP)

You have obviously never maintained any application.

Any maintainer worth his salt would take pride in the application he wrote, and would want it to be compatible with the most latest version.

The fact is that most maintainers are simply unaware of release dates when python will drop.

If you inform the maintainers about the release date they will always, without exception, prioritize it.

It's wild that you are actually stating with any confidence that a maintainer wouldn't care about making their library compatible with the latest version of python.

You have no idea what you are talking about.

Prove me wrong. Test your application on RC2, find a dependency that is broken, and raise a polite github request. Time how long it takes for them to fix the ABI compatibility and/or release the wheel.

At the very least they will start working on it immediately, and in the vast majority of cases they will be ready on the release date for Python 3.13.

[-]

Twirrim@reddit

You have no idea what you are talking about.

The only one showing they have no idea what they're talking about is you.

Open Source is not a demand environment. It's a collaborative one. Maintainers aren't your slaves, they're not there to jump every time someone so much as blinks. You are not owed their time, and you are not owed their labour. You are taking advantage of their labour, and willingness to publish their labour publicly.

This is an important way of thinking that I really think you need to spend some time wrapping your head around, because it's clear from your messages in this thread so far that you really don't understand the Open Source contract, nor do you understand the what open source licenses are telling you. You're not owed anything from any open source project. Not one bit.

Speaking to the license part, specifically quoting from GPLv3, but you'll find variations of the exact same wording in virtually every open source license (they're all nearly identical, in fact):

Disclaimer of Warranty.

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

There is no warranty for the software licensed with an open source license. A particular key phrasing in the license terms is that software provided under an open source licenses is provided AS IS. Bugs, warts and all. Software published with an open source license can literally not work, and you are agreeing to not have any expectations, or make demands, otherwise. You're even agreeing to cover any costs that may occur from your use of the software, should it fail in some way in your product.

Open Source licensed software will only work to the extent that the publishers may choose to state, and you are not entitled to assume otherwise, nor is there any kind of guarantee or commitment made by open source maintainers for making it work under the circumstances that you wish it to.

It is up to them to decide if, as, or when they choose to ensure it works in other circumstances. There are absolutely no guarantees made in the license terms that it will be in whatever time frame YOU want.

By using open source software you are agreeing to these terms in their licenses. If you're not happy with things being provided on an as-is basis, and maintainers getting to it when they have time to get to it, then either pay them to prioritise your tasks, or your patches; or find another solution, maybe one with a commercial license and support contracts where you can make demands of maintainers.

The vast majority of open source developers are working on their projects in their spare time. This is not their job. This is not how they make money. You're not paying them. That means you have no right to demand their labour. That means any support is entirely up to when they happen to have time to do it. If you find it doesn't work on the most recent version, and you need support sooner, then as part of the social contract of open source, you are more than welcome to submit pull requests, or offer to pay the maintainer for their time.

Added to this, the large majority of the installed user base will not be on Python 3.13 for some time yet, because it won't make its way in to most Linux distributions for a while. There isn't a new LTS due soon for any of the enterprise distributions, though maybe RedHat will put Python 3.13 in an application stream at some stage. Enterprise customers are the ones that tend to be more likely to pay open source maintainers for support, and it's also more likely to be what environment maintainers find themselves using their software in in their working life. Even then enterprise sponsoring is rarer than rocking horse manure.

What this means is that you might happen to choose to be on the bleeding edge of things, but most end users of open source libraries will not, and maintainers, who are already providing unpaid labour, are likely to be spending most of their volunteer time working on things that have the biggest impact, which will mean prioritising work that affects versions of python their users are actually using.

Maybe you should take a hint from all of the other people in this thread that are also telling you your expectations are wrong.

[-]

chinawcswing@reddit (OP)

Maybe you should take a hint from all of the other people in this thread that are also telling you your expectations are wrong.

All the other people in this thread, like you, are college students who have never written code professionally or maintained an open source application. You derive all of your opinions from whatever is most upvoted on Reddit, without exception.

It is an absolute fact that maintainers are highly motivated to make their libraries compatible with the latest version of Python.

The vast overwhelming majority of active/popular python modules will be ready for Python 3.13 on the day it comes out.

It's insane that you would try to argue otherwise.

[-]

Twirrim@reddit

And another swing and a miss, I'm not a college student, odds are I'm actually older than you, and I've been working in and around open source for decades. You're doing great! Keep at it!

[-]

chinawcswing@reddit (OP)

I guarantee that I have been programming for far longer than you.

Just to reiterate: you are quite literally arguing that maintainers have no inclination to preparing their code base for the latest release.

What a mind-boggling statement.

Virtually all of the most popular python modules will be ready on day 1 for Python 3.13.

Just because you are lazy and put in the minimal amount of effort through life, doesn't mean everyone else is the same.

[-]

Twirrim@reddit

Just to reiterate: you are quite literally arguing that maintainers have no inclination to preparing their code base for the latest release.

I argued nothing of the sort.

There's an attitude of entitlement in your urging people in your original post to "demand loudly", instead of "ask politely". Demanding is rude (doubly so to do so "loudly"), asking isn't.

Maintainers can choose to but don't have to. It's entirely their choice, and they may not choose to do so, because they may have other priorities.

[-]

sawser@reddit

It's such a strange hill for this dude to die on

[-]

sawser@reddit

I've been maintaining applications and packages for around two decades now in Java and Python - in addition to creating mods for a handful of games.

I've got a full time job and teach jiujitsu 15 hours a week and just got back from taking a bunch of kids to a tournament.

People who donate their time to open source products have other shit going on.

[-]

pm_me_github_repos@reddit

It’s a python minor version which means breaking changes. If your dependencies fail, you fix them according to the python 3.13 spec. Or you stick to <3.13

[-]

UselessButTrying@reddit

Huh, i thought only major versions have breaking changes while minor versions are moreso feature additions in a backwords compatible way

[-]

poppy_92@reddit

Python is not going to have a v4 (maybe a very small chance) due to the amount of churn py2->3 caused. So all breaking changes have to be in minor versions. Feature releases are usually in minor versions as well. Patch releases are more for bug fixes and security fixes. But someone's bug fix could be another one's breaking change, so it's kind of up in the air.

An example of this: A recent somewhat controversial change is the deprecation of ~True / ~False. This deprecation was introduced in 3.12 and was going to raise in 3.14 (which has now been delayed to 3.16). Some discussion about this is occuring in https://discuss.python.org/t/bool-deprecation/62232

[-]

UselessButTrying@reddit

Thanks for the info. Yeah, im more familiar with node which does use semver. im also reading that the breaking changes for python minor versions are more often changes in C api

[-]

pm_me_github_repos@reddit

Most python packages operate that way but python has historically had breaking changes in minor versions.

[-]

aa-b@reddit

You can be loud and polite/constructive. In this case it's like shouting "Dude, you're literally on fire!" at someone (who is somehow unaware of being on fire)

If there was a serious problem with something I'm about to release, I'd be grateful to be told by any means necessary myself. The fallout is so much worse when you find out too late, even a few false alarms are OK

[-]

billsil@reddit

Please do not complain. There’s nothing I can do outside of waiting 6+ months. My dependencies have dependencies and I’m not about to build from source because I use Windows.

If you really care, do a pull request. If you don’t want to do that, don’t ever use a package 6 months after a new python version comes out.

[-]

chinawcswing@reddit (OP)

The vast majority of python modules will be ready for Python 3.13 on the very first day it is released.

It will not take them 6 months lmao.

[-]

billsil@reddit

Anaconda takes 6 months to a year to release a new version.

The vast majority of python modules don't many dependencies.

[-]

chinawcswing@reddit (OP)

Anaconda isn't relevant to this discussion.

Whether or not numpy is prepared to be ready for Python 3.13 on the release date has nothing whatsoever to do with the fact that Anaconda is not ready for Python 3.13 on the release date.

[-]

billsil@reddit

How is it not relevant? You gave me grief for wanting to wait for my dependancies to update prior to updating my package. I literally can’t even test. If python 3.13 is so easy, why can’t Anaconda release some binaries within a week? It’s the same thing.

[-]

twigboy@reddit

immediately raise an issue on their github and complain loudly that they need to make the changes to make it compatible

As someone who maintained an open source project, this behaviour is the sort that drives maintainers away.

Ive always prioritised requests from the ones that are polite and respectful. The rude ones get marked as duplicate even if opened first. We're not above being petty

[-]

chinawcswing@reddit (OP)

I forgot this was Reddit and that everyone here is too literal.

Of course you should be polite and you should not complain, certainly not complain loudly.

The point is that that most people including maintainers seem to be totally unaware when new Python releases are dropping.

If you raise a ticket, politely of course, the vast overwhelming majority of maintainers will prioritize it. The good ones will, at least.

[-]

sawser@reddit

So not at all what you said in your message. Many of the people here are professional developers, and your word choice matters.

"If you run into issues, it will be very helpful if you let the contributors know in their GitHubs."

Would be a perfectly cogent statement.

[-]

chinawcswing@reddit (OP)

Most people who don't use reddit, and especially most programmers, are able to read between the lines instead of read everything literally.

Obviously you shouldn't complain loudly. That is never an effective strategy for getting things accomplished. Politeness is always the best strategy.

[-]

mmcnl@reddit

Why not write what you mean in the lines instead of between the lines? And not belittle those who question what you're saying in and between the lines? If you write down A but actually mean B it's your fault if people don't get you actually mean B.

[-]

chinawcswing@reddit (OP)

I guarantee you that if your coworker sent you an email with my post, word for word, you would not have gotten angry or failed to understand. You would have used your brain and read through the lines.

It is literally only on Reddit where people somehow lose this ability.

That is the culture here. Read everything as literal as possible, and then disingenuously complain about it.

[-]

mmcnl@reddit

I am not angry?

[-]

chinawcswing@reddit (OP)

You did it again. You deliberately read the comment literally and chose to ignore the greater meaning, and then disingenuously replied in such a way to ignore the actual meaning.

Again, I guarantee you that if your coworker or wife or anyone sent you a text message with that reply word for word, you would not have done that. But because you are on Reddit you immediately cave to the social climate and behave this way.

[-]

mmcnl@reddit

You don't know how I communicate with others and it's totally irrelevant anyway. Use less words and be more specific.

[-]

sawser@reddit

Instead of asking strangers who do not know you to magically understand what you mean to say and read between the lines when you tell them to be a dickhead to people who donate time to maintain packages, why don't you just use the words you want us to magically understand you to mean?

Because instead of saying "oh I didn't mean that literally - you're right complaining loudly is obnoxious, let me update my post"

You're being a pedantic jerk to everyone whose pointed it out.

Which of course makes me think you genuinely meant to tell people to be a jerk to code maintainers.

I'd hate to see your code

This loop runs a million times

I don't meant that literally, obviously the code runs I times

"It's not interative it's recursive, obviously

[-]

runawayasfastasucan@reddit

Lol, just admit that your call to "complain loudly" was wrong mate.

[-]

runawayasfastasucan@reddit

immediately raise an issue on their github and complain loudly

Wtf, its up to them if they want to support 3.13, and when they want to support it.

[-]

chinawcswing@reddit (OP)

What an awful take. Any maintainer who doesn't want to support the latest version of Python is terrible.

[-]

sawser@reddit

Yeah anyone who won't donate 100% of their free time to strangers on the internet, immediately is a piece of shit.

Lol what losers, providing useful code for free to others in their spare time for no money at all.

[-]

Neat-Description-391@reddit

I see it more like: "If you don't want to maintain the package - meaning it works on new, and maybe on old - stop pretending and declare it unmaintained..."

Loud doesn't imply obnoxious/impolite.

[-]

runawayasfastasucan@reddit

This makes no sense at all. You know that even old python versions are still maintained? Packages can still target old versions of, say, python and still be maintained, lol.

[-]

sawser@reddit

OP may not have intended "Loudly" to mean obnoxious or rudely, but most people do.

Because "Loudly" is a subjective adjective, and it implies to do whatever with more than anticipated volume or intensity then otherwise required.

And there's a level of work that some people who donate to free products between "unmaintained" and "this is my top priority and I will work on it the millisecond there's a new release client available" and that's called "at my earliest convenience.

You and OP are welcome to volunteer your own time to work on any open source projects and bring them up to speed since you guys have nothing more important to do.

I've been doing development for decades and know that open source projects I use require testing when switching to new versions, and if that project is so critical to me or my organization that it's preventing an update, the onus is on me to purchase a support package for it, clone the project and fix it myself, or find a replacement.

OPs' post should have said

"please test the release client, and if you run into a problem with a dependency it's always best to let the maintainers know in their GitHubs"

Everyone understands that communication should be polite, and would have assumed that OP meant politely. But because OP went out of their way to specifically instruct people to loudly complain, we assumed he meant to be louder and more of an asshole than we normally would be.

And instead of "oh yeah my bad" he doubled down all over the thread, and you're doing the same thing.

[-]

runawayasfastasucan@reddit

Nah, telling people to complain loudly just because a package doesn't already suppprt 3.13 is an awful take. So is pretending like you didn't mean that.

[-]

ForkLiftBoi@reddit

Yeah, isn’t it the pythons concerns only for the core installed packages to function? I.e. only imports that require no pip install?

[-]

dukeblue219@reddit

I think the poster meant complain on the dependency's GitHub

[-]

monorepo@reddit

Just a note: You should, in fact, not complain loudly. You can open an issue, or if you are feeling extra snazzy - open a pull request to add support.

Be kind :)

[-]

cnelsonsic@reddit

FTFY:

If any of your dependencies fail when running your application on
the RC2, immediately open a merge request on their github and make the changes to make it compatible.

[-]

caatbox288@reddit

To be fair, opening an issue is also useful. Not an issue in which you complain loudly like OP says, just an issue where you explain politely what does not work and provide as much information as possible.

[-]

Neat-Description-391@reddit

To me, bold all-caps "Doesn't work on 3.13" is way more polite than wasting everyones time with lenghty hollow pleasantries.

[-]

bfcdf3e@reddit

What an awful attitude. Way to ruin an interesting subject.

[-]

tankerdudeucsc@reddit

Experimental JIT. Would love to see benchmarks once that is well tuned.

Folks seen benchmarks for performance with the JIT?

[-]

caatbox288@reddit

The faster CPython team maintains a public benchmark repository which is pretty thorough: https://github.com/faster-cpython/benchmarking-public

Tldr: no improvements yet

[-]

jmreagle@reddit

They were originally talking about a 50% improvement per release, sadly too optimistic if not delusional.

[-]

caatbox288@reddit

It did not pan out like that, no. It seems python 3.13 is 2-4% faster than 3.12.

[-]

poppy_92@reddit

There's essentially no improvements. The work so far has been to get the groundwork and initial implementation done. I think the PEP suggested there might be a 2-5% on either side compared to single threaded python.

[-]

ErGo404@reddit

Instead of complaining on github issues you would be welcome to create a PR for 3.13 support on any open source project you use.

[-]

NimrodvanHall@reddit

OP who is their GitHub in your post? Python’s or the dependencies’ ?

[-]

chinawcswing@reddit (OP)

The dependent libraries' github.

[-]