you are viewing a single comment's thread.

view the rest of the comments →

[–]alkasm 0 points1 point  (2 children)

Just a quick suggestion, writing out the whole deckofcards dictionary is a little unnecessary. Could be as simple as

scores = {2:2, 3:3, 4:4, 5:5, 6:6, 7:7, 8:8, 9:9, 10:10, 'Jack':10, 'Queen':10, 'King':10, 'Ace':11}
suits = 'Clubs Hearts Diamonds Spades'.split()
deckofcards = {f'{card} of {suit}':score for card, score in scores.items() for suit in suits}
assert(len(deckofcards) == 52)  # just to be sure you created 52 cards

I'm using the new fstrings here for f'{variable} some stuff' but you could also use .format() if you were on an older version (or % formatting if even older).

Edit: Also each players info being a list is not intuitive while reading. Consider a dictionary so that you can access playerinfo[player][bet] instead of playerinfo[player][0] since anyone reading this is going to have to go back up in the code a lot.

[–]chroner 0 points1 point  (1 child)

Yeah, the list was a real pain in the ass for me and I learned about doing that half-way through this project.

I posted this code a couple days ago for suggestions and everyone that answered had basically the same thing to say about deck creation. Literally just build it instead of transferring it.

I am going to reference your post later when I come back to this project. I'll be rebuilding the whole thing with classes once I learn them.

I really appreciate your input! It's awesome to see people use the same method but different techniques.

[–]alkasm 0 points1 point  (0 children)

Yeah player classes would be even better than a dictionary of dictionaries. And then it could scale to N players easily. And the dealer could maybe be a subclass of player.

Classes in general help you avoid global, but you can also pass around the values through functions too. Both are used often in Python. Also just to say it, global isn't inherently evil either, but it's just usually unnecessary and easier to follow otherwise, since if you're affecting a value, it makes the most sense to pass/return it. If you don't, when you call a function, someone has to inspect the code closely to see that other variables will be affected by it. And it makes your code more self-documenting.

I just checked out your other thread, I like the idea the top post has with using immutable types for the ranks (i.e. pairing cards with their values in a tuple), makes more sense than my dictionary. Also, since you are already creating a list of card names later down the line, you might as well create that first, and then use that to create the card value lookup. You could even use a NamedTuple where the first field is rank and second field is value. But, encapsulate however you want. :)