This is a very broad question, and I concur with u/nicholashairs that you should probably ask r/learnpython

But, generally speaking, how you approach this will depend a lot on the scope of the project. Based on what you said, your best bet is to start with something pretty simple/low-level, get a working prototype in order, then re-evaluate your options and start-over with what you've learned.

If that seems reasonable, then my suggestion would be to focus on a building a basic REST API which handles the game interactions then build a front-end which basically works more like a website rather than a game. You may not be able to build the kind of game you're targeting, but this approach will let you touch everything, get a lay of the land, and operate fast enough that you can toss the whole thing and focus on the more complex technologies you may need to actually build your game.

In Python, you could do this with something like FastAPI. You'd need to back this with some sort of database, like Postgres (although a very simple prototype may just use SQLite). You'd likely want to use SQLAlchemy as an ORM to handle the database interactions. Ideally, you'd also use Pydantic for data modeling, but that might be overkill at this point. Your goal would be to build a backend that is logical, scalable, and can be operated against entirely programmatically.

From there, the front-end is just an interface for the backend. I'd pick the simplest front-end framework you're willing to use and just go nuts with it. I'm partial to React (which isn't particularly simple), but there's a lot of good, modern options you can choose from. I'd avoid building things without this kind of framework. It's possible (and not too hard), but it quickly becomes unwieldy, so it's just worth doing it "right" from the start. Similarly, I'd avoid using JS game framework to start (like Phaser), since that it a whole other ball game.

Again, start simple, and just make something that resembles the kind of game you want to make. Don't try to force the technology to do stuff it isn't designed to do. Instead, just keep moving forward until you're satisfied with it and restart. Luckily, card games are usually simple enough that the approach I described should get you pretty far (i.e., turned based, simple interfaces, etc.).

Once you have that in-place, you can start exploring more complex stuff that may be required to actually build the game you want. This will likely lead you to exploring websockets (which FastAPI can still help you with), different kinds of databases like NoSQL such as MongoDB or even in-memory key-value databases like Redis, more appropriate front-end libraries (like Phaser), etc. You might even decide to move into a more proper game engine like Godot (which I'd recommend) which can still interact with a Python backend if you decide that's an appropriate approach.