Gram orsinium @nico-lab-com Amsterdam Python, Go, Web, Security. All my projects:

life4/textdistance 1823

Compute distance between sequences. 30+ algorithms, pure python implementation, common interface, optional external libs usage.

dephell/dephell 1618

:package: :fire: Python project management. Manage packages: convert between formats, lock, install, resolve, isolate, test, build graph, show outdated, audit. Manage venvs, build package, bump version.

life4/flakehell 171

Flake8 wrapper to make it nice, legacy-friendly, configurable.

life4/gweb 164

Interact with browser from Go. Manually-crafted WebAPI interoperation library.

orsinium-archive/django-bruteforce-protection 109

Bruteforce protection for Django projects based on Redis. Simple, powerful, extendable.

life4/deal 108

Design by contract for Python with many validators support.

orsinium-archive/djburger 79

Framework for safe and maintainable web-projects.

has2k1/plotnine-examples 71

Jupyter Notebooks that are part of the plotnine documentation

life4/homoglyphs 62

Homoglyphs: get similar letters, convert to ASCII, detect possible languages and UTF-8 group.

life4/awesome-python-code-formatters 34

A curated list of awesome Python code formatters


started time in 6 hours

issue commenttypeddjango/awesome-python-typing

[Request] Please list "beartype" in the "Dynamic type checkers" section

I should probably write all of that up into a new subsection of our README.rst publicly exhibiting these shenanigans

And not only README, I would appreciate a series of articles about it.

That feeling when you realize you should have become a professor after all.

Totally! 👍


comment created time in 17 hours

issue commenttypeddjango/awesome-python-typing

[Request] Please list "beartype" in the "Dynamic type checkers" section

Thanks so much for the kind comments! I've been bear-wrestling with PEP 585 all evening, so that means more than you know.

I love fielding questions like this, too. beartype not only supports shallow type hints like List[int] but also deeply nested constructs like Union[dict, float, int, Sequence[Union[dict, float, int, MutableSequence[str]]]] – which I just pulled verbatim from our voluminous test suite, so that surprisingly behaves as expected. <sup>Phew.</sup>

For the specific case of List[int], beartype dynamically generates a new wrapper function randomly type-checking one item of the passed or returned list to be an integer on each call – preserving our O(1) call-time guarantee while also guaranteeing eventual coverage over the entire list after a sufficient number of calls. Specifically, the expected number of calls required to type-check all items of a list of n items to be integers is O(n log n). So, given this:

from beartype import beartype
from typing import List

def thoracic_spine_collapser(nerve_compression: List[int]) -> int:
    return nerve_compression[0] if nerve_compression else 42

beartype dynamically generates this new wrapper function:

def __beartyped_thoracic_spine_collapser(
    # Generate and localize a sufficiently large pseudo-random integer for
    # subsequent indexation in type-checking randomly selected container items.
    __beartype_random_int = __beartype_getrandbits(32)
    # Localize the number of passed positional arguments for efficiency.
    __beartype_args_len = len(args)
    # Localize this positional or keyword parameter if passed *OR* to the
    # sentinel value "__beartypistry" guaranteed to never be passed otherwise.
    __beartype_pith_0 = (
        args[0] if __beartype_args_len > 0 else
        kwargs.get('nerve_compression', __beartypistry)

    # If this parameter was passed...
    if __beartype_pith_0 is not __beartypistry:
        # Type-check this passed parameter or return value against this
        # PEP-compliant type hint.
        if not (
            # True only if this pith shallowly satisfies this hint.
            isinstance(__beartype_pith_0, list) and
            # True only if either this pith is empty *OR* this pith is
            # both non-empty and deeply satisfies this hint.
            (not __beartype_pith_0 or isinstance(__beartype_pith_0[__beartype_random_int % len(__beartype_pith_0)], int))

    # Call this function with all passed parameters, type-check the value
    # returned from this call against this PEP-noncompliant type hint, and
    # return this value only if this check succeeds.
    __beartype_return_value = __beartype_func(*args, **kwargs)
    if not isinstance(__beartype_return_value, __beartype_func.__annotations__['return']):
        raise __beartype_nonpep_return_exception(
            '@beartyped thoracic_spine_collapser() return value {} not {!r}.'.format(
                __beartype_trim(__beartype_return_value), __beartype_func.__annotations__['return']))
    return __beartype_return_value

There are more than a few interesting tidbits to unpack here, including:

  • The code comments above are verbatim as they appear in the generated code. Noice.
  • __beartype_random_int, a randomly generated 32-bit integer. If a pure-Python list contains more than 2**32 items, the user probably has bigger problems. :hear_no_evil:
  • __beartypistry, an internal thread-safe global registry of all types, tuples of types, and forward references to currently undeclared types in type hints in callables decorated by beartype. Yup. Lotsa well-tested black magic there.
  • The line (not __beartype_pith_0 or isinstance(__beartype_pith_0[__beartype_random_int % len(__beartype_pith_0)], int)) is where the specific magic of randomly testing list items to be integers happens, naturally accounting for the edge case of empty lists.

Things get really interesting when beartype dynamically generates wrapper functions for callables annotated with deeply nested type hints like List[List[List[int]]], because we actually leverage PEP 572-style assignment expressions to localize repeatedly accessed random list items. But... I think I've exhausted us all enough for an evening.

Thanks again, @sobolevn! Come to think, I should probably write all of that up into a new subsection of our README.rst publicly exhibiting these shenanigans. Can't let a good opportunity to pontificate online go to waste, right? That feeling when you realize you should have become a professor after all.


comment created time in 19 hours

issue commenttypeddjango/awesome-python-typing

[Request] Please list "beartype" in the "Dynamic type checkers" section

Oh wow, beartype looks amazing! I will totally add it. I will also would love to learn how your List[int] support is implemented. I have tried several libraries, but they usually fail on this type.


comment created time in 2 days

issue openedtypeddjango/awesome-python-typing

[Request] Please list "beartype" in the "Dynamic type checkers" section

Thanks for all the awesome typing lists, @sobolevn, @orsinium, and other fearless contributors. If someone could find a spare moment to add a terse link to beartype, a recently released constant-time (i.e., O(1) with negligible constants at call time regardless of container size) runtime type checker compliant with Python 3.6—3.9 and PEPs 483, 484, 540, 560, 563, 593 and soon to be compliant with PEP 585 that I personally maintain, that would be... like, super awesome: e.g.,

  • beartype - Constant-time runtime type checker.

...or something. I leave everything to your skilled and talented hands.

Thanks again. This has been an extreme year for humanity, so I humbly appreciate everyone's continued focus on this small (but crucial) slice of the Python pie. You're all awesome!

created time in 2 days

fork rakyll/grafana

The tool for beautiful monitoring and metric analytics & dashboards for Graphite, InfluxDB & Prometheus & More

fork in 2 days


started time in 3 days


started time in 3 days


started time in 4 days


started time in 4 days


started time in 4 days


started time in 4 days


started time in 4 days


started time in 4 days


started time in 4 days

issue openeddephell/dephell

How to undo 'dephell project register'?

For context, I am coming from here:


In short, we are trying to figure out how to add editable installations of some external libraries into a poetry-managed environment. We found out about dephell project register, and it seems to be an agreeable compromise (until actual editable installations are standardized and implemented in poetry). Now as it seems, we are stuck at undoing the effects of this operation.

How to uninstall a project installed as editable via dephell project register?

1. It seems like it would be nice to have a dephell command to undo the project register operations. Would that be possible?

2. It seems like the content of the Library.egg-link file created by dephell in the environment's site-packages directory contains something like path/to/Library/Library.egg-info while (as far as I know) it should contain path/to/Library instead. This difference makes it so that pip can not uninstall the project. The uninstall done by pip would not be complete anyway since the dephell.pth would remain unchanged, but still...

created time in 7 days


started time in 10 days

push eventtypeddjango/awesome-python-typing

Nikita Sobolev

commit sha eec38192d82ba5d665c9b0c144601f350fbb43ac


view details

push time in 10 days

push eventtypeddjango/awesome-python-typing

Nikita Sobolev

commit sha ce2db6924d185b7cec2b2c58a308c19bd98c1991

Update misspell.yml

view details

push time in 10 days

fork rakyll/client-go

Go client for Kubernetes.

fork in 10 days

pull request commentdephell/dephell_discover

Allow package_data files to not have an extension

@orsinium @eli-schwartz Hey, I saw you've made some changes to the repository in the last week. Is there a reason you're not mergin in my PR? My team's adoption of dephell is still blocked by this issue. The lack of response from your side is frustrating, you tell me to make PR when I create an issue ticket and when I do there's no more communication. If there's a reason why you don't want to merge it in then please tell me and we can find a solution that everyone is happy with. The actual fix is less than one line of code, so it won't take a lot of time to review. I see that in the meantime you've fixed the CI yourself, even though I also did that in this PR. I can remove all the CI related changes in this PR if you prefer, I just implemented that to be able to get a passing run. The actual change I need is for dephell to no longer be opinionated about whether files need extensions in order to be discoverable. If you see a problem with that, let me know.


comment created time in 11 days

created repositoryneargye-forks/test-ci

created time in 11 days

created repositoryabilian/olapy-pyiodide

created time in 13 days


started time in 13 days


started time in 14 days

created repositoryabilian/abilian-sbe-cloud

Cloud deployment (Heroku, Docker, etc.) for Abilian SBE

created time in 14 days


started time in 14 days


started time in 14 days