Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .github/workflows/lint.yml
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ jobs:
strategy:
matrix:
python-version:
["3.8", "3.9", "3.10", "3.11", "3.12", "3.13", "3.14", "3.14t"]
["3.8", "3.9", "3.10", "3.11", "3.12", "3.13", "3.14", "3.14t", "3.15.0-alpha.1"]

steps:
- uses: actions/checkout@v4
Expand Down
2 changes: 1 addition & 1 deletion .github/workflows/tests_and_coverage.yml
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ jobs:
matrix:
os: [macos-latest, ubuntu-latest, windows-latest]
python-version:
["3.8", "3.9", "3.10", "3.11", "3.12", "3.13", "3.14", "3.14t"]
["3.8", "3.9", "3.10", "3.11", "3.12", "3.13", "3.14", "3.14t", "3.15.0-alpha.1"]

steps:
- uses: actions/checkout@v4
Expand Down
24 changes: 12 additions & 12 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,23 +17,23 @@

![logo](https://raw.githubusercontent.com/mutating/simtypes/develop/docs/assets/logo_2.svg)

Python type checking tools are usually very complex. In this case, we have thrown out almost all the places where there is a lot of complexity, and left only the most obvious and necessary things for runtime.
Python type checking tools are usually very complex. In this case, we have thrown out almost all the places where there is a lot of complexity, and left only the most obvious and necessary things for runtime use.


## Table of contents

- [**Why?**](#why)
- [**Installation**](#installation)
- [**Usage**](#usage)
- [**Type checking**](#type-checking)
- [**Special types**](#special-types)
- [**String deserialization**](#string-deserialization)


## Why?

It's been a long time since static type checking tools like [`mypy`](https://github.com/python/mypy) for `Python` have been available, and they've become very complex. The typing system has also become noticeably more complicated, providing us with more and more new types of annotations, new syntax and other tools. It seems that `Python` devs procrastinate endlessly, postponing all the really important [`CPyhton`](https://github.com/python/cpython) improvements in order to add more garbage to [`typing`](https://docs.python.org/3/library/typing.html).
It's been a long time since static type checking tools like [`mypy`](https://github.com/python/mypy) for `Python` have been available, and they've become very complex. The typing system has also become noticeably more complicated, providing us with more and more new types of annotations, new syntax and other tools. It seems that `Python` devs procrastinate endlessly, postponing all the really important [`CPython`](https://github.com/python/cpython) improvements in order to add more garbage to [`typing`](https://docs.python.org/3/library/typing.html).

A separate difficulty arises for those who try to use type annotations in runtime. Many data types make sense only in the context of static validation, and there is no way to verify these aspects in runtime. And some checks, although theoretically possible, would be extremely expensive. For example, to verify the validity of annotation `List[int]` in relation to a list, you would need to go through all its objects linearly to make sure that none of them violates the contract from the annotation.
A separate difficulty arises for those who try to use type annotations at runtime. Many data types make sense only in the context of static validation, and there is no way to verify these aspects at runtime. And some checks, although theoretically possible, would be extremely expensive. For example, to verify the validity of annotation `List[int]` in relation to a list, you would need to iterate over all its elements to make sure that none of them violates the contract from the annotation.

So, why do we need this package? There is only one function where you can pass a type or a type annotation + a specific value, and you will find out if one corresponds to the other. That's it! You can use this feature as a support when creating runtime type checking tools, however, we do not offer these tools here. You decide for yourself whether to wrap this function in syntactic sugar like decorators with automatic type checking.

Expand Down Expand Up @@ -66,15 +66,15 @@ pip install simtypes
You can also quickly try out this and other packages without having to install using [instld](https://github.com/pomponchik/instld).


## Usage
## Type checking

Import the `check` function:

```python
from simtypes import check
```

And pass there 2 arguments, a value + a type or type annotation:
And pass there two arguments, a value + a type or type annotation:

```python
print(check(1, int))
Expand Down Expand Up @@ -179,16 +179,16 @@ print(check(InnerNoneType('key'), InnerNoneType('key')))

## String deserialization

The library also provides primitive deserialization. Conversion of strings into several basic types in any combinations is supported:
The library also provides basic deserialization. Conversion of strings into several basic types in various combinations is supported:

- `str`- any string can be interpreted as a `str` type.
- `str` - any string can be interpreted as a `str` type.
- `int` - any integers.
- `float` - any floating-point numbers, including infinities and [`NaN`](https://en.wikipedia.org/wiki/NaN).
- `bool`- the strings `"yes"`, `"True"`, and `"true"` are interpreted as `True`, while `"no"`, `"False"`, or `"false"` are interpreted as `False`.
- `bool` - the strings `"yes"`, `"True"`, and `"true"` are interpreted as `True`, while `"no"`, `"False"`, or `"false"` are interpreted as `False`.
- `date` or `datetime` - strings representing, respectively, dates or dates + time in [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) format.
- `list` - lists in [`json`](https://en.wikipedia.org/wiki/JSON) format are expected.
- `tuple` - lists in [`json`](https://en.wikipedia.org/wiki/JSON) format are expected.
- `dict` - dicts in [`json`](https://en.wikipedia.org/wiki/JSON) format are expected.
- `list` - lists in [`JSON`](https://en.wikipedia.org/wiki/JSON) format are expected.
- `tuple` - lists in [`JSON`](https://en.wikipedia.org/wiki/JSON) format are expected.
- `dict` - dicts in [`JSON`](https://en.wikipedia.org/wiki/JSON) format are expected.

Examples:

Expand Down
5 changes: 3 additions & 2 deletions pyproject.toml
Original file line number Diff line number Diff line change
Expand Up @@ -4,14 +4,14 @@ build-backend = "setuptools.build_meta"

[project]
name = "simtypes"
version = "0.0.12"
version = "0.0.13"
authors = [{ name = "Evgeniy Blinov", email = "zheni-b@yandex.ru" }]
description = 'Type checking in runtime without stupid games'
readme = "README.md"
requires-python = ">=3.8"
dependencies = [
'typing_extensions ; python_version <= "3.12"',
'denial>=0.0.5',
'denial>=0.0.13',
]
classifiers = [
"Operating System :: OS Independent",
Expand All @@ -27,6 +27,7 @@ classifiers = [
'Programming Language :: Python :: 3.12',
'Programming Language :: Python :: 3.13',
'Programming Language :: Python :: 3.14',
'Programming Language :: Python :: 3.15',
'Programming Language :: Python :: Free Threading',
'Programming Language :: Python :: Free Threading :: 3 - Stable',
'License :: OSI Approved :: MIT License',
Expand Down
Loading