It’s actually the set-union operator in this context. It is spelled the same as the bitwise-or operator, but it’s not the same thing because it applies to the set type, not a binary number.
@@meowsqueak it actually can be considered as logical operator, because sets are mathematically identical to predicates which forms these sets. So a set operation on sets is actually a logical operation on their predicates.
@@christophertaylor5003I was trying to say that the set-union operator (or logical OR operator if you like) is not the same as the *bitwise* OR operator, which is usually spelled "|" ("pipeline", "pipe").
I've seen dozens of "python tips" videos like this and learned almost nothing. They went from giving tips everybody knows to outright horrendously bad code. This one is the first where I actually learned something (that you can pass functions as first class objects) and every tip was actually relatively unknown, but still useful and presented in well written code. Compliment!
the custom __format__ can be useful when you have sort of vector class and want to print its value with standard spec. like with f"{vec:.1f}" you get "(1.5, 3.0, 4.7)" and with f"{vec:.2f}" you get "(1.50, 3.01, 4.68)"
also imagine a direction vector where the length doesn't really matter, you could either want to receive x1, x2, xn, ... with value 1 or the normalized vector with length one and therefore different scalars. The format dunder is very useful there.
Important: when using dict.get, remember to check against is None, rather than an implicit truth check. Empty strings are considered falsy, which may lead to unexpected behaviour. These are 2 extra words that will help you not write bugs
1. when doing a[], you can extract as a variable of type "slice". for example a[slice(None,None,1)] is the same as a[::-1] 2. bit operations & | work with sets too 3. f-strings can be formated, __format__ can be implemented on types 4. You can use the walrus operator (a:=b) for its intended purpose, which is using it in if statements 4. curry is possible in python
4:49 Please be warned that "match" was only introduced in Python 3.10 which is relatively recent On another note, I personally use this for only one purpose, which is to allow debug prints, it looks like this: print(f"{my_class:d1}") d1 is basically "debug-1" which essentially means "print this object with little information". The implementation looks something like this: class Example: def __init__(self, field1: str, field2: str, field3: str, field4: str) -> None: self.field1: str = field1 self.field2: str = field2 self.field3: str = field3 self.field4: str = field4 def __format__(self, __format_spec: str) -> str: if __format_spec.startswith("d"): level = int(__format_spec[1:]) fields = ["field1"] if level > 1: fields.append("field2") if level > 2: fields.append("field3") if level > 3: fields.append("field4") fields_dict = { field_name: self.__dict__[field_name] for field_name in fields } return f"{self.__class__.__name__} {fields_dict}" The actual implementation I use is a bit different, to give better error messages, and to override __str__ to use this (so you can do print(example) directly) but you get the idea...
im just self-taught with python making programs for the last 4 years, but you just showed me (and i had no idea), that you could do self.__dict__ to get the defined variables from the __init__ of a class.... or the self.__class__.__name__... im assuming there must be one for getting the functions names of a class as well
@@resresres1 __dict__ gives you all fields of any object, and Python classes are also objects (I'm not talking about the instances of a class, but the class itself) If you use __dict__ on an *instance*, you get its fields, if you use it on the *class*, you get all static data, meaning methods, but also class constants. Python makes no distinction between functions and variables, they're all entries in the dictionary of the class, you can even define your own function as if it was a variable (obviously don't do that, it's unreadable and your IDE will probably loose its marbles). So this: class Example: EXAMPLE_CONST = "CONST VALUE" function_as_var = lambda self: self.some_func() def __init__(self) -> None: self.some_var = "value" def some_func(self): print("I've been called!") def print_self_dict(self): print(f"Static dict {self.__class__.__dict__} ") # Same as Example.__dict__ print(f"Object dict {self.__dict__}") # Same as Example().__dict__, assuming same instance example = Example() example.print_self_dict() example.function_as_var() prints out this: Static dict { '__module__': '__main__', '__doc__': "I'm a doc string and Python recognizes me at runtime!", 'EXAMPLE_CONST': 'CONST VALUE', '__init__': , 'some_func': , 'print_self_dict': , '__dict__': , '__weakref__': } Object dict {'some_var': 'value'} I've been called!
This is a totally fine "python features I love" video, but i have one recommendation for the young folks out there. Try not to use the build in set operators as recommend in the video. Stay with the methods which are way more explicit in what they are doing compared to the single characters of the build in operators. They can hide some nasty bugs when not 100% tested.
Using single operators seems more pythonic to me. Calling the methods reminds me the Java way. It's more explicit for someone that doesn't know Python as much, I think it's more verbose. Correct me if I'm wrong, please. It's just an opinion.
The final example, the return type should be Callable[[float],float], to be more specific. I'm not sure if the ide will infer the contents of [...] there, but if it doesn't then you either should specify that, or not specify a return type.
I went for that approach originally, but it wasn't ideal for the explanation in the tutorial, and since this video wasn't about type annotations, I excluded that bit. Please continue with annotating your types appropriately regardless of what I show in the video :)
While your full annotation is indeed more specific, just specifying Callable will still be better than not annotating at all. Your type checker will validate against whatever annotation you provide, to whatever level of specificity.
@@keoghanwhimsically2268 Most if not all static type checker can infer the typing from the return statement. The return type annotation is mostly only useful for self documenting code and to enforce a return type. So Callable by itself is too vague (in my opinion) to do either of the job, thus allowing the inference to take over is more desirable (at least for me) than only partially typing a callable. In the example the return type is just Callable, this'll mean the type checker will allow you to give any number of arguments and any type of argument to the returned function, which can cause a runtime error. If the return type wasn't annotated then the type checker will accurately infer the type from the return statement, thus it'll appropriately throw error and a runtime error could be avoided. Inference also works at assignment and if you have a default value for an argument you can allow the argument's type to be inferred. I personally use inferred typing for assignment and return types,but for production code, I'll recomend typing everything, so that the code can be understood at first glance. Hope this helps.
@@keoghanwhimsically2268 Most if not all type checker have a system called inference. This allows you to not specify type for something and still have it typed. In case of return types the compiler can look at the return statement check the type of variable/variables being returned and infer the return type of the function to be the type/union of the types of the variable/variables being returned, as long as the return type of the function is not specified. If the return type of a function is specified, the type checker checks the type of the returned variable against the return type. Now in my opinion type checking is done for two purpose, documentation and type checking. In the given example the type Callable is too vague, to work for either documentation or type checking. So if the return type wasn't annotated, the type checker could infer the type properly thus potentially avoiding a runtime error. You can have inference take over at, variable assignment/initialisation, argument with default value and return type of a function. I most often use inference at assignment and return types in my personal projects, but for a group project or an oficial project annotating everything is desirable as it allows others to understand the code at a glance. Hope this makes sense and is useful, if you have other query please ask away.
Oh yeah, I'mve use walrus operators so many times, especially for validating user input in a while loop. It's so much easier than having to set a default value.
This is your best video yet IMHO. I didn't know 100% of any of the topics you covered, and while I knew about all of the set operations, I'd no idea you could do the same thing with operators... very cool. Great job! Keep it up!
Whenever programming in numpy (or it's children) the combination of slice objects and boolean index masks are so powerful. You can make the hardest part of convolutional neural networks (from scratch) as legible as a standard loop and multiply pattern.
Thanks for the video. I do think the jump cuts where the code changes between the cuts (to fix a bug, for example) makes it harder for beginners to follow along. It would be better to fix the errors in the video, IMO.
Good tips! I used currying to create a text-based prefix notation calculator interface where the parser didn’t need to worry or know about function arity because all functions have an arity of one.
Set operations also work with inplace operators like |= and -=. In newer Python versions "|" also works with dicts. Walrus operator is great for regex matching i.e. "if match := re.match(...)". Currying is super useful for giving parameters to decorators. Also Callable should be used with parameters to give a more accurate type.
As well as | for dicts you can also use the other set operations on dict.keys(). This can be very useful if you want to iterate over part of a dict: for k in record.keys() - {'password'}: print(f"{k}: {record[k]}") but you do have to be careful that while dict.keys() is ordered sets aren't so don't do this if the order matters.
In Java, you can write docs(/** */) above the functions, and on mouseover, you can read those docs. You could write which types the converter can handle if that exists in Python.
Great video! The slice trick will be helpful, and I didn't know about that use of the walrus operator you showed inside the dictionary. The walrus operator can also be handy inside of comprehensions if you need to compute something with each element in an iterable, and you want to keep the computational results rather than the original items.
The proper type annotation for the `format_spec` parameter is `str`, not `Any`. It's passed as a string after all, and not simply whatever type Python wants.
There is a slightly cleaner way of building slice objects. The issue is that the slice function doesn't use slice notation. I much prefer using a 'slicebuilder' object, constructed such that you would get the same as slice(None, None, -1) by writing slicebuilder[::-1]. It really isn't hard to do, it is just an object that has __getitem__(self, key) returning the key. This lets you build slices using standard slice notation.
7:34 if, instead of `Any` you could set `format_spec` to be an enum, an array, or a union type, `__format__` would be more useful, and would not require documentation. At least for the IDE, if not the runtime, it would autocomplete. I don't know python enough. Maybe this is already possible, but as you didn't mention this option, I assume it can't.
So I can understand better, do you mind providing a quick example of what you mean by that? What I was trying to say in the video is that it's nearly impossible to use any of these format specifiers without reading documentation, or even taking a glance at the code of the class first. With a lot of classes, you can intuitively use its methods and functionality without having to open up the class, but with format specifiers, I have no idea how you would guess which ones you could use with such a random object as Book() from the start.
@@Indently I was hoping that something like that would trigger the IDE's autocomplete (in `print(f'{hairy_potter:`), but I was probably expecting too much :) ``` from typing import Literal, Type BookFormatSpec: Type[str] = Literal['time', 'caps'] class Book: def __init__(self, title: str, pages: int): self.title = title self.pages = pages def __format__(self, format_spec: BookFormatSpec) -> str: if format_spec == 'time': return f'{self.title} will take {self.pages//60} hours to read' elif format_spec == 'caps': return self.title.upper() else: raise ValueError(f'Unknown format {format_spec}') def main(): hairy_potter = Book('Very Hairy Potter', 300) python_daily = Book('Python Daily', 20) print(f'{hairy_potter: if __name__ == "__main__": main() ```
Editors such as vscode usually pop up the docstring when you're typing a function call. They could easily display the docstring for the object's __format__ function (assuming the type is known) but so far as I can see vscode doesn't bother doing that. I haven't checked PyCharm. If you use Literal for the type of the format string vscode will offer completion on the format but it also offers all other names in the program. so not a big help unless you start all the format strings with 'z' or some unique prefix. The problem with literal is it does have to be literal, you can't do formats with embedded numbers that way.
Nice video! Loved the little tips and tricks. At least for set operations though, I guess I will keep using the dot method because when I will open the code after a week, I would have probably forgotten what those meant and find myself in a mess. 😅
The dot operators are just as good, but think of it like this: a & b = the elements that are in a AND are in b (intersectoin) a | b = the elements that are in a OR are in b (union) You can even use - to get the set difference: a - b = the elements in a that are not in b (difference) Symmetric difference is easy, too: (a - b) } (b - a) = the elements that are in a but not b, and the elements of b that are not in a. Seems strange that + cannot be used for unions of sets, though.
I use the walrus operator quite often. I think python has made a good effort to minimize the risk of having accidental assignment instead of comparison in boolean evaluations like you'd have in c-like languages.
Oh! This is the first time I know about custom format specifiers! I'd love to use them in my personal projects too! Would be nice to be able to quickly get some commonly used value from a class without going through the whole hierarchical tree of objects...
Got a score of 3 out of 5 (if you include partials as currying) 😎 I'm struggling to see why you wouldn't just use partials, though it's funny to see that partials and decorators are technically created in the same way lmao.
First four are a great display of python features, the last one tho, it's not really a python feature as it is a functional design pattern present in any language with higher order functions. I still feel like it's kind of awkward in Python and is much more intuitive in Scala. But partial helps a bunch with that. I kinda feel bad using Callable as a return type. It's a shame that arrow can't be used to declare a function type like def func(a: flaot) -> float -> float. It's not perfect but i feel like it gives more info of what's actually geting returned
Those set operator are nice to know for code reading purposes, but I rather like them explicit: set_a.union(set_b) set_a.intersection(set_b) set_a.difference(set_b) set_b.difference(set_a) Also a big fan of the walrus feature. That feature saved me execution time on test scenarios where a condition had to be checked using UI browser interactions. Previously I'd be using janky tricks to move that condition checking inside the code block as a var, but that make the whole condition block rather opaque to read.
Interesting. As a mathematician, I prefer the more succinct | and & operators. Perhaps that's because, as a (mostly) reformed C programmer, I know those as the 'or' and 'and' operators, and it's natural to associate "or" with "union" and "and" with "intersection".
One thing I noticed when playing with this format function is that it will implicitly cast anything to string, if you have f"{foo:1}" you will have "1" in the foo's format class. Also you can't use variable or funtions here, their names will simply be given over as strings. Also Python will raise a TypeError Error if you try to return anything other than a string in __format__. Next you can use the walrus operator even in list comprahention: import string from itertools import product lower=string.ascii_lowercase upper=string.ascii_uppercase print([(i, U, l) if U.lower()
You can use variables or call functions inside the format string, but you have to enclose them in curly braces: print(f"{foo:strange {bar} format}") subtitutes the stringified value of 'bar' in the format string before calling foo.__format__.
For the set operations, don't call them "pipe" and "ampersand", call them "or" and "and". "a or b" gives you all elements that are in a or b, "a and b" gives you all elements that are in both a and b. (Oh, I forgot Python actually spells out "and", "or", "not" for booleans)
For the purposes of explanation I'm of the opinion it's better to mention the names of the characters themselves. It's a bit clearer than saying "and" or "or" when those operators already exist in a different format, and then you have those symbols for bitwise operations as well which is technically misleading in the context of sets. Sure advanced users will understand but beginners may not. That turned into more of a rant than I was originally aiming for, oops!
But they aren’t the logical and/or operators. Nor are they the bitwise and/or operators. They are the set intersection and union operators. To describe them properly, you have to use the character names. You could also mention they look the same as the bitwise and/or operators, as that might help. They are unrelated to the logical and/or operators.
On the topic of custom format specifiers, I think theres an argument to be made about providing an interface for truly unique ones, but implementing standard ones also has its benefits. For instance, maybe you want to adhere to printf format specifiers, so %d is for the 32-bit signed integer representation of your object. Meanwhile, I know that C# has some short format specifiers, such as DateTime having an "s" for "sortable" string formats. Personally, this is kind of nice, because I have had the situation where __repr__ and __str__ weren't enough for the different formats I wanted to provide, but I wasnt aware of any alternatives. For those hearing about these for the first time, __str__ is generally the "pretty" version of your data, while __repr__ is the stringified version of how an outside would represent your object, often using the __init__ signature, but an argument can be made for alternatives. Also, there's a failover that can happen (I believe from __str__ down to __repr__) but, as previously mentioned, they are supposed to be used for two different reasons
In the currying example, why wouldn't you just use lambda? Something like: def multiplier(a: float) -> Callable[[float], float]: return lambda x: x * a double = multiplier(2) triple = multiplier(3)
Because that's an unrealistically easy example that I only used to teach the concept of currying, if it gets more complicated your lambda may be impossible to read.
The walrus operator is useful for me for like error checking, when i only need the value if i go in the branch and i dont want to use a line for it. One big downside is that it has a very low precedence, meaning "if user := users.get(3) is None" would actually mean the value of user would be the result of the "users.get(3) is None", so it's always good to use parentheses. Another thing that came to my mind from this video is sometimes (especially for newer features) it might be useful to include the minimum python version it requires. All your examples are supported in 3.8 so it's not relevant here, but I noticed you also use the type union (at 8:30) which is only supported in 3.10 I had a funny issue with that because in an environment i run my codes actually run on 3.8 and the file was failing silently only showing that my code did not exist and took hours to figure it out.
You're right, I should start mentioning what versions features are supported in. Now that the channel has grown, and I'm not a little boy anymore, I have a duty to provide more information in my videos (or at least mention when a feature is relatively new) :)
Counting the total characters should be done with something like sum(map(len, words)) instead of len(''.join(words)). That way you dont build the entire string in memory, but just count the individual words
Very cool, thanks! I don't think all of them are particularly readable, but it's probably partly due to that I'm not accustomed to them. I'll definitely want to learn and adopt some of the operators from here (especially from #2 and #4) 😉
The concept of "Callable" is kind of a joke for JavaScript where you live surrounded by functions that return functions than take function as parameters
i'm too new to python to comment on whether this is a good style of coding, with my little experience, mainly with ttk tkinter, i find it somewhat lacking in the manner by which data is passed, probably because i am so knew, i was able to construct the proper functionality regardless, through trial and error, but i think what you are talkning about could make a difference in how i code using lists, i tried something like what you describe in this video to connect a str to a list of ints in order to display the results from a buttonpress, but i obviously didn't it get the results i wanted and ended up going with a simple if statement, i would like to be able to use a single variable to set to conditions then reset to do it again, so i think i can use your dictionary concept to do that, i subscribed, so somewhere in the future if i am successful at it, i will let you know, anyway, great video
@@lgf-sq9yf Python is weakly typed, it's just completely futile and would waste your time unless you choose to be inconsistent, in which case your code would be even worse because you're not following the same practices
Is the walrus variable scoped to the then&else branches? Or does it still exist once the if is done, ie. past line 6? If it's scoped then that's a massive point in favour in my book :-) Thanks for the clear and to the point video!
Hey Indently. Just so you know, there is a lot of noise in the sound on the low-end, especially popping out of my sub when you type on your keyboard. Could be a good idea to dampen the frequencies you record that are outside the range of your enjoyable voice. Much respect. Peace.
The second parameter of slice _is not_ the index! It's _how many_ elements long the slice should be. You'll notice that in the list, "index 5" would actually be 6, since indices in Python start at 0 😉 Off-by-one, anybody?
If I said that I misspoke, thank you for pointing it out for anyone who got confused by that. I tried my best to specify that you can use a slice object the same way you use slice notation, so regardless of what I said, it should be fine if people follow that principle 😎
For anyone that hasn't programmed in a functionnal language at its core, this is not currying. It achieves the same goal, but it's almost as inneficient as passing the parameter by hand.
that's actually not true, in golang it's a very common operator, and for someone with experience in go, i'm glad that we can also do that in python. With experience this can help a developer or a team of developers to have a better knowledge of what variables are being used by the code and where, and if this is just used on that piece of code, this is probably the best way to use this variable, since the variable will be deleted after the use.
It can actually improve readability in cases like simultaneously assigning a variable and evaluating its boolean value for a conditional. Especially if that variable is only used inside the *if* block
📝 Summary of Key Points: 📌 The first trick shared in the video is about creating slice objects in Python to avoid repetitive code when slicing iterables. By using slice objects, you can easily modify the slicing implementation in one place. 🧐 The second trick involves using set operators in Python to perform set operations like combining sets, subtracting elements, finding intersections, and getting unique elements efficiently. 🚀 The third trick demonstrates how to make a class compatible with F-strings by defining custom format specifiers using the __format__ method. This allows for specialized formatting of class attributes in F-strings. 💡 Additional Insights and Observations: 💬 One memorable concept introduced is the use of the walrus operator in Python to streamline code and assign values within conditional statements efficiently. 📊 The video showcases practical examples of currying functions in Python, which can simplify repetitive function calls with predefined setups. 📣 Concluding Remarks: The video covers five uncommon Python tricks and features, including creating slice objects, utilizing set operators, customizing F-string specifiers, leveraging the walrus operator, and implementing currying functions. These tricks offer practical ways to enhance code efficiency and readability in Python programming. Generated using TalkBud
I learn fastapi and i find out that i use currying, when set up post, delete methods. This 2 operations require identifier to find item. So i put find_by_id function inside those metods and then define next steps. Some sort of state managment
The walrus operator irks me a little. In a handful of simple ifs (and possibly in list comprehensions) its probably fine, but using it pretty much anywhere else I'd argue is a code smell.
I like Python's slice syntax, and it's good that I've seen this video to know that I can save a slice format because this is yet another feature I think my own language was missing. I finally upgraded my local copy of Python to 3.9 last year, and apparently the "walrus" operator and the match statement were added in 3.10, which is kind of annoying. Oh well, just need to checkout a later version, and I'm aiming for v3.11.0 and ask me in a couple of hours if it works, because yes I am that paranoid to run `make test`. One thing I keep wondering though, why doesn't Python implement operator+ for most things. For sets it makes sense to have operator| instead, but it wouldn't hurt to make operator+ be an alias or even do something weird like collapse a set into an array. I implemented + and += for all of the container classes in my standard library, both for single elements and other containers. It makes no sense to me why people keep pushing back on that.
The b parameter is coming from the enclosed def multiply(b). The multiply_setup(a) returns that multiply(b) function, so when the result is called, that becomes the b parameter.
`multiply_setup` returns a function which accepts one parameter, which is `b`. So `double = multiply_setup(2)` is setting `double` to a function, and calling `double(3)` will call the function with `b = 3`.
Thanks, I almost broke my brain figuring this out🎉 Not sure if it is really worth, maybe I just need a a better use case. My problem was that I watched at the callable, but completely omitted the double and 'triple' examples. After that it went smooth❤
Basically multiply-setup() is being used to create some functions with similar, uh, functionality. So when you call multiply-setup(2) it's going to return a function that will multiply anything by 2. In this case, it's called double() If I was asked to do this I'd use lambdas, because I use lambdas a lot in my python code, but that's just me.
@@chemicals8582i use lambdas a lot in other languages, but the python syntax is kinda clunky imo, "lambda x: x * x" is more clunky than "(x) => x * x" or "|x| x * x"
It's my teachings style, I try not to confuse beginners with too much terminology. What you said is accurate, but it's not appropriate for this video. I accept that I will get roasted by more experienced / pedantic devs for this. Thank you for trying to help though!
@@IndentlyNo worries, good of you to reply, it's ok to use vernacular but please also teach the correct term afterwards, as you did with "symmetric difference" for example.
The last one is properly called Decorator. I usually don’t define the type. That is an advantage of Python if you just want to make simple code. Probably include it when It serves the purpose of clarity. Using it everywhere will make the code harder to read. Just my thought.
currying is the correct termonology here, currying is the act of usually taking a single argument and returning a function using that argument and taking the next argument, it can go on recursively forever a decorator is a wrapper a function or object with the same signature usually in object oriented code python decorators (@ syntax) is basically currying, they dont conform to the same signature
For the format spec, why not just do if format_spec == '': elif format_spec == '': (... and so on) also I dont think it should be Any for format_spec, it should be format_spec: str. I tried this and it results in a TypeError: class something: pass def __format__(self, format_spec): if format_spec == 's': return 'Spec1' elif format_spec == 99: return 'Spec2' x = something() y = 99 print(f'{x:s}') print(f'{x:{y}}')
The "pipeline" on sets is not a pipeline, but the OR operator (returning a set containing all elements which are in either A or B).
Isnt the character called "pipe"? Or am i wrong?
It's called pipe but is seen as OR in programming languages
like how ^ is exponent but is seen as XOR
It’s actually the set-union operator in this context. It is spelled the same as the bitwise-or operator, but it’s not the same thing because it applies to the set type, not a binary number.
@@meowsqueak it actually can be considered as logical operator, because sets are mathematically identical to predicates which forms these sets. So a set operation on sets is actually a logical operation on their predicates.
@@christophertaylor5003I was trying to say that the set-union operator (or logical OR operator if you like) is not the same as the *bitwise* OR operator, which is usually spelled "|" ("pipeline", "pipe").
00:13 Using slice object
02:03 Set operators
03:51 Custom object string format
07:52 Walrus operator :=
11:51 Currying
I've seen dozens of "python tips" videos like this and learned almost nothing. They went from giving tips everybody knows to outright horrendously bad code. This one is the first where I actually learned something (that you can pass functions as first class objects) and every tip was actually relatively unknown, but still useful and presented in well written code. Compliment!
the custom __format__ can be useful when you have sort of vector class and want to print its value with standard spec. like with f"{vec:.1f}" you get "(1.5, 3.0, 4.7)" and with f"{vec:.2f}" you get "(1.50, 3.01, 4.68)"
Ohh this makes sense
also imagine a direction vector where the length doesn't really matter, you could either want to receive x1, x2, xn, ... with value 1 or the normalized vector with length one and therefore different scalars. The format dunder is very useful there.
Important: when using dict.get, remember to check against is None, rather than an implicit truth check. Empty strings are considered falsy, which may lead to unexpected behaviour. These are 2 extra words that will help you not write bugs
1. when doing a[], you can extract as a variable of type "slice".
for example a[slice(None,None,1)] is the same as a[::-1]
2. bit operations & | work with sets too
3. f-strings can be formated, __format__ can be implemented on types
4. You can use the walrus operator (a:=b) for its intended purpose, which is using it in if statements
4. curry is possible in python
I would use partial for simple currying, but function returning functions for more complex or customised currying.
I've been using Python for almost 5 years now and im still learning something new everyday from your channel! I love your explanation style ❤
Python ist very complex, more so than Rust apparently
I'm a python developer since about 2012, and EVERYTHING here was new and useful to me!
@@climatechangedoesntbargain9140 you must be out of your mind
4:49 Please be warned that "match" was only introduced in Python 3.10 which is relatively recent
On another note, I personally use this for only one purpose, which is to allow debug prints, it looks like this:
print(f"{my_class:d1}")
d1 is basically "debug-1" which essentially means "print this object with little information". The implementation looks something like this:
class Example:
def __init__(self, field1: str, field2: str, field3: str, field4: str) -> None:
self.field1: str = field1
self.field2: str = field2
self.field3: str = field3
self.field4: str = field4
def __format__(self, __format_spec: str) -> str:
if __format_spec.startswith("d"):
level = int(__format_spec[1:])
fields = ["field1"]
if level > 1:
fields.append("field2")
if level > 2:
fields.append("field3")
if level > 3:
fields.append("field4")
fields_dict = {
field_name: self.__dict__[field_name] for field_name in fields
}
return f"{self.__class__.__name__} {fields_dict}"
The actual implementation I use is a bit different, to give better error messages, and to override __str__ to use this (so you can do print(example) directly) but you get the idea...
Neat idea!
im just self-taught with python making programs for the last 4 years, but you just showed me (and i had no idea), that you could do self.__dict__ to get the defined variables from the __init__ of a class.... or the self.__class__.__name__... im assuming there must be one for getting the functions names of a class as well
@@resresres1 __dict__ gives you all fields of any object, and Python classes are also objects (I'm not talking about the instances of a class, but the class itself)
If you use __dict__ on an *instance*, you get its fields, if you use it on the *class*, you get all static data, meaning methods, but also class constants. Python makes no distinction between functions and variables, they're all entries in the dictionary of the class, you can even define your own function as if it was a variable (obviously don't do that, it's unreadable and your IDE will probably loose its marbles).
So this:
class Example:
EXAMPLE_CONST = "CONST VALUE"
function_as_var = lambda self: self.some_func()
def __init__(self) -> None:
self.some_var = "value"
def some_func(self):
print("I've been called!")
def print_self_dict(self):
print(f"Static dict {self.__class__.__dict__}
") # Same as Example.__dict__
print(f"Object dict {self.__dict__}") # Same as Example().__dict__, assuming same instance
example = Example()
example.print_self_dict()
example.function_as_var()
prints out this:
Static dict {
'__module__': '__main__',
'__doc__': "I'm a doc string and Python recognizes me at runtime!",
'EXAMPLE_CONST': 'CONST VALUE',
'__init__': ,
'some_func': ,
'print_self_dict': ,
'__dict__': ,
'__weakref__':
}
Object dict {'some_var': 'value'}
I've been called!
specifically for debugging mode, a dunder method ___repr___ was provided, which is called in f-strings as follows:
f"{object!r}"
We: pronoun don’t need: verb type hints: noun cluttering your example: noun. 🤮: emoji.
This is a totally fine "python features I love" video, but i have one recommendation for the young folks out there. Try not to use the build in set operators as recommend in the video. Stay with the methods which are way more explicit in what they are doing compared to the single characters of the build in operators. They can hide some nasty bugs when not 100% tested.
Using single operators seems more pythonic to me. Calling the methods reminds me the Java way. It's more explicit for someone that doesn't know Python as much, I think it's more verbose.
Correct me if I'm wrong, please. It's just an opinion.
The final example, the return type should be Callable[[float],float], to be more specific.
I'm not sure if the ide will infer the contents of [...] there, but if it doesn't then you either should specify that, or not specify a return type.
I went for that approach originally, but it wasn't ideal for the explanation in the tutorial, and since this video wasn't about type annotations, I excluded that bit. Please continue with annotating your types appropriately regardless of what I show in the video :)
@@Indentlythought I should point it out as no one else did.
While your full annotation is indeed more specific, just specifying Callable will still be better than not annotating at all. Your type checker will validate against whatever annotation you provide, to whatever level of specificity.
@@keoghanwhimsically2268 Most if not all static type checker can infer the typing from the return statement.
The return type annotation is mostly only useful for self documenting code and to enforce a return type.
So Callable by itself is too vague (in my opinion) to do either of the job, thus allowing the inference to take over is more desirable (at least for me) than only partially typing a callable.
In the example the return type is just Callable, this'll mean the type checker will allow you to give any number of arguments and any type of argument to the returned function, which can cause a runtime error.
If the return type wasn't annotated then the type checker will accurately infer the type from the return statement, thus it'll appropriately throw error and a runtime error could be avoided.
Inference also works at assignment and if you have a default value for an argument you can allow the argument's type to be inferred.
I personally use inferred typing for assignment and return types,but for production code, I'll recomend typing everything, so that the code can be understood at first glance.
Hope this helps.
@@keoghanwhimsically2268 Most if not all type checker have a system called inference. This allows you to not specify type for something and still have it typed.
In case of return types the compiler can look at the return statement check the type of variable/variables being returned and infer the return type of the function to be the type/union of the types of the variable/variables being returned, as long as the return type of the function is not specified.
If the return type of a function is specified, the type checker checks the type of the returned variable against the return type.
Now in my opinion type checking is done for two purpose, documentation and type checking.
In the given example the type Callable is too vague, to work for either documentation or type checking. So if the return type wasn't annotated, the type checker could infer the type properly thus potentially avoiding a runtime error.
You can have inference take over at, variable assignment/initialisation, argument with default value and return type of a function. I most often use inference at assignment and return types in my personal projects, but for a group project or an oficial project annotating everything is desirable as it allows others to understand the code at a glance.
Hope this makes sense and is useful, if you have other query please ask away.
Oh yeah, I'mve use walrus operators so many times, especially for validating user input in a while loop. It's so much easier than having to set a default value.
This is your best video yet IMHO. I didn't know 100% of any of the topics you covered, and while I knew about all of the set operations, I'd no idea you could do the same thing with operators... very cool. Great job! Keep it up!
Whenever programming in numpy (or it's children) the combination of slice objects and boolean index masks are so powerful. You can make the hardest part of convolutional neural networks (from scratch) as legible as a standard loop and multiply pattern.
Great video! Btw love HAIRY Potter 😂
HARRY ❌ HAIRY ✅...🗿🗿🗿
Hairy Potter and the Barber of Azkaban
By the way, Snape's name in the Italian translation is Piton, so seeing "Daily Python" just below was additionally funny for me.
Thanks for the video. I do think the jump cuts where the code changes between the cuts (to fix a bug, for example) makes it harder for beginners to follow along. It would be better to fix the errors in the video, IMO.
Every video I watched so far, I learned at least one thing new. Great work, thanks!
Good tips! I used currying to create a text-based prefix notation calculator interface where the parser didn’t need to worry or know about function arity because all functions have an arity of one.
Set operations also work with inplace operators like |= and -=. In newer Python versions "|" also works with dicts.
Walrus operator is great for regex matching i.e. "if match := re.match(...)".
Currying is super useful for giving parameters to decorators. Also Callable should be used with parameters to give a more accurate type.
As well as | for dicts you can also use the other set operations on dict.keys(). This can be very useful if you want to iterate over part of a dict:
for k in record.keys() - {'password'}:
print(f"{k}: {record[k]}")
but you do have to be careful that while dict.keys() is ordered sets aren't so don't do this if the order matters.
Who on earth came up with the term "walrus operator" for := ? I can't see any connection to a walrus.
@@__christopher__ I think the idea is if you turn your head on its side you get a face with two eyes ':' and a walrus moustache '='. Maybe.
It's a pair of tusks, not a moustache!
In Java, you can write docs(/** */) above the functions, and on mouseover, you can read those docs. You could write which types the converter can handle if that exists in Python.
Great video! The slice trick will be helpful, and I didn't know about that use of the walrus operator you showed inside the dictionary. The walrus operator can also be handy inside of comprehensions if you need to compute something with each element in an iterable, and you want to keep the computational results rather than the original items.
I've finnaly understood the Callable function. Thank you. ^^
The proper type annotation for the `format_spec` parameter is `str`, not `Any`. It's passed as a string after all, and not simply whatever type Python wants.
There is a slightly cleaner way of building slice objects. The issue is that the slice function doesn't use slice notation. I much prefer using a 'slicebuilder' object, constructed such that you would get the same as slice(None, None, -1) by writing slicebuilder[::-1]. It really isn't hard to do, it is just an object that has __getitem__(self, key) returning the key. This lets you build slices using standard slice notation.
I really wish there was a built-in python methods to do these conversions. slice[x:y:z]? slice.from_str(''x:y:z")?
7:34 if, instead of `Any` you could set `format_spec` to be an enum, an array, or a union type, `__format__` would be more useful, and would not require documentation.
At least for the IDE, if not the runtime, it would autocomplete.
I don't know python enough. Maybe this is already possible, but as you didn't mention this option, I assume it can't.
You can also use Literal["time", "caps"]
So I can understand better, do you mind providing a quick example of what you mean by that?
What I was trying to say in the video is that it's nearly impossible to use any of these format specifiers without reading documentation, or even taking a glance at the code of the class first. With a lot of classes, you can intuitively use its methods and functionality without having to open up the class, but with format specifiers, I have no idea how you would guess which ones you could use with such a random object as Book() from the start.
@@Indently I was hoping that something like that would trigger the IDE's autocomplete (in `print(f'{hairy_potter:`), but I was probably expecting too much :)
```
from typing import Literal, Type
BookFormatSpec: Type[str] = Literal['time', 'caps']
class Book:
def __init__(self, title: str, pages: int):
self.title = title
self.pages = pages
def __format__(self, format_spec: BookFormatSpec) -> str:
if format_spec == 'time':
return f'{self.title} will take {self.pages//60} hours to read'
elif format_spec == 'caps':
return self.title.upper()
else:
raise ValueError(f'Unknown format {format_spec}')
def main():
hairy_potter = Book('Very Hairy Potter', 300)
python_daily = Book('Python Daily', 20)
print(f'{hairy_potter:
if __name__ == "__main__":
main()
```
Now I get what you mean, it would be super cool to get that kind of context completion, I agree!
Editors such as vscode usually pop up the docstring when you're typing a function call. They could easily display the docstring for the object's __format__ function (assuming the type is known) but so far as I can see vscode doesn't bother doing that. I haven't checked PyCharm.
If you use Literal for the type of the format string vscode will offer completion on the format but it also offers all other names in the program. so not a big help unless you start all the format strings with 'z' or some unique prefix. The problem with literal is it does have to be literal, you can't do formats with embedded numbers that way.
Nice video! Loved the little tips and tricks. At least for set operations though, I guess I will keep using the dot method because when I will open the code after a week, I would have probably forgotten what those meant and find myself in a mess. 😅
The dot operators are just as good, but think of it like this:
a & b = the elements that are in a AND are in b (intersectoin)
a | b = the elements that are in a OR are in b (union)
You can even use - to get the set difference:
a - b = the elements in a that are not in b (difference)
Symmetric difference is easy, too:
(a - b) } (b - a) = the elements that are in a but not b, and the elements of b that are not in a.
Seems strange that + cannot be used for unions of sets, though.
I use the walrus operator quite often. I think python has made a good effort to minimize the risk of having accidental assignment instead of comparison in boolean evaluations like you'd have in c-like languages.
These kinds of videos makes me relize how much I don't know about python
Oh! This is the first time I know about custom format specifiers! I'd love to use them in my personal projects too! Would be nice to be able to quickly get some commonly used value from a class without going through the whole hierarchical tree of objects...
Great explanation of the walrus operator. I've struggled to understand it for a while, but I think I've got a good grasp now! Very useful trick.
walrus and slice object was cool, thanks.
The walrus operator is really nice
Got a score of 3 out of 5 (if you include partials as currying) 😎 I'm struggling to see why you wouldn't just use partials, though it's funny to see that partials and decorators are technically created in the same way lmao.
You r the best.... python teacher...!
love from bangladesh.
First four are a great display of python features, the last one tho, it's not really a python feature as it is a functional design pattern present in any language with higher order functions. I still feel like it's kind of awkward in Python and is much more intuitive in Scala. But partial helps a bunch with that.
I kinda feel bad using Callable as a return type. It's a shame that arrow can't be used to declare a function type like def func(a: flaot) -> float -> float. It's not perfect but i feel like it gives more info of what's actually geting returned
gotta thank the walrus operator for saving me on my exam, such a great feature
Those set operator are nice to know for code reading purposes, but I rather like them explicit:
set_a.union(set_b)
set_a.intersection(set_b)
set_a.difference(set_b)
set_b.difference(set_a)
Also a big fan of the walrus feature. That feature saved me execution time on test scenarios where a condition had to be checked using UI browser interactions. Previously I'd be using janky tricks to move that condition checking inside the code block as a var, but that make the whole condition block rather opaque to read.
Interesting. As a mathematician, I prefer the more succinct | and & operators. Perhaps that's because, as a (mostly) reformed C programmer, I know those as the 'or' and 'and' operators, and it's natural to associate "or" with "union" and "and" with "intersection".
One thing I noticed when playing with this format function is that it will implicitly cast anything to string, if you have f"{foo:1}" you will have "1" in the foo's format class.
Also you can't use variable or funtions here, their names will simply be given over as strings. Also Python will raise a TypeError Error if you try to return anything other than a string in __format__.
Next you can use the walrus operator even in list comprahention:
import string
from itertools import product
lower=string.ascii_lowercase
upper=string.ascii_uppercase
print([(i, U, l) if U.lower()
You can use variables or call functions inside the format string, but you have to enclose them in curly braces: print(f"{foo:strange {bar} format}") subtitutes the stringified value of 'bar' in the format string before calling foo.__format__.
I didn't know that Python had a switch-case called match, I went to investigate and it was introduced in version 3.10, great.
I've been using the set operators for ages, but I've only just discovered f-strings and match. I still need to learn more about match.
For the set operations, don't call them "pipe" and "ampersand", call them "or" and "and". "a or b" gives you all elements that are in a or b, "a and b" gives you all elements that are in both a and b. (Oh, I forgot Python actually spells out "and", "or", "not" for booleans)
For the purposes of explanation I'm of the opinion it's better to mention the names of the characters themselves. It's a bit clearer than saying "and" or "or" when those operators already exist in a different format, and then you have those symbols for bitwise operations as well which is technically misleading in the context of sets. Sure advanced users will understand but beginners may not.
That turned into more of a rant than I was originally aiming for, oops!
But they aren’t the logical and/or operators. Nor are they the bitwise and/or operators. They are the set intersection and union operators. To describe them properly, you have to use the character names. You could also mention they look the same as the bitwise and/or operators, as that might help. They are unrelated to the logical and/or operators.
Your python code looks like Rust and I love it
On the topic of custom format specifiers, I think theres an argument to be made about providing an interface for truly unique ones, but implementing standard ones also has its benefits. For instance, maybe you want to adhere to printf format specifiers, so %d is for the 32-bit signed integer representation of your object. Meanwhile, I know that C# has some short format specifiers, such as DateTime having an "s" for "sortable" string formats.
Personally, this is kind of nice, because I have had the situation where __repr__ and __str__ weren't enough for the different formats I wanted to provide, but I wasnt aware of any alternatives. For those hearing about these for the first time, __str__ is generally the "pretty" version of your data, while __repr__ is the stringified version of how an outside would represent your object, often using the __init__ signature, but an argument can be made for alternatives. Also, there's a failover that can happen (I believe from __str__ down to __repr__) but, as previously mentioned, they are supposed to be used for two different reasons
Walrus operator is so cool!!!
Thanks to bring them up. 💯
Thanks for sharing, the set portion is very valuable.
Regarding set ops: if you can be explicit: rather use the member functions!! They also work with other iterable types!
Some very neat tricks, also very useful, thanks Indently for your continued efforts to improve the world of python.
I did not know about slice(), nice one!
Also, I somehow missed that type hints are now in Python (since 3.5, see PEP 484).
In the currying example, why wouldn't you just use lambda? Something like:
def multiplier(a: float) -> Callable[[float], float]:
return lambda x: x * a
double = multiplier(2)
triple = multiplier(3)
Because that's an unrealistically easy example that I only used to teach the concept of currying, if it gets more complicated your lambda may be impossible to read.
The walrus operator is useful for me for like error checking, when i only need the value if i go in the branch and i dont want to use a line for it.
One big downside is that it has a very low precedence, meaning "if user := users.get(3) is None" would actually mean the value of user would be the result of the "users.get(3) is None", so it's always good to use parentheses.
Another thing that came to my mind from this video is sometimes (especially for newer features) it might be useful to include the minimum python version it requires.
All your examples are supported in 3.8 so it's not relevant here, but I noticed you also use the type union (at 8:30) which is only supported in 3.10
I had a funny issue with that because in an environment i run my codes actually run on 3.8 and the file was failing silently only showing that my code did not exist and took hours to figure it out.
You're right, I should start mentioning what versions features are supported in. Now that the channel has grown, and I'm not a little boy anymore, I have a duty to provide more information in my videos (or at least mention when a feature is relatively new) :)
Amazing! Thank you fo rsharing!
This was amazingly well explained and useful! Thank you!
Counting the total characters should be done with something like sum(map(len, words)) instead of len(''.join(words)). That way you dont build the entire string in memory, but just count the individual words
Very cool, thanks! I don't think all of them are particularly readable, but it's probably partly due to that I'm not accustomed to them. I'll definitely want to learn and adopt some of the operators from here (especially from #2 and #4) 😉
All of this tips are awesome. I think Jetbrains IDEs should support format string completions
The literal type helps with custom format operations.
The concept of "Callable" is kind of a joke for JavaScript where you live surrounded by functions that return functions than take function as parameters
My first thought when I saw that was "oh, so a factory function"
Is there a reason you don't use the `Optional` type annotation?
Walrus operator in Python is a default behavior of assignments in Perl.
What about using literal type hint with the format dunder method?
I came to Python from C, and I didn't know about ':=', but it's something I used all the time with '=' in C.
Python seemingly never runs out of syntactic sugar to discover.
Python is all sugar syntax, if you wanna be a real man, learn C.
Hey could you do a series on try exceptions? I still don't full get it the different errors or exceptions. Thanks
Code is exprssion language. You really good express common language
i'm too new to python to comment on whether this is a good style of coding, with my little experience, mainly with ttk tkinter, i find it somewhat lacking in the manner by which data is passed, probably because i am so knew, i was able to construct the proper functionality regardless, through trial and error, but i think what you are talkning about could make a difference in how i code using lists, i tried something like what you describe in this video to connect a str to a list of ints in order to display the results from a buttonpress, but i obviously didn't it get the results i wanted and ended up going with a simple if statement, i would like to be able to use a single variable to set to conditions then reset to do it again, so i think i can use your dictionary concept to do that, i subscribed, so somewhere in the future if i am successful at it, i will let you know, anyway, great video
Don't annotate a string if python will know it's a string, it's pointless
It’s for developers lol
@@lgf-sq9yf
Python is weakly typed, it's just completely futile and would waste your time unless you choose to be inconsistent, in which case your code would be even worse because you're not following the same practices
Dear internet,
TIL that if you do something similar multiple times in python, there probably is way to make a function for that
7:29 Could add this to the class:
(a)property
def specifiers() -> set[str]:
return {'caps', 'time'}
Is the walrus variable scoped to the then&else branches? Or does it still exist once the if is done, ie. past line 6?
If it's scoped then that's a massive point in favour in my book :-)
Thanks for the clear and to the point video!
I thought scoping was the main feature of the walrus operator. Turns out I was wrong - there is no scoping
18:30 you dont need to import "Callable", the type "callable" already is in the defaults
Callable != callable
informative video as always.
In haskell you write function normally and get curried function by default.
Thank you!!
Thanks. Very interesting.
Wooow excellent sound.
Hey Indently. Just so you know, there is a lot of noise in the sound on the low-end, especially popping out of my sub when you type on your keyboard. Could be a good idea to dampen the frequencies you record that are outside the range of your enjoyable voice. Much respect. Peace.
The second parameter of slice _is not_ the index! It's _how many_ elements long the slice should be. You'll notice that in the list, "index 5" would actually be 6, since indices in Python start at 0 😉
Off-by-one, anybody?
If I said that I misspoke, thank you for pointing it out for anyone who got confused by that. I tried my best to specify that you can use a slice object the same way you use slice notation, so regardless of what I said, it should be fine if people follow that principle 😎
For anyone that hasn't programmed in a functionnal language at its core, this is not currying. It achieves the same goal, but it's almost as inneficient as passing the parameter by hand.
Thanks for video.
What font is used in this video?
I have yet to find a use case for reversing a string, beside academics
Valrus operator: saves one line, by ruining the readability of another
that's actually not true, in golang it's a very common operator, and for someone with experience in go, i'm glad that we can also do that in python. With experience this can help a developer or a team of developers to have a better knowledge of what variables are being used by the code and where, and if this is just used on that piece of code, this is probably the best way to use this variable, since the variable will be deleted after the use.
Zig also has something like this, and it is a language that prioritizes readability over writing code
if (something) |variable| {
}
It can actually improve readability in cases like simultaneously assigning a variable and evaluating its boolean value for a conditional. Especially if that variable is only used inside the *if* block
That being said, I think the example used in this video is not the best use case. I still prefer to use a separate line in that case
📝 Summary of Key Points:
📌 The first trick shared in the video is about creating slice objects in Python to avoid repetitive code when slicing iterables. By using slice objects, you can easily modify the slicing implementation in one place.
🧐 The second trick involves using set operators in Python to perform set operations like combining sets, subtracting elements, finding intersections, and getting unique elements efficiently.
🚀 The third trick demonstrates how to make a class compatible with F-strings by defining custom format specifiers using the __format__ method. This allows for specialized formatting of class attributes in F-strings.
💡 Additional Insights and Observations:
💬 One memorable concept introduced is the use of the walrus operator in Python to streamline code and assign values within conditional statements efficiently.
📊 The video showcases practical examples of currying functions in Python, which can simplify repetitive function calls with predefined setups.
📣 Concluding Remarks:
The video covers five uncommon Python tricks and features, including creating slice objects, utilizing set operators, customizing F-string specifiers, leveraging the walrus operator, and implementing currying functions. These tricks offer practical ways to enhance code efficiency and readability in Python programming.
Generated using TalkBud
I learn fastapi and i find out that i use currying, when set up post, delete methods. This 2 operations require identifier to find item. So i put find_by_id function inside those metods and then define next steps. Some sort of state managment
The walrus operator irks me a little. In a handful of simple ifs (and possibly in list comprehensions) its probably fine, but using it pretty much anywhere else I'd argue is a code smell.
Useful video
what IDE do you use? I cant recognize it.. (stuck to VSCode for years, but yours look really clean!)
It's pycharm....basically designed for python
@@resresres1thanks, i didnt noticed because it is not the default theme
@@agent_artifical JetBrains recently updated the UI.
I like Python's slice syntax, and it's good that I've seen this video to know that I can save a slice format because this is yet another feature I think my own language was missing. I finally upgraded my local copy of Python to 3.9 last year, and apparently the "walrus" operator and the match statement were added in 3.10, which is kind of annoying. Oh well, just need to checkout a later version, and I'm aiming for v3.11.0 and ask me in a couple of hours if it works, because yes I am that paranoid to run `make test`. One thing I keep wondering though, why doesn't Python implement operator+ for most things. For sets it makes sense to have operator| instead, but it wouldn't hurt to make operator+ be an alias or even do something weird like collapse a set into an array. I implemented + and += for all of the container classes in my standard library, both for single elements and other containers. It makes no sense to me why people keep pushing back on that.
I didn't understand how the multiply-setup() works. We provide only parameter "a", but where does the parameter "b" come from in multiply()?
The b parameter is coming from the enclosed def multiply(b). The multiply_setup(a) returns that multiply(b) function, so when the result is called, that becomes the b parameter.
`multiply_setup` returns a function which accepts one parameter, which is `b`. So `double = multiply_setup(2)` is setting `double` to a function, and calling `double(3)` will call the function with `b = 3`.
Thanks, I almost broke my brain figuring this out🎉 Not sure if it is really worth, maybe I just need a a better use case.
My problem was that I watched at the callable, but completely omitted the double and 'triple' examples. After that it went smooth❤
Basically multiply-setup() is being used to create some functions with similar, uh, functionality. So when you call multiply-setup(2) it's going to return a function that will multiply anything by 2. In this case, it's called double()
If I was asked to do this I'd use lambdas, because I use lambdas a lot in my python code, but that's just me.
@@chemicals8582i use lambdas a lot in other languages, but the python syntax is kinda clunky imo, "lambda x: x * x" is more clunky than "(x) => x * x" or "|x| x * x"
how to define a variable of type list[list]. Can you help me with that. I am new to python.
Interesting videos but you have some issues with terminology...
^ is called 'caret' not up-arrow.
A | B is 'set union' which you don't mention.
It's my teachings style, I try not to confuse beginners with too much terminology. What you said is accurate, but it's not appropriate for this video. I accept that I will get roasted by more experienced / pedantic devs for this.
Thank you for trying to help though!
@@IndentlyNo worries, good of you to reply, it's ok to use vernacular but please also teach the correct term afterwards, as you did with "symmetric difference" for example.
I'll work on improving that!
I'm curious about the font of the thumbnail. Can anyone tell me?
the set one is not really an uncommon python feature, that's just operator overloading for sets
The last one is properly called Decorator.
I usually don’t define the type. That is an advantage of Python if you just want to make simple code.
Probably include it when It serves the purpose of clarity. Using it everywhere will make the code harder to read. Just my thought.
A decorator is a function that _takes_ a function, not one that returns a function. This is more akin to partials or currying.
currying is the correct termonology here, currying is the act of usually taking a single argument and returning a function using that argument and taking the next argument, it can go on recursively forever
a decorator is a wrapper a function or object with the same signature usually in object oriented code
python decorators (@ syntax) is basically currying, they dont conform to the same signature
7:49 Enums? Would that work with that syntax?
For the format spec, why not just do
if format_spec == '':
elif format_spec == '':
(... and so on)
also I dont think it should be Any for format_spec, it should be format_spec: str.
I tried this and it results in a TypeError:
class something:
pass
def __format__(self, format_spec):
if format_spec == 's':
return 'Spec1'
elif format_spec == 99:
return 'Spec2'
x = something()
y = 99
print(f'{x:s}')
print(f'{x:{y}}')
bismillah, great video my brother, thank you
I think format would be fun try😂😂
14:05 OMG, what was that?! 😮
What‘s the shortcut? Please
I think alt+shift+click
I would have loved to see curry used in a way that couldn't be substituted w/ power()