Trying to migrate a DB with a nonexisting DB crashes with this error 👇

Trying to migrate with invalid credentials 👇

How can we solve this?

• The app should catch this error to ensure a good user experience. This scenario should be presented to the user in a less technical way unlike as seen in the crash error log.
• The app should prevent abrupt app exist.

The time currently set for access tokens to expire is not practical. Should be increased to maybe 6 hours and a refresh token to be used to generate new access tokens.

Why is this an issue?

Used when there is no reference to the class, suggesting that the method could be used as a static function instead If the class method does not reference any of the class attributes it may be more clear to define the method as a static function instead.

Attempt using either of the decorators @classmethod or @staticmethod

Ex:

class Foo(object):
    ...
    def bar(self, baz):
        ...
        return llama

Try instead to use:

class Foo(object):
    ...
    @classmethod
    def bar(cls, baz):
        ...
        return llama

SOURCE

Related code pattern

Prohibits classes without referencing
Prohibits the usage of classes when there are no references for it, suggesting that the method could be used as a static function instead

Avoid pass in the except block
Example:

try:
  do_some_stuff()
except Exception:
  pass

Rationale:
This pattern is considered bad practice in general, but also represents a potential security issue. A larger than normal volume of errors from a service can indicate an attempt is being made to disrupt or interfere with it. Thus errors should, at the very least, be logged.

There are rare situations where it is desirable to suppress errors, but this is typically done with specific exception types, rather than the base Exception class (or no type).

IMPORTS

Imports should usually be on separate lines, e.g.:

Yes:

import os
import sys

No:

import sys, os

It's okay to say this though:

from subprocess import Popen, PIPE

Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants.

Imports should be grouped in the following order:

• Standard library imports.
• Related third party imports.
• Local application/library specific imports.
  You should put a blank line between each group of imports.

Absolute imports are recommended, as they are usually more readable and tend to be better behaved (or at least give better error messages) if the import system is incorrectly configured (such as when a directory inside a package ends up on sys.path):

import mypkg.sibling
from mypkg import sibling
from mypkg.sibling import example

However, explicit relative imports are an acceptable alternative to absolute imports, especially when dealing with complex package layouts where using absolute imports would be unnecessarily verbose:

from . import sibling
from .sibling import example

Standard library code should avoid complex package layouts and always use absolute imports.

Implicit relative imports should never be used and have been removed in Python 3.

When importing a class from a class-containing module, it's usually okay to spell this:

from myclass import MyClass
from foo.bar.yourclass import YourClass

If this spelling causes local name clashes, then spell them

import myclass
import foo.bar.yourclass

and use "myclass.MyClass" and "foo.bar.yourclass.YourClass".

Wildcard imports (from import *) should be avoided, as they make it unclear which names are present in the namespace, confusing both readers and many automated tools. There is one defensible use case for a wildcard import, which is to republish an internal interface as part of a public API (for example, overwriting a pure Python implementation of an interface with the definitions from an optional accelerator module and exactly which definitions will be overwritten isn't known in advance).

When republishing names this way, the guidelines below regarding public and internal interfaces still apply.

• snake_case
• UPPERCASE for constants

The server timezone is GMT. As users are from different time zones, this means that checks to ensure past dates are not accepted will not always be accurate.
These checks are biased to GMT and therefore will allow past dates in context to other time zones.

Maintain DRY standards

Duplicated Code

Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

The update_user DB query has a pass. No implementation of DB connection and edits made. Hence a false positive of changes being applied!

How can this kind of false positives be mitigated?

• Try to ascertain directly that there was a change in the DB data.

#33 Should be revised!

Add docstrings to all modules

Should not exceed 5

Cognitive Complexity

Cognitive Complexity is a measure of how difficult a unit of code is to intuitively understand. Unlike Cyclomatic Complexity, which determines how difficult your code will be to test, Cognitive Complexity tells you how difficult your code will be to read and comprehend.

A method's cognitive complexity is based on a few simple rules:

• Code is not considered more complex when it uses shorthand that the language provides for collapsing multiple statements into one
• Code is considered more complex for each "break in the linear flow of the code"
• Code is considered more complex when "flow breaking structures are nested"