Video není dostupné.
Omlouváme se.
10 Ways You Can Use "_" In Python (Do you know ALL of them?)
Vložit
- čas přidán 25. 07. 2024
- Here are 10 ways you can use the underscore (_) in Python when programming. Did you know all of them?
▶ Become job-ready with Python:
www.indently.io
▶ Follow me on Instagram:
/ indentlyreels
00:00 Intro
00:05 1) Last used value
00:49 2) Number formatting
01:27 3) Unimportant values
02:17 4) Unimportant exceptions
02:56 5) Unpacking
03:37 6) Super unpacking
04:16 7) Protected
05:46 8) Private
06:41 9) Reserved names
07:17 10) Dunder methods
09:26 11) Naming variables
09:34 Conclusion
"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
Great presentation style and hugely memorable content! Thanks Buddy.
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 👍🏻
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 I am glad I never saw that. I'd be confused. If I explicitly want to ignore an exception, I'd just leave the assignment out. And if I don't even want to handle it, I'd use contextlib.suppress().
@@Indently well, if one wants to suppress it, with contextlib.suppress() is a much cleaner option
Thats very good. Looking forward to dunder methods of class video.
I think some of it was refreshing, duunder methods, however there were pretty neat tricks there!! We'll certainly be back again!!
I enjoy your videos with your personal touch.
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?
Unimportant exceptions was a new one for me!
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 _.
What text editor/IDE you are using
Wonderfull!
Some are pretty useful.
How can we connect Cypress to python in pycharm? Can you please tell me
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.
U could do user._User__get_id() at 6:35 if any1 was curious
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)
Thanks
what IDE do you use??
it's pycharm
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."
@@user-vt9bp2ei1w 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’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.
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!
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)
Everyone asks what is an underscore but no one asks how is the underscore...
That is very True
_ 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
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