25 nooby Python habits you need to ditch



These nooby Python habits give away your inexperience in Python. Improve your code and your prestige just a bit by ditching those habits and doing things the Pythonic way.

CONTEST CLOSED! The winners are: Lluc Cardoner, David Saint, Gaurav Verma 1412, and Alpe!

OFFICIAL CONTEST RULES:
1. All entries must comply with the YouTube community guidelines ( and YouTube Terms of Service ( Entries that violate YouTube guidelines are automatically disqualified.
2. YouTube is not a sponsor of the contest and viewers are required to release YouTube from any liability related to the contest.
3. Privacy notice: no personal data will be collected for this contest.
4. In order to enter, you must (a) be one of my subscribers, AND (b) make a top-level comment to the video including #pycharm somewhere in the comment.
5. The contest is free, there is no fee required to enter.
6. Winners will be chosen randomly 1 week after the date the video went live from all users who have entered and not been disqualified.
7. Each winner will be notified via a comment reply from me that details what prize was won (e.g. “Congratulations! You have won XYZ. Please email me.”). I will ask the winner to contact me by email, and I will reply through email with a random token which must be posted as another reply to the winning comment from the winning account in order to verify account ownership and prevent fraud.
8. Each winner will have 72 hours to respond AND prove account ownership or their prize is automatically forfeited and another winner will be chosen.
9. A winner can only win 1 prize per contest.
10. The prize pool for this contest is: 4 licenses for PyCharm Professional (“Free 1-Year Personal Subscription”), which is a product made by JetBrains. A prize consists of 1 license, which will be delivered in the form of a redeemable code that can be redeemed at before May 01, 2022.
11. You may not enter the contest if doing so would be a violation of any relevant federal, state, and local laws, rules, and regulations, including U.S. sanctions.

― mCoding with James Murphy (

Source code:

SUPPORT ME ⭐
—————————————————
Sign up on Patreon to get your donor role and early access to videos!

Feeling generous but don’t have a Patreon? Donate via PayPal! (No sign up needed.)

Want to donate crypto? Check out the rest of my supported donations on my website!

Top patrons and donors: Jameson, Laura M, Dragos C, Vahnekie, John Martin, Casey G, Pieter G, Krisztian M, Mutual Information, Sigmanificient

BE ACTIVE IN MY COMMUNITY 😄
—————————————————
Discord:
Github:
Reddit:
Facebook:

source

Avatar of mCoding

By mCoding

35 thoughts on “25 nooby Python habits you need to ditch”
  1. 1. 00:25: Manual string formatting

    2. 00:36: Manually closing a file

    3. 00:53: Using "try:" and "finally:" instead of a context manager

    4. 01:07: Using a bare "except:" clause

    5. 01:32: Thinking that "^" in python means exponentiation (it's a bitwise XOR, exponentiation is "a ** b")

    6. 01:42: Use of default mutable arguments

    7. 02:07: Never using comprehensions, or only using list comprehensions

    8. 02:24: ALWAYS using comprehensions

    9. 02:50: Checking for a type using "=="

    10. 03:23: Using "==" to check for None, True, or False

    11. 03:37: Using an "if bool(x):" or "if len(x)" check

    12. 03:51: Using the "range(len(a))" idiom

    13. 04:30: Looping over the keys of a dictionary

    14. 04:48: Not knowing about the dictionary items methods

    15. 05:01: Not using tuple unpacking

    16. 05:11: Creating your own index counter variable

    17. 05:21: Using "time.time()"" to time things

    18. 05:43: Littering your code with print statements instead of using the logging module

    19. 05:59: Using "shell = True" on any function in the subprocess library

    20. 06:13: Doing maths or any kind of data analysis in Python

    21. 06:23: Using "import *" outside of an interactive session

    22. 06:33: Depending on a specific directory structure for your project

    23. 07:07: The common misconception that Python is not compiled

    24. 07:34: Not following PEP 8

    25. 07:56: Doing anything to do with Python 2

  2. Great vid, i didn’t know about a quarter of those. Some because I never even heard of like shell =true. Others were really silly, like I’ve been using list comprehension but didn’t think that would work for dictionaries too 😅

  3. I'm by far not a noob, but 1:42 would have eventually bitten me in the balls. That seems like really bad behavior and poor internal design. All function arguments should reflect the specified default on each call, no matter what – if it's an empty list, you should get a new empty list every single effing time.

  4. Ok, but is it still noob if i hate f strings? Like, i like the plus cuz i was taught this method in school while learning java and it stuck with me, f strings i taught myself but i hate using it.

  5. Buggy regex pattern strings due to having to worry about two layers of escaping and almost never getting it right. Most tutorials don’t bother explaining to use raw string literals, or triple quotes when you need to look for literal quotes.

  6. Manual string formatting. I don't do, only because I'm learning and didn't understand the f string bit in the lesson. So in the problem projects as I've been comparing my code with others if I get super stuck, I see they've used the f string but only use it once I 100% get it. If I don't get it, I'll just go with the way I do it, even if its not the best.

  7. Thanks, I'm real new so like half of these I either don't know what it means, or didn't even know you could do that in the first place (Such as checking if something IS a tuple)

  8. I think some people utilize those nooby habits just to make the code longer and in result -> seem more complex. Someone from management might come up and see that someone has a solution written in one line and will say in the future "Oh come on, you can do this for tomorrow morning. It's easy, it's only one line of code". Sorry if I may be wrong and it might not apply in programming, software engineering, etc. but perhaps more likely in data analysis.

    I remember when I was working as an analyst in FMCG and while I didn't use Python, I used SQL and everytime there was something that I needed to dig into deeper to undersetand it, I was being rushed and pushed and all I heard was "Come on it's so easy, I can do it in Excel in 1 hour". Fuck this then

  9. 5:43 this isn't a nooby thing to do. The logging module requires some thought and setting up (especially if your code is spread across multiple files?), while the print function is always just there. Even the documentation states that in some cases print is the best tool for the job.
    Also the logging module can litter your output with unsolicited logs at times. I'm not sure where they come from (they're a bit cryptic), but I've been getting that while using imgui with pygame.

  10. I don't know if it's pep8, but I will never conform to this convention that I think I read around there once, but I've seen many people use:
    if very_long_condition and
    another_condition:
    # stuff

    I find this way more readable, and more logical:

    if very_long_condition

    and another_condition:
    # stuff

    Same thing in other cases, where you might do something like this:
    foo = some_value
    + some_other_value
    + some_other_thing

    (ignore that things don't properly align in this font)

  11. Regarding 19. (subprocess):
    When using the list version, it wouldn't accept ">" in any form. It would onmly work when using shell=true!
    Any way to work arounf tha?

  12. wow thanks. i just startet learning python for school and got the hang for it. (even got schown some of these habits by teachers) and i think some of what you said really will help me for my current projekt. thanks

  13. Python is such a broken language. The scope of variables is so fucked and the fact that there is no explicit copy built in leads to extremely hidden bugs. It is completely overused and I hate it.

  14. Python people always say that comprehensions are "clearer", but I've never found that to be true, and sometimes people will string multiple comprehensions in the same line and it becomes hard to parse at best and unreadable at worst.

Leave a Reply

Your email address will not be published.

Captcha loading...