You forgot about 'case _:' in a match expression. Example: n = int(input()) match n: case 1: print("n is 1") case 2: print("n is 2 times more than 1") case 3: print("n is bigger than 1") case _: print("n is weird")
In try except if you need to use _ you don't need it in the first place, just try except without variable output. Otherwise, great video man, this one was useful and informative 👍🏻
To point 4, it is also default case in the new match structure (3.10 and up). match type(myvariable): case type(int()): do_int_staff(myvariable) case type(float()): do_float_stuff(myvariable) case type(str()): do_string_stuff(myvariable) case _: print(f"Unsupported type {_}") Update: someone explains to me why this code throws an error in line case type(int()) but print(type(int())) works as expected.
@@sangchoo1201 case int: would compare it to literally the int type, instead of checking if its an instance of int or not. its supposed to be case int():
@schloppppdev3002 1. match type(myvariable): wants to check the variable's type 2. match int(): is actually checking the variable matchs 0 (because default constructor of int creates 0)
6:48 a more common reserved name that would be wanted to use it for something else is "id" , it let's you reassign it though, but it's not recommended .
Can you cover setting _ (underscore) instead of method parameters in the signature some method/function? Uses cases: the IDE or linter complains the parameter is not used, but you don't need it and the specification states you must put it there, and also it doesn't support optional params and other neat features and it's in args section so no kwargs will work.
What's the benefit to using it in exception handling, when you don't need to catch what the exception is at all if you're not gonna use it? Am I missing anything?
For 7 (Private) and 8 (Protected) - 4:16-6:40, I believe you are mistaken. AFAIK, both protected and private methods use a single underscore by convention, and name mangling with double underscore is not correct. Though both are common, I believe name mangling is incorrect. I don't know how to verify this, though.
I don't know where you're getting your information from. What I shared is a very common convention in Python, if you want to learn more about name mangling, check out mCoding, he made a proper video on it. Otherwise if you have resources that prove otherwise, I wouldn't mind looking at them.
@@Indently The name mangling is to avoid subclasses accidentally overriding parent class methods when inheriting. This behavior is documented in the wiki (and pep-0008): "Python's runtime does not restrict access to such attributes, the mangling only prevents name collisions if a derived class defines an attribute with the same name."
@@Jason-b9t Yes I agree, the function does not become private neither it becomes difficult to find its name. I tried this by creating a sample class with a double underscore leading function. Then I passed in the object created by that function in dir() global function which had the function inside my class named as: '_ClassName__functionName'. According to PEP 8 : __double_leading_underscore: when naming a class attribute, invokes name mangling (inside class FooBar, __boo becomes _FooBar__boo)
@@Indently you forgot to mention one another common use you are even using in the video, defining __init__ method for classes 7:53 anyway great video as usual!
I’m overanalysing it. It’s just treating _ as a variable and doing the usual * unpacking. So *_ isn’t a Python symbol, it’s just the * unpacking operator applied to variable _. The whole _ is just a convention that it’s ignored, syntactically (outside of console mode) it’s just another variable - right?
@@gavintillman1884 Yes exactly, if you want you can even use emojis instead of _. "*" operator changes it's behaviour if it's in between int or float data types; acts as a multiplier. If left side is a string and right side is an int, acts as a repeater. I think these two the most common ones.
"as _" ? Why the h*** would you ever do that? Just delete those 4 extra characters from you code
it's used by django's translate engine
My Mom: What should we name him?
My Dad: Name him "_", we do not care about him
In C# it is literally called the discard character
2:32 But if you don't need to use the exception, why even write "as _" instead of leaving it to be "except ZeroDivisionError:"?
From what I read and saw, some people use it to explicitly show that they are ignoring it, but it is probably a very rare use case.
@@Indently well, if one wants to suppress it, with contextlib.suppress() is a much cleaner option
You forgot about 'case _:' in a match expression.
Example:
n = int(input())
match n:
case 1:
print("n is 1")
case 2:
print("n is 2 times more than 1")
case 3:
print("n is bigger than 1")
case _:
print("n is weird")
Here, _ is a wildcard that never fails to match. If none of the other cases match, it will match with case _.
In try except if you need to use _ you don't need it in the first place, just try except without variable output.
Otherwise, great video man, this one was useful and informative 👍🏻
To point 4, it is also default case in the new match structure (3.10 and up).
match type(myvariable):
case type(int()):
do_int_staff(myvariable)
case type(float()):
do_float_stuff(myvariable)
case type(str()):
do_string_stuff(myvariable)
case _:
print(f"Unsupported type {_}")
Update: someone explains to me why this code throws an error in line case type(int()) but print(type(int())) works as expected.
match case is pattern matching, you're using type(int()) you should just use int()
Is that not just a naming convention? Doing `case unused_variable:` would do the same thing
just
case int:
doesn't work..?
@@sangchoo1201 case int: would compare it to literally the int type, instead of checking if its an instance of int or not. its supposed to be case int():
@schloppppdev3002
1.
match type(myvariable):
wants to check the variable's type
2.
match int():
is actually checking the variable matchs 0
(because default constructor of int creates 0)
I think some of it was refreshing, duunder methods, however there were pretty neat tricks there!! We'll certainly be back again!!
6:48 a more common reserved name that would be wanted to use it for something else is "id" , it let's you reassign it though, but it's not recommended .
Great presentation style and hugely memorable content! Thanks Buddy.
Can you cover setting _ (underscore) instead of method parameters in the signature some method/function?
Uses cases: the IDE or linter complains the parameter is not used, but you don't need it and the specification states you must put it there, and also it doesn't support optional params and other neat features and it's in args section so no kwargs will work.
What's the benefit to using it in exception handling, when you don't need to catch what the exception is at all if you're not gonna use it? Am I missing anything?
Thats very good. Looking forward to dunder methods of class video.
For 7 (Private) and 8 (Protected) - 4:16-6:40, I believe you are mistaken. AFAIK, both protected and private methods use a single underscore by convention, and name mangling with double underscore is not correct. Though both are common, I believe name mangling is incorrect. I don't know how to verify this, though.
I don't know where you're getting your information from. What I shared is a very common convention in Python, if you want to learn more about name mangling, check out mCoding, he made a proper video on it.
Otherwise if you have resources that prove otherwise, I wouldn't mind looking at them.
@@Indently The name mangling is to avoid subclasses accidentally overriding parent class methods when inheriting.
This behavior is documented in the wiki (and pep-0008): "Python's runtime does not restrict access to such attributes, the mangling only prevents name collisions if a derived class defines an attribute with the same name."
@@Jason-b9t Yes I agree, the function does not become private neither it becomes difficult to find its name.
I tried this by creating a sample class with a double underscore leading function. Then I passed in the object created by that function in dir() global function which had the function inside my class named as: '_ClassName__functionName'.
According to PEP 8 :
__double_leading_underscore: when naming a class attribute, invokes name mangling (inside class FooBar, __boo becomes _FooBar__boo)
I enjoy your videos with your personal touch.
what IDE do you use??
it's pycharm
How can we connect Cypress to python in pycharm? Can you please tell me
Why does this video not mention the important role _ plays is match patterns?
Because I absolutely forgot about it until you mentioned it! damn, it will be for the next one
@@Indently you forgot to mention one another common use you are even using in the video, defining __init__ method for classes 7:53 anyway great video as usual!
Unimportant exceptions was a new one for me!
I’ve come across both * and _ in an unpacking context, but never *_ together. Is that quite new?
It's been around for as long as I can remember :)
"*" usually means all so you are unpackaging all the in between values to "_"
I’m overanalysing it. It’s just treating _ as a variable and doing the usual * unpacking. So *_ isn’t a Python symbol, it’s just the * unpacking operator applied to variable _. The whole _ is just a convention that it’s ignored, syntactically (outside of console mode) it’s just another variable - right?
@@gavintillman1884 Yes exactly, if you want you can even use emojis instead of _. "*" operator changes it's behaviour if it's in between int or float data types; acts as a multiplier. If left side is a string and right side is an int, acts as a repeater. I think these two the most common ones.
Some are pretty useful.
Everyone asks what is an underscore but no one asks how is the underscore...
That is very True
Wonderfull!
U could do user._User__get_id() at 6:35 if any1 was curious
_ is just a variable name.
with a context of "I don't use it"
Not exactly. open python console, type '10', enter. Then type '_' , enter. you'll see 10. More than "just a variable name"
@@eitantal726 but it's still just a variable name, although the referenced variable is a special variable
@@sangchoo1201 no, "Eitan" is just a variable name. when I type 10 and Eitan, I don't see 10. _ is different. I see it as "ANS" of the calculator
@@eitantal726 but _ IS a variable name, isn't it?
what is a variable name:
sangchoo1201
_
input
what is NOT a variable name:
if
@#$
1a
Thanks
Why use __str__() instead of __repr__()?
__str__ is to convert the instance to a string
__repr__ is to represent the state of an instance (more close to debugging stuff)
Basically, underscore is just variable name or simple letter. Nothing special. In can be replaced with any other letter.
Update you IDE
Update you grammar
@@kaninchengaming-inactive-6529 but you used the same bad grammar as he did