In today's video we're going to be learning how we can use defaultdict in Python. ▶ Become job-ready with Python: www.indently.io ▶ Follow me on Instagram: / indentlyreels
@@DrDeuteron What is the difference between them? Can you still assign a lambda for setdefault or is defaultdict the only way to do that? Also, if you're just using a default constructor of some kind, will there actually be a difference?
Not necessarily, assume you have a list of unknown values whose types are not necessarily strings. This more general approach considers the 'str' representation of the object...Python is very intelligent (even if slow! Python has this important tradeoff!).
Yes it is, upper is a string function. The function does not exist for types like numbers, for example. If you are unsure of the type, you'd do str(string).upper() Wrapping that expression with colons is irrelevant. An exception will be raised before that if string is for example an int as upper() is only defined for string types
@@Andrumen01You're wrong, for two reasons: the type annotations indicate that these are strings, and `.upper()` is a method of the `str` class. Also, the code in the video is converting the string in uppercase to a string, so the f-string here is useless.
Hi there - one thing I use dictionary defaults (I usually use the get function of.a regular function) is for a translation from one representation to another. Often only a few words need to be translated - so the default is the key. For example "american_words={'colour':'color','honour':'honor'} then "new_word = american_words.get(word, word)". Is there a way to do this with default_dict?
defaultdict is so invaluable. It's not uncommon for me to subclass defaultdict to override __missingkey__ so that I can use the key in the creation of the default value.
@@davidmurphy563 Really? I introduce you to statically typed languages, then, even "worst", you're forced to put the complete type for each variable declaration!
@Dimitrius1991 Not really, it's always near the variable's name. Also it's more readable `var: Type = val` as "`var` of type `Type` which is equal to `val`", instead of `Type var = val;` that you or have to reverse the order of the type and the name, or have to say it in an unusual order: "a variable of type `Type` named `var` which is equal to `val`". But at the end, it's you that chose.
@foxypiratecove37350 I mean, it's more readable when a declaration and the corresponding assignment are not in the same line, especially if the type name is long. Also, I've had enough of static typing already.😆
@@Dimitrius1991 Not true. I wish C and C++ type declarations were as well separated as Python ones. Try to decipher what the following declares in C: void(**f)(void *(*g)());
defaultdict mentioned!! 🔊🔊🔊
I never thought I would hear Indently saying "yo mamma"
Zappa: "Maybe you should stay with yo' mamma" :-)
dict.setdefault: «am I a joke to you?»
that's a different default.
except at 6:15 where it is probably preferable.
@@DrDeuteron What is the difference between them? Can you still assign a lambda for setdefault or is defaultdict the only way to do that? Also, if you're just using a default constructor of some kind, will there actually be a difference?
def Tree():
return defaultdict(Tree)
t = Tree()
t['level1']['level2']['level3'] = 'a'
defaultdict is so useful, I've gotten annoyed at some other languages when their version of a dictionary didn't have an equivalent.
what default function do you use? And don't say "int".
@@DrDeuteron i use int in C++ instead of void .-.
super useful! Subscribed
If you try to access a key without adding it to this dictionary, is that key implicitly added (with the default value) or not?
Yes
4:41 Isn't the f-string overkill here?
Not necessarily, assume you have a list of unknown values whose types are not necessarily strings. This more general approach considers the 'str' representation of the object...Python is very intelligent (even if slow! Python has this important tradeoff!).
Yes it is, upper is a string function. The function does not exist for types like numbers, for example. If you are unsure of the type, you'd do str(string).upper()
Wrapping that expression with colons is irrelevant. An exception will be raised before that if string is for example an int as upper() is only defined for string types
@@Andrumen01You're wrong, for two reasons: the type annotations indicate that these are strings, and `.upper()` is a method of the `str` class. Also, the code in the video is converting the string in uppercase to a string, so the f-string here is useless.
Isn't using a defaultdict overkill in the string example? A normal dict would already work. Bad example...
@korntut I honestly don't know, I'm not a `defaultdict` expert. But yeah it seem a bit overkill, but the f-string was more obvious.
very useful function
Great video. Thanks
Hi there - one thing I use dictionary defaults (I usually use the get function of.a regular function) is for a translation from one representation to another. Often only a few words need to be translated - so the default is the key. For example "american_words={'colour':'color','honour':'honor'} then "new_word = american_words.get(word, word)". Is there a way to do this with default_dict?
defaultdict is so invaluable. It's not uncommon for me to subclass defaultdict to override __missingkey__ so that I can use the key in the creation of the default value.
2:04 That's not actually a cast, it's creating a new dict from the defaultdict
The true power of defaultdict is allowing you to circumvent your professor’s “No dictionaries” restriction, since it is not a dict = {} 😆
>>> isinstance(defaultdict(list), dict)
True
Calamansi (whatever that is - even spell checked did not know it) example works very well with dict() instead of defaultdict()
Python flet framework project convert to android apk plzz provide tutorial
C'est horrible la voix IA dégueu pour le doublage
Je vais essayer à l’écouter quand je rentre chez moi. Je suis très curieux!
La voix originale est bien mieux
holy crap auto translated ai sounds bad
like the german version straight up calls python "pithon"
i mean i appreciate translations, but i prefer the original
5:00
dict(zip(los, map(str.upper, los))
is mo' better.
{string: string.upper() for string in list_of_strings}
😰
python is actually just 90% bloat
so?
who is this diva
Ugh!: interjection All: pronoun these: adverb types: noun make: verb it: pronoun so: adverb hard: adverb to: particle read: verb
@@davidmurphy563 Really? I introduce you to statically typed languages, then, even "worst", you're forced to put the complete type for each variable declaration!
@foxypiratecove37350 In that case type declarations are usually separate and don't harm readability.
@Dimitrius1991 Not really, it's always near the variable's name. Also it's more readable `var: Type = val` as "`var` of type `Type` which is equal to `val`", instead of `Type var = val;` that you or have to reverse the order of the type and the name, or have to say it in an unusual order: "a variable of type `Type` named `var` which is equal to `val`". But at the end, it's you that chose.
@foxypiratecove37350 I mean, it's more readable when a declaration and the corresponding assignment are not in the same line, especially if the type name is long. Also, I've had enough of static typing already.😆
@@Dimitrius1991 Not true. I wish C and C++ type declarations were as well separated as Python ones. Try to decipher what the following declares in C:
void(**f)(void *(*g)());