> "I avoided implementing this correctly because of migration concern for existing installations of this code I'm writing right now"
This one grinds my gears so bad, probably 1/4 of my job at this point is telling an LLM (either in my own editor or in review comments for someone's MR) "how about we do this right _before_ merging it, eh?".
Or:
foo = abc
<Maybe 4-10 lines of code>
if foo != None:
...
In my experience giving it "rules" not to do this does nothing, but a separate pass (could be by a different model but really just fresh context is enough) does okay
All the global memories I have stored are basically just this. Memories appear to be completely useless on their own, but, before a merger or a plan is finalized, having it go read them will definitely help course correct.
I really wish there was an "every x tokens" type trigger for every agent, where I could have it fire off a "Pause, go read the guide to make sure you're adhering fully." To help keep concepts fresh in context.
Seems very reasonable, from my use. I commit much more often, as checkpoints, with branch rules that prevent force pushes/deletions, so the agents can't delete anything. And, suspect MS is only counting commits, and not the eventual squashes to one commit.
We had it internally with our teams that open a PR to then push like 10-20 more commits but never actually interested in the client builds etc. turned out they opened the PR as a checkmark/ way to share the current state.
We set cooldowns and auto cancel for the ci. And then there is the developer who uses the CI compute to run tests instead of running them locally for various reasons.
We had to remind that compute isn’t for free.
Nope. You can configure CI to not run for every commit of every branch (seems insane to have full CI for every commit, unless you don't allow your devs to push until done with something, which also seems insane).
The old HP calculators, and their emulators, have a computer algebra system, for symbolic maths, that supported this. The user interfaces leave much to be desired, but some also have reverse Polish notation!
This is different from a CAS. For example, if you ask it to do exp(100)+1-exp(100), it does not rearrange and cancel out the two exp(100)s. Instead, it does exp, addition, and subtraction, all with as many digits as you ask for.
> that doesn’t round at all. It computes with constructive real numbers: every result is exact, and you can scroll any answer for as many correct digits as you want.
A CAS is a practical way to achieve this, where everything is stored symbolically, with no rounding, until final calculation. Unlimited precision was through Erable [1]. This was included with/as HP49 CAS, but was an add-on with HP48. Many HP48 are on the iOS app store. The one I tried about a decade ago had the add-on, and I see many still there (but not sure if they have the add-on).
Perceptual color accuracy is usually handled at the display manager or operating system level; wherever monitor color calibration is applied. You don't usually have to worry about it, unless your target audience puts you especially in charge of it. (Certain applications on Windows and Linux do this for color-grading workflows.)
Oh, I was just listing the constraints. I'm not directly aware of a color space where value 0 is not no light. It would however mean that even if linear, doubling a value relative to 0 wouldn't necessarily double the amount of light.
> I suspect 3.14.4 could have been tweaked slightly to address the issue without a revert
I'm sure all the people that have been working on this for years would be interested in your small tweak, that they didn't think of, and would happily accept the PR!
a) do work to reduce issues as they come up
b) appease the vocal complaints
A takes work, guts, and risk. Option b was chosen with the GC work basically saddled with so much process it’s never going to change. Python has a very storied history of being very committee driven design so the committee did the committee thing.
Anyone who’s worked in incident response will tell you why you’re wrong.
Tweaking the GC while the system was functionally broken is the worst time to do it. Correct incident response is revert first, figure out how to fix it later.
The difference being this is not a live system and thus incident response is very different. Applying best practices from incident response to development of a language is simply incorrect
Do you live on a planet where the Python language maintainers are deploying Python into your servers or managing them? Do you live on a planet where a new version of Python being released gets instantly and automatically deployed into your systems without testing and validation?
You are responsible for that, not them. And if Python 3.13 is fine for you and you report a performance regression for 3.14, you can still stay on 3.13. And as you say, it was introduced in a new release. What happens when the other side goes and says “3.14.5 regressed on the GC pause times and my p95 web server latencies went up. Please revert”? At least one side can make the case “performance was changed on a major release of Python boundary” while the other is changing the performance on a minor release boundary. It’s an arbitrary decision that speaks to the politics of the organization and less about a well reasoned technical plan.
Your argument is, frankly, idiotic. If a version of Windows, or any deployed software, has a performance regression, do you consider it “not a live product” because you didn’t personally install it yet?
I really don’t have words. When people bemoan the state of software engineering, your comment here is exactly what they’re talking about.
3.14.5 has a serious performance regression - GC pause times have increased significantly since the entire 3.14 series. This is the problem - you’re arbitrarily putting max RSS of certain workloads over the p95 latency of others. It’s arbitrary and why the worst kind of software engineering that inhibits software progress for the sake of nothing changing.
As for Windows, I think you need a better example. OSes frequently change their performance profile on certain workloads and use more memory. Terrible example.
Also please cool it with the personal insults. They’re not productive and shows you’re trying to win the argument through force and emotion instead of reason.
Snarky comment aside, Python is definitely *not* a "live system". If you had worked with such system before you'd know the world of difference between a version release of "stable" software versus a live platform that cannot fail.
You mean software that has to be deployed locally? Like the example I gave?
> you'd know the world of difference
It's actually worse. The longer you take to get a fixed version out there, the more people will install the buggy version. As distribution is more difficult than just merging a Github PR, that buggy version will live longer on live systems. And before you say "but it's on the developer/DevOps/sysadmin to test," I point you to the countless CVEs where this didn't happen.
Knowing this is the situation, it's unconscionable to leave a faulty build on live for longer than necessary, when you can rollback the change with limited risk.
I do find the BDFL approach much better for language design. You might disagree with the direction of the language, but there is usually a "philosophy" or "taste" driven by one person that tends to be consistent over time.
In fact, I think Guido himself resigned due to the experience he had trying to get a PEP through the committee.
> In fact, I think Guido himself resigned due to the experience he had trying to get a PEP through the committee.
If you're referring to the steering council, that group was created in response to Guido stepping down.
He stepped down partly in response to the changing nature of online discussions around changes to the language. He just didn't want to be at the center of every polarizing discussion anymore. I think he also recognized that the transition needed to happen at some point, and that was as good a time as any.
People also use usable mice instead of touchpads, and they put the "ctrl" key where Apple thinks a useless "fn" should be. All kinds of things happen outside Apple world.
To me, it's more about what I'm used to. I have a perfectly fine several years-old monitor, so why should I throw it away?
Then let me blow your mind:) One of my daily drivers is an ex-Chromebook at 1366x768. Granted, it's also physically smallish so the DPI isn't quite as low as a macbook would be with those pixels, but still. And that's a touch cramped but it's fine.
The problem is, as soon as you are not on a Mac but Linux or Windows, you are in for an awful, truly awful lot of pain. HiDPI support is a mess because even in the rare case applications are made with HiDPI in mind they are not tested on HiDPI machines.
Other way around, most Mac software is not tested how it behaves on inferior external monitors.
What kind of windows programs are these? HiDPI is more than a decade old. A desktop application, no matter what OS it is, should always be tested with different scaling factors.
I’m not your child, and that’s false, it’s literally one key to change in the settings. That allows you to select the exact scaling factor, not macos’s “more text”/“less text”.
Have you ever tried to write HiDPI-aware Win32 code? I suggest enabling HiDPI in Control Panel sometimes and marveling at how many Win32 apps just don’t notice and draw as postage stamps.
Mac OS X 10.4 tried the same thing (Quartz2D scaling) and it was so damn difficult that they threw it out and went for simple 1x/2x/3x auto-scaling. Even 3x was a challenge because of pixel alignment.
Well, you were talking about testing, development of DPI-aware apps is another thing. It requires the developers to be, well, DPI-aware, but I don't think there are particular obstacles to that in winapi itself.
>Have you ever tried to write HiDPI-aware Win32 code?
I haven't. I don't think there's any reason to, I'm more of a wxwidgets fan. I don't think even Microsoft makes applications in raw WinAPI.
>I suggest enabling HiDPI in Control Panel sometimes and marveling at how many Win32 apps just don’t notice and draw as postage stamps.
The default behaviour of a DPI-unaware app in Windows is to scale everything by the scale factor. Which - yes, looks completely awful and blurry, but that's not what you describe.
Yeap. Managers perceive complexity by how personally confused they are. I'm late in my career, and I'm realizing I wasted so many man years trying to make code clean, user friendly, and maintainable, when that code was never read by another person again and forgotten 15 minutes after it was released, then used for years. This is why I think AI is coming for our jobs much sooner than many people think: clean code, separation of concerns, maintainability, etc, all the things we spend the most time on, have never actually been valued. "Good enough" is fine, and keeps management happy. And, if something does pop up, AI can patch it, even if with spaghetti, just like fucking that ass at work.
Also:
"I implemented it this terrible way because of precedence in the codebase...that I just wrote"
"I avoided implementing this correctly because of migration concern for existing installations of this code I'm writing right now"
"I deferred this critical feature for the future, so we can deploy quicker"
or, my favorite,
"I hand rolled an buggy http server because you said the tool should be self contained"
reply