Yeah, seriously. The style of testing is public, so some engineers at OpenAI could easily have spent a few months generating millions of permutations of grid-based questions and including those in the original data for training the AI. Handshakes all around, publicity for everyone.
They are running a business selling access these models to enterprises and consumers. People won’t pay for stuff that doesn’t solve real problems. Nobody pays for stuff just because of a benchmark. It’d be really weird to become obsessed with metrics gaming rather than racing to build something smarter than the other guys. Nothing wrong with curating any type of training set that actually produces something that is useful.
"our users are idiots and we need to keep them away from sharp edges" is exactly what keeps driving me away from Python and pip. It's why I wrote https://pip.wtf -- Python package management would be so simple if they'd just stop adding more and more seatbelts and cushions to Python.
"seatbelts and cushions" is not how I'd describe a package manager that can run arbitrary code from the downloaded package when you explicitly tell it "please only download this", simply because it wants to verify that building it will result in it having name and version metadata that matches what you asked for (https://github.com/pypa/pip/issues/1884).
This is not fixed in 24.2 btw, even if you do everything according to the latest standards - you're still allowed and expected to have a setup.py if you choose Setuptools as your backend and you release an sdist with a non-trivial build step. 24.3 should be out some time this month and I'll be interested to see if they've finally done something about this issue, which has existed for almost the entire lifetime of Pip.
Not just considered in PEP 722 - the uv feature is just an implementation of PEP 723 [1] (PEP 722's successor/competitor), which was accepted. Other tools like pipx support it as well.
No kidding about pip. The dependency resolver change several years ago was a similar terrible move to the PEP being considered here. It broke so much legitimately working code for no good reason; just paternalism from the core devs. The change pushed my team to stop using pip at all for dependency management.
Hard disagree there. It was way too easy to get yourself into an incompatibility hell with the old resolver, where package A relied on transitive dependency X v1.2 and package B needed X v2.1. Which version of X you got depended on whether you installed A or B first.
Yes, the new version did mean I had to straighten out a few projects that were already working before, but they were working by coincidence because my code paths weren’t stumbling across the incompatibilities. The problem already existed. The new resolver just exposed it.
My case was different from yours. Our project wasn't working by coincidence, the dependency resolver was flagging incompatibilities that simply didn't apply to our case, and began refusing to build a stable working project. Yes it's more risky to override that kind of guardrail, that's why I would only do it when I know the risks and tradeoffs and determine it's the best course of action on balance. I strongly believe that tools should ultimately work for the user, over dogmatic principles.
I'm fine with the those safety guardrails being the default behavior, but removing any sort of escape hatch because the pip devs think that they know better than the users of the tool 100% of the time is what I object to.
In the end we ended up ditching pip entirely for this use case and ended up with a much better system, with absolutely no disasters as a result, but we had a burn a lot of time and angst that could have been spent on actual problems we were trying to solve.
> If you don’t want pip to actually resolve dependencies, use the --no-deps option. This is useful when you have a set of package versions that work together in reality, even though their metadata says that they conflict. For guidance on a long-term fix, read Dealing with dependency conflicts.
I made https://pip.wtf, which is a "god damn it, I'm doing this myself" alternative for single-file scripts that just need some basic deps. You paste some code into your script and then it installs dependencies to a local directory.
Nice! The only criticism I have of this is needing to figure out the obscure shell quoting rules. But it is pretty easy to follow the DIY spirit and replace the os.system call with subprocess!
I'm looking for automation, scripting, making developer tooling, and prototyping. I can pick most things up really quickly and I like to write good documentation. I'm N3-level in Japanese.
The index, which is linked in the article, reveals that the banned books are not How to Code books but a series of chapter novels that feature girls who are interested in coding but know nothing about it. Furthermore, they are only banned as classroom curriculum books, not banned from the library, which makes sense because the first book appears to contain no classroom merit whatsoever -- just like most chapter books aimed at kids.
I skimmed through the first book. It's cute. A bunch of girls who are excited to learn to make apps join the coding club and get tricked by their female teacher into solving a bunch of coding trivia outside the classroom in order to develop friendships. They finally learn some actual coding from the protagonist's older brother. There really is no merit to this as a classroom assigned reading book, and it would probably be a drag for boys to read. The writing style and thoughts and feelings of the main character are obviously directed heavily at girls, except for the older brother who's a cool prankster and who actually knows how to make basic utilities.
The Girls Who Code textbook by the same author, Learn to Code and Change the World, is not banned.
Is there a reason we don't trust the teachers to make that call? I imagine there are a near infinite number of books that have "no classroom merit", do we need to spell them all out?
It's also hard to square "it just doesn't provide any benefit in the classroom" with this quote from the board president:
> What we are attempting to do is balance legitimate academic freedom with what could be literature/materials that are too activist in nature, and may lean more toward indoctrination rather than age-appropriate academic content.
That sure seems to suggest someone thought a group of girls bonding in coding club was "too activist".
> Is there a reason we don't trust the teachers to make that call?
As a conservative, I don't trust teachers because their interests often don't align with my own. I heard from a friend in Florida that their kid started identifying as an ATI Radeon HD4850, which is absurd and not respecting AMD's brand.
No, it's not free. Every time you load up the page to view your own files with files.gallery, a big honkin' pop-up shows up instructing you to buy a $40 license for additional features:
Purchase a license [$39] to unlock features and support dev!
- Remove this popup
- Upload
- Download folder
- Code and text editor
- Create new file
- Create new folder
- Rename
- Delete
- Duplicate file
- Dedicated support
- Multi-user, panorama and much more coming soon!
[payment button]
The files.gallery website only hints at this restriction at the very bottom of the page in the "License" section, which devs would expect to mean an OSS license: "Files is free to use with basic features. To remove the license-popup and unlock additional features, you may purchase a license [$39] from within the app."
Now if you look at the rest of the landing page you can see it very carefully does not mention the ability to use basic file browsing features so that it's not technically a lie to present a tool that can "browse files and folders without complicated installations" that doesn't allow you to do anything more than download your own files without opening your wallet.
When you try and obfuscate the fact that it is a purchased product, it makes one a hustler. This is no different than the many click-bait sites that offer -free- stuff that are actually purchased items.
It's not obfuscated, the landing page says the following under the section "License".
> Files is free to use with basic features. To remove the license-popup and unlock additional features, you may purchase a license [$39] from within the app.
You can tie floss into a loop. It's way better than strangling your fingers and faster too. Look at the last picture in the first post of this thread: https://igkt.net/sm/index.php?topic=2013.15
You grab and twist a doubled-up line, then pull the small end through the new hole. This takes just a few seconds and now I don't mind flossing daily.
