[PR #1343] [CLOSED] Add Dynamic Analysis section #1186

New Issue

GiteaMirror · 2025-11-06T13:11:08-06:00

GiteaMirror commented

2025-11-06 13:11:08 -06:00

📋 Pull Request Information

Original PR: https://github.com/vinta/awesome-python/pull/1343
Author: @roo-oliv
Created: 9/5/2019
Status: ❌ Closed

Base: master ← Head: patch-1

📝 Commits (1)

d2f5d81 Add Dynamic Analysis section

📊 Changes

1 file changed (+7 additions, -0 deletions)

View changed files

📝 README.md (+7 -0)

📄 Description

Add a Dynamic Analysis section and include parameters-validation lib to it.

What is this Python project?

parameters-validation lib eases function parameters validation regarding type, content and/or any other custom validations one may wish to perform.

It leverages type-hint annotations to provide a clean and unobstructive way to adopt the Look Before You Leap principle when you need to.

What's the difference between this Python project and similar ones?

There are no similar projects currently. Usually, the developer will write their own validation helper functions and manually call'em. While this is fine, the end result pollutes function bodies with validation actions that are not the core responsibility of a function. Nevertheless, there are simple validations (such as checking if a string is not blank or that a number is not negative) that will be kinda frequent and repeated all over different projects while performing exactly the same functionality.

parameters-validation lib enables removing the validation logic from the function body, explicitly stating validations upfront in the function signature and provides ready-to-use common validations.

Here a simple comparison between runtime validations with and without using parameters-validation:

"""
Using parameters-validation lib: clean and explicit way of declaring
and performing runtime validations
"""
@validate_parameters
def register(
    token: strongly_typed(AuthToken),
    name: non_blank(str),
    age: non_negative(int),
    nickname: no_whitespaces(non_empty(str)),
    bio: str,
):
    # do register

"""
Adding validation code directly at the function body: explicit on the
validations but pollutes the function body
"""
@validate_parameters
def register(
    token: AuthToken,
    name: str,
    age: int,
    nickname: str,
    bio: str,
):
    if not isinstance(token, AuthToken):
        raise TypeError("Parameter 'token' must be of type 'AuthToken'")
    if not bool(name and name.strip()):
        raise ValueError("Parameter 'name' cannot be blank nor empty")
    if age < 0:
        raise ValueError("Parameter 'age' cannot be negative")
    if not nickname:
        raise ValueError("Paramater 'nickname' cannot be empty")
    if " " in nickname:
        raise ValueError("Parameter 'nickname' cannot contain whitespaces")
    # do register

"""
Adding validation code in a helper function: implicit on the
validations pollutes outer scope of the function with the companion
helper function. The companion helper is harder to keep in sync
with the register function and duplicates parameters declarations
"""
_validate_register_parameters(
    token: AuthToken,
    name: str,
    age: int,
    nickname: str,
    bio: str,
):
    if not isinstance(token, AuthToken):
        raise TypeError("Parameter 'token' must be of type 'AuthToken'")
    if not bool(name and name.strip()):
        raise ValueError("Parameter 'name' cannot be blank nor empty")
    if age < 0:
        raise ValueError("Parameter 'age' cannot be negative")
    if not nickname:
        raise ValueError("Paramater 'nickname' cannot be empty")
    if " " in nickname:
        raise ValueError("Parameter 'nickname' cannot contain whitespaces")

@validate_parameters
def register(
    token: AuthToken,
    name: str,
    age: int,
    nickname: str,
    bio: str,
):
    _validate_register_parameters(token, name, age, nickname, bio)
    # do register

--

Anyone who agrees with this pull request could vote for it by adding a 👍 to it, and usually, the maintainer will merge it when votes reach 20.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/vinta/awesome-python/pull/1343 **Author:** [@roo-oliv](https://github.com/roo-oliv) **Created:** 9/5/2019 **Status:** ❌ Closed **Base:** `master` ← **Head:** `patch-1` --- ### 📝 Commits (1) - [`d2f5d81`](https://github.com/vinta/awesome-python/commit/d2f5d814449b1461bb7daa3b580fbca2cada63cd) Add Dynamic Analysis section ### 📊 Changes **1 file changed** (+7 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `README.md` (+7 -0) </details> ### 📄 Description Add a _Dynamic Analysis_ section and include [`parameters-validation`](https://github.com/allrod5/parameters-validation) lib to it. ## What is this Python project? parameters-validation lib eases function parameters validation regarding type, content and/or any other custom validations one may wish to perform. It leverages type-hint annotations to provide a clean and unobstructive way to adopt the [*Look Before You Leap* principle](https://docs.python.org/3/glossary.html#term-lbyl) when you need to. ## What's the difference between this Python project and similar ones? There are no similar projects currently. Usually, the developer will write their own validation helper functions and manually call'em. While this is fine, the end result pollutes function bodies with validation actions that are not the core responsibility of a function. Nevertheless, there are simple validations (such as checking if a string is not blank or that a number is not negative) that will be kinda frequent and repeated all over different projects while performing exactly the same functionality. `parameters-validation` lib enables removing the validation logic from the function body, explicitly stating validations upfront in the function signature and provides ready-to-use common validations. Here a simple comparison between runtime validations with and without using `parameters-validation`: ```python """ Using parameters-validation lib: clean and explicit way of declaring and performing runtime validations """ @validate_parameters def register( token: strongly_typed(AuthToken), name: non_blank(str), age: non_negative(int), nickname: no_whitespaces(non_empty(str)), bio: str, ): # do register ``` ```python """ Adding validation code directly at the function body: explicit on the validations but pollutes the function body """ @validate_parameters def register( token: AuthToken, name: str, age: int, nickname: str, bio: str, ): if not isinstance(token, AuthToken): raise TypeError("Parameter 'token' must be of type 'AuthToken'") if not bool(name and name.strip()): raise ValueError("Parameter 'name' cannot be blank nor empty") if age < 0: raise ValueError("Parameter 'age' cannot be negative") if not nickname: raise ValueError("Paramater 'nickname' cannot be empty") if " " in nickname: raise ValueError("Parameter 'nickname' cannot contain whitespaces") # do register ``` ```python """ Adding validation code in a helper function: implicit on the validations pollutes outer scope of the function with the companion helper function. The companion helper is harder to keep in sync with the register function and duplicates parameters declarations """ _validate_register_parameters( token: AuthToken, name: str, age: int, nickname: str, bio: str, ): if not isinstance(token, AuthToken): raise TypeError("Parameter 'token' must be of type 'AuthToken'") if not bool(name and name.strip()): raise ValueError("Parameter 'name' cannot be blank nor empty") if age < 0: raise ValueError("Parameter 'age' cannot be negative") if not nickname: raise ValueError("Paramater 'nickname' cannot be empty") if " " in nickname: raise ValueError("Parameter 'nickname' cannot contain whitespaces") @validate_parameters def register( token: AuthToken, name: str, age: int, nickname: str, bio: str, ): _validate_register_parameters(token, name, age, nickname, bio) # do register ``` -- Anyone who agrees with this pull request could vote for it by adding a :+1: to it, and usually, the maintainer will merge it when votes reach **20**. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

GiteaMirror added the pull-request label 2025-11-06 13:11:08 -06:00

GiteaMirror closed this issue

2025-11-06 13:11:08 -06:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/awesome-python#1186