Color/format codes in console are literally printed.
Use a simple fastapi setup like your readme example.
from fastapi import FastAPI
app = FastAPI()
@app.get("/")
def read_root():
return {"Hello": "World"}
I figured out that this can be fixed by using os.system("cls") on top of your main.py

Expected with os.system("cls"):

I do not think adding a raw os.system("cls") should be the right solution for a library. However, I do not know another way to fix the issue.
On Ubuntu18.04 everything works as expected. Could be a problem with my windows machine.
If this is a problem with my local machine, I am sorry.
Also I know that I should post this on the uvicorn repo instead. But I figured that you should mention this as long as the bug exists.
This issue is related to uvicorn, not FastAPI.
Last sentence:
Also I know that I should post this on the uvicorn repo instead. But I figured that you should mention this as long as the bug exists.
Last sentence:
Also I know that I should post this on the uvicorn repo instead. But I figured that you should mention this as long as the bug exists.
Oops 馃檭
@zaanposni These are ANSI codes, which are the standard way to add colors to output in a POSIX terminal. From what I gather, this will work just fine in Windows if you run inside PowerShell; the problem is using a non-ANSI-aware terminal like cmd.exe. (Are you running the server via cmd.exe?)
If that is right, I don't think it necessarily needs mentioning in FastAPI docs, as it's a relatively uncommon edge case that is an issue with the specific terminal being used to run the server (especially considering, as you noted, that it's not a FastAPI issue to begin with).
That said, I haven't used Windows in years, so I can't verify this myself and it could be wrong!
@dmontagu thanks for your response. I did not notice that running and developing with cmd.exe is that much of an edge case. However, as I think about it, you could be right. Shall I close this issue or wait for encode/uvicorn#542 ?
Thanks for the help here everyone!
@zaanposni yeah, cmd.exe is in general just very difficult to deal with for developers.
This actually goes down to Click, it's probably not even Uvicorn.
I think cmd.exe is still in Windows probably just for backwards compatibility. But if you are in Windows the best next thing after WSL2, Bash for Windows, Babun (Zsh in Windows), etc. is just PowerShell, even more if you are a developer.
Hello @tiangolo,
I also grew up a bit and now use Linux for development 馃槃.
However, I wanted to report this problem because it still exists.
I've learned my part and think that using cmd.exe shouldn't support everyone in their library.
How should we proceed? The problem still persists, although I would never expect anyone to fix it as it is very banal.
This is a fairly common bug with non-ANSI-aware terminal(s). There're similar reports even with Poetry (check this thread #1887 & if you search enough you might come across many other like these).
And also, to be honest it definitely isn't a FastAPI related issue either. Not to forget how trivial & non-blocking this issue is. And if the guys at uvicorn are inclined they might want to look into this issue. With that in mind, I think it's safe to close the issue.
Developing on Windows has never been better. You got WSL, Windows Terminal & many other CLI stuff to use. Take a look at the screenshot below, it's a breeze working with the new Windows Terminal & it's only gettting over time.

So my suggestions?
You don't have to migrate to a Unix environment just for a "good" CLI. Windows 10 is fine, just use Powershell (or WSL) with the new Windows Terminal, more so if you're a developer. This opinion is from someone who uses Ubuntu while on-the-go & Windows 10 on a desktop environment.