The only time fixed port numbers are inconvenient is when they conflict, but otherwise they're much easier to work with.
Of course, one day the technical inferiority finally shows itself (e.g., the ports do conflict), and then people start to heroically overcome the obstacles they've created for themselves, showing outstanding feats of ingenuity. Just google "port allocator"! Every company inevitably writes their own home-grown one because everyone's deployment/integration pipeline is unique.
It’s likely that the port will be available indefinitely.
This already works by just telling flask to use port 0. Binding to port 0 is standard behaviour (literally, part of the standard) and like most other software of that type the first thing Flask does is report the URL it’s running on.
> but it offers tremendous convenience.
Except when it does not as is the case here. If you’re working on your web stuff having to copy/paste a URL from your term every time you restart your server.
I've seen a couple of programs that explicitly check and refuse to start when asked to listen on port 0 (for example, to this day "ssh -D 127.0.0.1:0 remote-host" refuses to start).
> If you’re working on your web stuff having to copy/paste a URL from your term every time you restart your server.
Don't the developer's standard server-launching scripts (re)launch browser after they start the server? IIRC, npm start and VisualStudio+ASP.NET do exactly that.