10 Mistakes that Python Developers Should Avoid to Excel in Their Resume

Here are the 10 mistakes that Python developers should stay away from

One of the main reasons people would prefer to learn Python is its popularity and ease of learning. It is simpler to learn and is a type of free programming language. The time taken to learn this programming language would depend on which level you would want to achieve and depends on your learning ability. Start learning Python from the very basics, such as syntax, keywords, functions and classes, data types, basic coding, and exception handling. You are not required to have advanced programming knowledge, depending on the nature of your work, you can learn skills such as database programming, synchronization techniques, multithreading, etc. Here are the 10 mistakes you must avoid as a python developer to excel in your resume.

Misusing expressions as defaults for function arguments

Python allows you to specify that a function argument is optional by providing a default value for it. While this is a great feature of the language, it can lead to some confusion when the default value is mutable. A common mistake is to think that the optional argument will be set to the specified default expression each time the function is called without supplying a value for the optional argument.

Using class variables incorrectly

In Python, class variables are internally handled as dictionaries and follow what is often referred to as Method Resolution Order (MRO). So in the above code, since the attribute x is not found in class C, it will be looked up in its base classes (only A in the above example, although Python supports multiple inheritances). In other words, C doesn't have its own x property, independent of A. Thus, references to C.x are in fact references to A.x. This causes a Python problem unless it's handled properly. Learn more about class attributes in Python.

Specifying parameters incorrectly for an exception block

The proper way to catch multiple exceptions in an except statement is to specify the first parameter as a tuple containing all exceptions to be caught. Also, for maximum portability, use them as a keyword, since that syntax is supported by both Python 2 and Python 3.

Misunderstanding Python scope rules

Python scope resolution is based on what is known as the LEGB rule, which is shorthand for Local, Enclosing, Global, and Built-in. There are some subtleties to the way this works in Python, which brings us to the common more advanced Python programming problem below. Many are thereby surprised to get an UnboundLocalError in previously working code when it is modified by adding an assignment statement somewhere in the body of a function.

Modifying a list while iterating over it

The problem with the following code should be pretty obvious. Deleting an item from a list or array while iterating over it is a Python problem that is well known to any experienced software developer. But while the example above may be pretty obvious, even advanced developers can be unintentionally bitten by this in code that is much more complex. Fortunately, Python incorporates several elegant programming paradigms that, when used properly, can result in significantly simplified and streamlined code. A side benefit of this is that simpler code is less likely to be bitten by the accidental-deletion-of-a-list-item-while-iterating-over-it bug. One such paradigm is that of list comprehensions. Moreover, list comprehensions are particularly useful for avoiding this specific problem, as shown by this alternate implementation of the above code which works perfectly:

Confusing how Python binds variables in closures

Python's late binding behavior says that the values of variables used in closures are looked up at the time the inner function is called. So in the above code, whenever any of the returned functions are called, the value of i is looked up in the surrounding scope at the time it is called.

Creating circular module dependencies

The answer is that the mere presence of a circular import is not in and of itself a problem in Python. If a module has already been imported, Python is smart enough not to try to re-import it. However, depending on the point at which each module is attempting to access functions or variables defined in the other, you may indeed run into problems.

Name clashing with Python Standard Library modules

One of the beauties of Python is the wealth of library modules that it comes with "out of the box". But as a result, if you're not consciously avoiding it, it's not that difficult to run into a name clash between the name of one of your modules and a module with the same name in the standard library that ships with Python.

Failing to address differences between Python 2 and Python 3

The "problem" is that, in Python 3, the exception object is not accessible beyond the scope of the except block. (The reason for this is that, otherwise, it would keep a reference cycle with the stack frame in memory until the garbage collector runs and purges the references from memory. More technical detail about this is available here). One way to avoid this issue is to maintain a reference to the exception object outside the scope of the except block so that it remains accessible.

Misusing the __del__ method

When the interpreter shuts down, the module's global variables are all set to None. As a result, at the point that __del__ is invoked, the name foo has already been set to None. A solution to this somewhat more advanced Python programming problem would be to use atexit.register() instead. That way, when your program is finished executing (when exiting normally, that is), your registered handlers are kicked off before the interpreter is shut down.