will it become a relic of the past?
Probably
why YEAR in the first place, who would actually make use of it?
Accounting systems in the 90s that needed to squeeze out every drop of performance imaginable
will it become a relic of the past?
Probably
why YEAR in the first place, who would actually make use of it?
Accounting systems in the 90s that needed to squeeze out every drop of performance imaginable
I expect it won’t
The year datatype is a 1 byte integer, but the engine adds/subtracts 1900 to the value under the hood and has special handling for zero.
If you need to store more than 255 years range, you can use a 2 byte integer, which doesn’t need that special handling under the hood, because with 2 bytes you can store 65000+ years
There are like 10,000 different solutions, but I would just recommend using what’s built in to python
If you have multiple versions installed you should be able to call python3.12
to use 3.12, etc
Best practice is to use a different virtual environment for every project, which is basically a copy of an existing installed python version with its own packages folder. Calling pip with the system python installs it for the entire OS. Calling it with sudo puts the packages in a separate package directory reserved for the operating system and can create conflicts and break stuff (as far as I remember, this could have changed in recent versions)
Make a virtual environment with python3.13 -m venv venv
the 2nd one is the directory name. Instead of calling the system python, call the executable at venv/bin/python3
If you do source venv/bin/activate
it will temporarily replace all your bash commands to point to the executables in your venv instead of the system python install (for pip, etc). deactivate
to revert. IDEs should detect the virtual environment in your project folder and automatically activate it
Ya but they are in a different order
Right? it screams wayyyy pre-y2k but MySQL was only release in 95