DEV Community: Bruno Rocha

Hello Dev.to

Bruno Rocha — Tue, 09 Apr 2024 10:56:45 +0000

Olá, estamos chegando!

O CodeShow é um canal colaborativo com pessoas que criam conteúdo de programação e falamos sobre Python, Java, Rust, Go, SQL, Javascript e muito mais!

Python Protocol Oriented Programming

Bruno Rocha — Fri, 05 Nov 2021 21:20:00 +0000

Python Objects 🐍

In Python everything is an object.

An object is formed by:

A memory location identified internally by an id.
A type (class) that determines the protocols of the object.
A value (or a set of values) that the object holds.

Example:

# Given an object identified by the variable name `a`
>>> a = 1

# We can access its memory location `id`
>>> id(a)
1407854654624

# We can access its type
>>> type(a)
'<class 'int'>'

# We can access its value
>>> a
1

# We can use the behavior defined on its protocol
>>> a + 1
2
>>> a.hex()
'0x1'

The above will be similar for every object in Python.

Types 🔠

Every object is based on a type, a type is a class definition.

print <- is function type
"Hello" <- is str type
0 <- is int type
[0:5] <- is a slice type
str.upper <- is a method_descriptor type

 Function String Integer       Slice
    __⬆️__  __⬆️_ _⬆️_         __⬆️__
    print("Hello"[0] + "World!"[0:5].upper())
                  ___⬆️___            __⬆️___
                   Symbol            Method Descriptor

Protocols 📝

Python is a POP Language (Protocol Oriented Programming)

The type of the object determines its implementation, which exposes the behavior, the behavior are the things that the object can do or things that can be done with the object.

There are languages that calls it Traits of an object.

Each set of those abilities is what we call a Protocol, protocols are useful for setting contracts 🤝 between objects.

Identifying protocols on the Hello World program:

   Callable  Subscriptable   Sliceable
    __⬆️__  ______⬆️    __________⬆️
    print("Hello"[0] + "World!"[0:5].upper())
             ________⬆️________      __⬆️__
                  Summable         Callable

Callable 🗣️ Can be invoked using ()
A type is also callable when its protocol includes the __call__ method.
Subscriptable ✍🏻 its elements can be accessed through a subscription.
The subscription can be numeric ordinal [0] or named key ['name']. A type is Subscriptable when its protocol includes the __getitem__ method.
Sliceable 🔪 its collection of elements can be sliced in parts.
A type is Sliceable when it is Subscriptable and its __getitem__ method can accept a slice in place of the index or name. A slice is the composition of [start:stop:step] elements.
Summable ➕ Can be combined with other objects via + operation.
The product of this combination is always new object. On numeric types this is the ability to sum two or more numbers in a set. On sequences it is the concatenation of its fragments in to one. A type is Summable when its protocol includes the __add__ or __radd__ method.
Printable 🖨️ Can be printed using print
All the Python objects are printable, print will look either for a __repr__ or a __str__ method for printing the object.

ℹ️ There are many more and in fact, you can define custom protocols, Protocols are very generic and there is no official list of protocols although there are some pre-defined protocols in the typing module.

from typing import Iterator, Iterable, Optional, Sequence, Awaitable, Generic

Complete list of protocols and sub typing is available on https://mypy.readthedocs.io/en/stable/protocols.html

🦆 Protocols empowers an approach called Duck Typing which is the fact that in Python if an object looks like, behaves like, and has the behavior of a Duck, it is said to be a Duck, regardless if this is the case of a Dog that learned to say quack immitating a Duck 🐶.

Typing and Protocol Checking

Some protocols can be checked using built-in functions

callable(print) is True
callable("Hello") is False

Some protocols must be checked against its type class

isinstance("Hello", str) is True
isinstance(0, slice) is False

There are cases where the only way to verify protocols
is checking for its attributes.

hasattr("Hello", "__add__") is True  # Summable, we can use `+` operator.

Others where we need to use the EAFP pattern.

try: 
    "Hello" + 1 
except TypeError: # Strong type checking
    # we cannot `__add__` an `str` to an `int`

Typing Protocols

Python3 offers a way to define custom protocols

from typing import Protocol, runtime_checkable

@runtime_checkable
class CallableSummableSubscriptable(Protocol):
    def __call__(self) -> T: 
        ...
    def __add__(self, other: T) -> T: 
        ...
    def __getitem__(self, item: T) -> T: 
        ...

ℹ️ Protocol methods are just signatures with empty bodies, stated by the .... T is usually a type alias indicating a generic type.

Protocols are useful to define contracts, bounds on function signatures for example defining a function that accepts an argument only if the type has the specified protocol.

def awesome_function(thing: CallableSummableSubscriptable):
    # accepts only objects that implements that ⬆️ protocol.
    # Protocols can be checked at runtime @runtime_checkable
    # Or checked using static analysers e.g: mypy

Is there the Traditional OOP in Python?

OOP Python is actually POP (Protocol Oriented Programming)

More about Protocols and Behavior.
Less about tradicional OOP concepts.

All the traditional concepts and patterns are also available, but some are intrinsic to objects and protocols that in the end of the day the programmers doesn't have to take care of it at all in the same way.

Inheritance

The ability to inherit from another base type and take all its behavior and the ability to override with custom implementation.

class MyString(str)
    def __str__(self):
        return super().__str__().upper()

>>> x = MyString("Bruno")
>>> print(x)
"BRUNO"

Encapsulation

The ability to hide object attributes and methods and expose only a selected set of them or to expose them in a more controlled way.

# Descriptor is a protocol for getter/setter like approach.
class Field:
    def __get__(...):
    def __set__(...):

class Thing:
    # Double underline means that the field is private
    # but actually it is only a naming mangling convention.
    __protected_attr = Field()

    # Properties can also be used to define getter/setter
    @property
    def foo(self): 
        return self.__protected_attr
    @foo.setter
    def set_foo(self, value): 
        self.__protected_attr = value

Polymorfism

The ability for objects to behave differently regardless of its base type and for procedures to take different types of objects as arguments.

len("Bruno")
len([1, 2, 3])

dict.get("key")
dict.get("key", default="other")

print("Hello")
print(123)
print(*["Hello", "World"])

def function(*args, **kwargs):
    ...

ℹ️ In traditional OOP literature polymorphism is often used to define only the ability to have methods reusing the same name but different implementation, but in fact it goes deeper than this.

Conclusion

🧑‍🍳 A Chef when selecting ingredients for a recipe, will look for the protocols defined on each ingredient, the Chef can go to the supermarket and see a set of different types of onions 🧅, even if the recipe only says onion the Chef knows based on the desired behavior that wants a specific type of onion, white onions are swetter, better for cooked recipes, the purple onions are more acid so better for salads and raw recipes. (but that also depends a bit on taste)

🧑‍💻 The Software Engineer when choosing the data structures to use in an algorithm 🤖 must look to the protocols defined and how the objects behaves even if the requirements says it is a collection of texts for example, the engineer must analyse the program to choose wisely between a tuple, a list or even a set.

The protocols are often more important than the types.

NOTE: Credits to @mathsppblog to have inspired the first paragraph of this post https://twitter.com/mathsppblog/status/1445148609977126914

[EN] I am Learning Rust - Exercism Space Age

Bruno Rocha — Mon, 30 Mar 2020 03:03:10 +0000

Resolving Space Age Exercism in Rust language

Used Traits and Macros.

Never do this in Python

Bruno Rocha — Thu, 06 Feb 2020 02:01:07 +0000

This video is published in 2 languages.

In English:

In this video I share some things you should avoid doing in when #programming in #python, so called Python #antipatterns and I also show you examples of how to achieve the same result in a better way.

In Portuguese:

Neste video eu falo sobre algumas coisas que não devemos fazer ao programar em #python, algumas práticas que são caracterizadas como #antipatterns e que podem trazer problemas para o seu #software.

Criando seu blog com Zola e hospedando de graça na Netlify

Bruno Rocha — Mon, 18 Nov 2019 19:56:07 +0000

Criando seu blog com Zola e hospedando de graça na Netlify

A forma mais prática para publicar blogs, especialmente se o blog for de uma pessoa desenvolvedora é a utilização de sites estáticos, são inúmeras as vantagens dessa abordagem.

Os motivos que nos levam a escolher sites estáticos ao invés de um CMS completo incluem a simplicidade da linguagem Markdown, a possibilidade de armazenar o conteúdo gratuitamente em um repositório do Github ou Gitlab, a rapidez na renderização do conteúdo, a facilidade na migração caso precise mudar de servidor, a hospedagem gratuita em serviços como Netlify ou Github Pages e é claro não ter que manter bancos de dados e servidores web.

Eu mesmo já tentei criar meu próprio CMS algumas vezes (1, 2) e no final das contas percebi que eu não preciso de um CMS complexo e você provavelmente também não.

Componentes

Estes são os componentes que usaremos nesta solução.

Markdown - Linguagem de marcação para o conteúdo.
Git (github/gitlab) - Repositório onde o conteúdo será armazenado.
Zola - Ferramenta que irá gerar o site estatico a partir dos arquivos markdown.
Github UI ou seu editor favorito - Local onde escreveremos novos posts no blog.
Netlify - Serviço de hospedagem que fará os deploys automaticamente do blog.

Zola

O Zola é um programa escrito em Rust para a geração de sites estáticos, com ele é possivel criar sites, single page apps e também blogs.

Eu estava a procura de um gerador de sites estáticos para construir este blog e como estou
bastante interessado em praticar com Rust eu fui ao AwesomeRust e fiz uma busca por static-site e nesta lista estava o Zola.

Dei uma rápida olhada em seu código fonte para saber se eu teria condições de contribuir para o projeto caso viesse a adotar.

Algumas coisas me fizeram escolher o Zola

Escrito em Rust (Rápido e Seguro)
# Markdown é **amor**
Binário único $ zola, apenas 20MB com tudo incluido para gerar o blog.
Templates Tera que tem a {{ sintaxe }} bem parecida com o Jinja do Python.
Syntax Highlight.
Shortcodes (diretivas Markdown customizáveis).
Processamento de imagens.
Muitos Temas.
Deploy simples na Netlify e Github Pages.
Todas as features de um gerador de sites estáticos.

Instalação

Na verdade não há instalação, o Zola é distribuído já compilado e é um único binário que você pode baixar na página de releases.

A versão mais atual no momento desta postagem é a 0.9.0 e para iniciar o seu Blog você pode seguir estes passos.

Considerando um sistema Linux, porém se você estiver no Windows ou Mac veja os links na página de releases e adapte para o seu O.S.

# Baixando o Zola (linux)
wget https://github.com/getzola/zola/releases/download/v0.9.0/zola-v0.9.0-x86_64-unknown-linux-gnu.tar.gz

# Descompactando
tar -xvzf zola-v0.9.0-x86_64-unknown-linux-gnu.tar.gz
rm zola-v0.9.0-x86_64-unknown-linux-gnu.tar.gz

# Executando
./zola --help

# Saída
SUBCOMMANDS:
    build    Deletes the output directory if there is one and builds the site
    check    Try building the project without rendering it. Checks links
    init     Create a new Zola project
    serve    Serve the site. Rebuild and reload on change automatically

Se tudo funcionou bem até aqui é hora de iniciar um projeto e começar a escrever o conteúdo para o blog.

Criando um novo site Zola

Este processo é bem simples rodando o comando $ zola.. Clique aqui para continuar lendo...

Este conteúdo também está disponível em áudio:

from dynaconf import settings

Bruno Rocha — Fri, 12 Apr 2019 16:40:11 +0000

Often when starting a new Python project we need to spend some time thinking about how to manage the settings, decide on which module the configuration manager will be written, decide which name to give to this module, create a class or function to store the configuration keys, create the conditions for multiple environments and still need to worry about where these keys will be stored and in which file format?

No more! now you have Dynaconf!

rochacbruno / dynaconf-mirror

dynaconf mirror (mainly for stats)- ORIGINAL REPO ON - https://github.com/dynaconf/dynaconf

dynaconf - Configuration Management for Python.

Features

Inspired by the 12-factor application guide
Settings management (default values, validation, parsing, templating)
Protection of sensitive information (passwords/tokens)
Multiple file formats toml|yaml|json|ini|py and also customizable loaders.
Full support for environment variables to override existing settings (dotenv support included).
Optional layered system for multi environments [default, development, testing, production]
Built-in support for Hashicorp Vault and Redis as settings and secrets storage.
Built-in extensions for Django and Flask web frameworks.
CLI for common operations such as init, list, write, validate, export.
full docs on https://dynaconf.com

Install

$ pip install dynaconf

Initialize Dynaconf on project root directory

$ cd path/to/your/project/
$ dynaconf init -f toml

⚙️  Configuring your Dynaconf environment
------------------------------------------
🐍 The file `config.py` was generated.

🎛️  settings.toml created to hold your settings.

🔑 .secrets.toml created to hold your secrets.

🙈 the .secrets.* is also included in `.gitignore`
  beware to not push your secrets

…

View on GitHub

Spend your precious time developing your application, run pip install dynaconf and let Dynaconf take care of your settings.

Quick start.

from dynaconf import settings

And that's it!

That is the only line of code you need, no complicated boilerplate, no hadouken-ifs, no need to maintain config classes.

You must be wondering - "What magic is this? Where does the setting values come from?"

Well, there is no magic, and the values can come from wherever you want, by default and following the recommendations of the 12 factor apps Dynaconf has preference for environment variables.

# optionally you can save it in .env file
export DYNACONF_DEBUG=true
export DYNACONF_NAME=Bruno

# app.py
from dynaconf import settings
if settings.DEBUG is True:
    print(settings.NAME)

$ python3 app.py
Bruno

And the environment variables for Dynaconf are typed using the toml format sotrue has been evaluated to boolean True and this makes it possible to export lists, dictionaries, floats, booleans, and so on.

More than environment variables

Well, that's cool, but your project will not have settings coming from just the environment variables, I'm sure you want to have a settings file where you can set default values.

Dynaconf can read multiple file formats, out of the box it supports .py, .toml, .ini and .json. If PyYAML is installed then it will also support .yaml and you don't have to take care of finding and opening the files. The preferred format is .toml because it is currently the best configuration format, widely addopted, and you can use whatever file format you want.

# settings.toml
[default]
name = "Bruno"

[development]
debug = true

[production]
debug = false

# app.py
from dynaconf import settings
if settings.DEBUG is True:
    print(settings.NAME)

$ python3 app.py
Bruno

And as you can see now using settings. file we can have separate [environments] by default dynaconf will always work on [development] which means only [default] and [development] variables will be loaded. At any time you can do export ENV_FOR_DYNACONF=production and then it starts using the values from [production] environment.

If you don't want to have that separation by environment, you can simply put everything under [default] section.

Read more about environments and settings file

Some values are secrets

A good practice is to not store your secrets like passwords and tokens directly on settings files, because you can make a mistake and commit that to a public git repository, so there are some alternatives to store secrets

Environment Variables

Not recommended

There are some people who disagrees and it is really a point of security failure. However, if you are sure that your machine is protected, you can leave the secrets in the variables, at your own risk, Dynaconf can read it normally.

Secret files

This is a simple level of security for keeping secrets, and it is specially useful to keep development secrets. That token you use to access the development API etc.

It is very simple, together with your normal settings.toml you put a new file called .secrets.toml and store your sensitive data there. Dynaconf will read it after the read of the settings.toml

Wait.. how does it solve my security problem?

Well it does not (yet) but it make your life easier in 2 ways.

Put .secrets.* in your ~/.gitignore so you will never commit the mistake of sending that data to a public git repository.
Dynaconf can output debug information when DEBUG_LEVEL_FOR_DYNACON=DEBUG is exported, all loaded values are printed but if the values comes from a .secrets.* file, then only the key is printed and the value is masked. It is useful to use on public CI.
You can setup a step on your Ansible deployment playbook that will safely copy or generate the secrets file to store there on your production environment.

You can also tell Dynaconf to load that file from somewhere else export SECRETS_FOR_DYNACONF=/path/to/secrets/location/.secrets.yaml (very useful for CI like Jenkins)

Vault Project from Hashicorp

Recommended!

Now we are really talking about true security

Using Vault is the better way to protect your secrets dynaconf has built-in support:

export VAULT_ENABLED_FOR_DYNACONF=true
export VAULT_URL_FOR_DYNACONF=https://..../
export OTHER_VAULT_CONFIGS

And then if have for example the TOKEN stores on your vault server you can simply do:

from dynaconf import settings
perform_your_authentication(settings.TOKEN)

Vault has lots of features like leases and sealed vaults.

Are you using Django or Flask?

Dynaconf provides extensions for those 2 frameworks, with 2 lines of code you enable it and then your framework will start reading settings from Dynaconf.

Django

# settings.py
import dynaconf  # noqa
settings = dynaconf.DjangoDynaconf(__name__, **options)

Now you if you do export DJANGO_FOO=BAR you can access inside your app via django.conf.settings.FOO

# app.py
from dynaconf import FlaskDynaconf
FlaskDynaconf(app, **options)

Now you if you do export FLASK_FOO=BAR you can access inside your app via app.config['FOO']

You can extend Dynaconf adding new loaders!

Dynaconf already provides loaders for:

.py
.json
.yaml
.toml
.ini
Redis Server
Vault Server
.env files
Environment variables

But if this is not a fit for your project you can still create your own loader

Conclusion

Dynaconf is the only thing you need to manage your settings!

Well tested
Trusted by companies like Red Hat, Seek, Catho and others
Well tested both on Linux and Windows environment
Strict separation of settings from code (following 12-factor applications Guide).
Define comprehensive default values.
Store parameters in multiple file formats (.toml, .json, .yaml, .ini and .py).
Sensitive secrets like tokens and passwords can be stored in safe places like .secrets file or vault server.
Parameters can optionally be stored in external services like Redis server.
Simple feature flag system.
Layered [environment] system.
Environment variables can be used to override parameters.
Support for .env files to automate the export of environment variables.
Correct data types (even for environment variables).
Have only one canonical settings module to rule all your instances.
Drop in extension for Flask app.config object.
Drop in extension for Django conf.settings object.
Powerful $ dynaconf CLI to help you manage your settings via console.
Customizable Validation System to ensure correct config parameters.
Allow the change of dynamic parameters on the fly without the need to redeploy your application.

Read the docs

Settings are simple but Dynaconf provides even more features like Feature Flags, Settings Context Managers, Plugin Settings etc..

Documentation: http://dynaconf.readthedocs.io/

Dynaconf is waiting for your feedback and Contribution

from dynaconf import settings
settings.THANKS_FOR_READING

DEV Community: Bruno Rocha

Hello Dev.to

Python Protocol Oriented Programming

Python Objects 🐍

Types 🔠

Protocols 📝

Typing and Protocol Checking

Typing Protocols

Is there the Traditional OOP in Python?

Inheritance

Encapsulation

Polymorfism

Conclusion

[EN] I am Learning Rust - Exercism Space Age

Never do this in Python

Criando seu blog com Zola e hospedando de graça na Netlify

Criando seu blog com Zola e hospedando de graça na Netlify

Componentes

Zola

Instalação

Criando um novo site Zola

from dynaconf import settings

rochacbruno / dynaconf-mirror

dynaconf mirror (mainly for stats)- ORIGINAL REPO ON - https://github.com/dynaconf/dynaconf

Features

Install

Initialize Dynaconf on project root directory

Quick start.

More than environment variables

Some values are secrets

Environment Variables

Secret files

Vault Project from Hashicorp

Are you using Django or Flask?

Django

Flask

What if you are using a different settings file format? a different framework and a different external storage?

Conclusion

Read the docs