Skip to content

Home

Backend Language


Note

Given the increasing prominence of artificial intelligence (AI) and its integration into backend systems, two languages with significant potential for the future of backend development in the AI domain are Python and Golang (Go).

Python:

Python has already established itself as a dominant language in AI and machine learning (ML) development due to its simplicity, versatility, and extensive libraries like TensorFlow, PyTorch, and scikit-learn. Its ease of use makes it ideal for rapid prototyping and experimentation, while its performance can be enhanced through libraries like NumPy and Cython.

Golang (Go):

Go is gaining traction in the AI and backend development communities due to its speed, concurrency support, and strong built-in standard library. Go's simplicity and efficiency make it well-suited for building scalable backend systems that handle AI workloads efficiently. Additionally, frameworks like TensorFlow and gorgonia provide Go bindings for AI development.


By learning Python and Golang, you'll be well-equipped to tackle backend development tasks in the evolving landscape of AI-driven applications and systems. These languages offer complementary strengths and are likely to remain relevant in the future of AI-powered backend development.


Koncept HolyGrail

dir() lists attributes and methods of an object, while help() provides detailed documentation about specific objects, including classes, functions, and modules.

Django

$ django-admin shell

$ import django
$ dir(django)
$ help(django)

djangorestframework rest_framework

$ py manage.py shell

$ import rest_framework
$ dir(rest_framework)
$ help(rest_framework)

$ import rest_framework.generics
$ dir(rest_framework.generics)
$ help(rest_framework.generics)

manage.py vs django-admin

manage.py shell vs django shell

python manage.py shell loads the Django project's environment, while django-admin shell provides a general Python shell without Django-specific setup.

# django-admin shell provides a general Python shell without Django-specific setup.
django-admin shell

# python manage.py shell loads the Django project's environment.
py manage.py shell

Creating our first app

A single Django project can contain one or more apps that work together to power a web application. Django uses the concept of projects and apps to keep code clean and readable.

Apps in Django are like pieces of a website. You can create an entire website with one single app, but it is useful to break it up into different apps, each representing a clear function.(1)

  1. Creating our first app

    python3 -m django startproject <project_name>
    python3 -m django startproject moviereviews
    
    cd moviereviews
    
    python3 manage.py startapp <name of app>
    python3 manage.py startapp movie
    

    Although our new app exists in our Django project, Django doesn't recognize it till we explicitly add it. To do so, we need to specify it in settings.py. So, go to /moviereviews/settings.py, under INSTALLED_APPS, and you will see six built-in apps already there.

    Add the app name, as highlighted in the following (this should be done whenever a new app is created):

    INSTALLED_APPS = [
        'django.contrib.admin',
        'django.contrib.auth',
        'django.contrib.contenttypes',
        'django.contrib.sessions',
        'django.contrib.messages',
        'django.contrib.staticfiles',
        # Added app name here
        'movie',
    ]
    
    • Django 4 for the Impatient, 1st Edition by Greg Lim, Daniel Correa

Managing Django URLs

Note that urls.py is located in the project's main folder, moviereviews.

All requests to the site will go through urls.py. Then, specific paths defined in urls.py are linked to specific view functions, which are located in the individual app folders.

For example, the /about path (defined in urls.py file) is linked to the about function (defined in the /movie/views.py file). This allows us to separate views according to the app they belong to.

  • Django 4 for the Impatient, 1st Edition, pg: 23

Key Differences Between dir() and help()

  • The dir() function lists the attributes and methods that are currently accessible in the namespace of the object or module.

  • It only shows what has been explicitly imported or exposed through the module's __init__.py file.

  • For Django REST Framework (rest_framework), many submodules and attributes are not automatically exposed in the top-level namespace, so they won't appear in dir(rest_framework) unless explicitly imported.

  • The help() function provides detailed documentation about an object, module, or class by reading its docstrings and metadata.

  • It retrieves information about all components defined within the module, even those that are not directly exposed in the top-level namespace.

  • This is why help(rest_framework) can show all built-ins, classes, and functions defined in Django REST Framework, even if they are not listed by dir().

Why This Happens in Django REST Framework
  • Django REST Framework is modular, and its submodules (e.g., serializers, views, etc.) are not automatically imported into the top-level namespace (rest_framework) to keep it lightweight and efficient.

  • The help() function accesses deeper documentation about the module's structure, including components that are defined but not directly imported or exposed.

Example: Understanding the Difference
python
import rest_framework

# Using dir()
print(dir(rest_framework))
# Output: Limited attributes like '__name__', '__package__', '__doc__', etc.

# Using help()
help(rest_framework)
# Output: Detailed documentation about all submodules, classes, functions, etc., even if they are not listed by dir().

1. How to Access Hidden Components

If you want to see all submodules or attributes using dir(), you need to explicitly import them:

import rest_framework.serializers
print(dir(rest_framework.serializers))

2. Alternatively, use tools like pkgutil to list all submodules within a package:

import pkgutil
for module in pkgutil.iter_modules(rest_framework.__path__):
    print(module.name)

Conclusion

  • dir() provides a surface-level view of what is currently accessible in a module's namespace.

  • help() dives deeper into documentation and metadata, showing all components defined within the module, whether or not they are exposed at the top level.


Purpose of dir() and help()

Feature dir() help()
Purpose Lists attributes and methods Provides detailed documentation
Output A list of names (strings) Text-based help with descriptions
Detail Level Surface-level (what’s available) In-depth (what it does and how to use)