Находки в опенсорсе: Python

🚀 New issue to wemake-services/django-modern-rest by @Peopl3s 📝 TagSchema and RoleSchema do not enforce max_length, causing unhandled DB errors (#944) What's wrong? The Tag and Role Django models define name = CharField(max_length=100), but the corresponding Pydantic schemas accept any-length strings.

class TagSchema(pydantic.BaseModel):
      name: str  <!-----------------------------HERE                                                                                                                                                                 
                                                        
  class RoleSchema(pydantic.BaseModel):                                                                                                                                                                     
      name: str  <!-----------------------------HERE

When a client sends a name longer than 100 characters, Pydantic validation passes (HTTP 422 is never raised), and the value reaches the database layer where PostgreSQL raises DataError: value too long for type character varying(100). This results in an unhandled 500 instead of a proper 422 validation error. On SQLite the value is silently stored without truncation, masking the bug in tests. How it should be? Add max_length constraints to match the model definition:

                                                                                                                                                                                                            class TagSchema(pydantic.BaseModel):                  
    name: str = Field(max_length=100)
                                                                                                                                                                                                            class RoleSchema(pydantic.BaseModel):
    name: str = Field(max_length=100)

Used versions 0.7.0 OS information MacOS #bug #good_first_issue #help_wanted #django_modern_rest sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn 📝 Add `RefreshTokenSyncController` and `RefreshTokenAsyncController` (#907) Add RefreshTokenSyncController and RefreshTokenAsyncController Basically, they should accept refresh_token and return new pairs of access_token and refresh_token. But they should be reusable as well as the existing controllers. It should be similar to the existing views: django-modern-rest/dmr/security/jwt/views.py Lines 99 to 132 in dba07e8 Example from a real project: https://github.com/Griger10/g-pulse/blob/3d520b8444736eaaeffad1cf2221019f3ffad6c4/services/api/apps/accounts/api/views.py#L93 #feature #good_first_issue #help_wanted #django_modern_rest sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn 📝 Optimize `dmr_rf` and `dmr_client` test features for faster tests (#889) We provide our own fixtures that are subclasses of Django's builtin one. Django has this code inside: https://github.com/django/django/blob/7dc826b9758d634623a6f5ca05d0ca2048a0ce48/django/test/client.py#L450-L458

    def _encode_json(self, data, content_type):
        """
        Return encoded JSON if data is a dict, list, or tuple and content_type
        is application/json.
        """
        should_encode = JSON_CONTENT_TYPE_RE.match(content_type) and isinstance(
            data, (dict, list, tuple)
        )
        return json.dumps(data, cls=self.json_encoder) if should_encode else data

We need to optimize this method, because json.dumps is slow, but msgspec is fast. It won't be noticable on 1 tests, but will be on 2k tests (which is the case for our own test base). See how we conditionally dump our schema here: https://github.com/wemake-services/django-modern-rest/blob/master/dmr/openapi/dump.py Maybe we should reuse the same for tests? #good_first_issue #help_wanted #django_modern_rest sent via relator

🚀 New issue to ag2ai/faststream by @ce1ebrimbor 📝 Feature: Support broker-level ack_policy default with per-subscriber override (#2826) Problem Currently ack_policy can only be set per-subscriber:

@broker.subscriber("orders.topic", ack_policy=AckPolicy.NACK_ON_ERROR)
async def handle_order(msg: OrderMessage) -> None:
    ...

There is no way to set a default ack_policy at the broker (or router) level. In practice, most services want the same policy across all subscribers — typically NACK_ON_ERROR for at-least-once delivery with DLQ. This forces every @broker.subscriber() call to repeat the same ack_policy= argument, which is error-prone: forgetting it on a single subscriber silently falls back to ACK_FIRST (at-most-once), which can cause silent message loss. Proposed solution Add an ack_policy parameter to KafkaBroker (and equivalently to RabbitBroker, NatsBroker, etc.) that sets the default for all subscribers registered on that broker. Individual subscribers can still override it.

broker = KafkaBroker("localhost:9092", ack_policy=AckPolicy.NACK_ON_ERROR)

# Inherits NACK_ON_ERROR from broker
@broker.subscriber("orders.topic")
async def handle_order(msg: OrderMessage) -> None:
    ...

# Overrides to ACK for this specific subscriber
@broker.subscriber("notifications.topic", ack_policy=AckPolicy.ACK)
async def handle_notification(msg: NotificationMessage) -> None:
    ...

The resolution order would be: subscriber-level > broker-level > built-in default (ACK_FIRST). Why this matters • Safety: ACK_FIRST as a silent default is dangerous for services that use DLQ or need at-least-once delivery. A broker-level default lets teams enforce their delivery guarantee in one place. • DRY: Services with 10+ subscribers shouldn't need to repeat ack_policy=AckPolicy.NACK_ON_ERROR on every one. • Consistency with other broker-level settings: decoder, middlewares, security, and logger are all broker-level defaults that subscribers inherit. ack_policy is the notable exception. #enhancement #good_first_issue #faststream #ag2ai sent via relator

🚀 New issue to wemake-services/django-modern-rest by @LesPrimus 📝 UnsolvableAnnotationsError when subclassing a concrete Controller subclass` (#873) What's wrong? Bug: UnsolvableAnnotationsError when subclassing a concrete Controller subclass Description When creating an intermediate concrete controller class and then subclassing it, __init_subclass__ raises UnsolvableAnnotationsError even though the serializer is already resolved on the parent. Reproduction

from dmr import Controller
from dmr.plugins.pydantic import PydanticSerializer
from dmr.serializer import BaseSerializer
                                                                                                                                                                            
 
class BaseController[T: BaseSerializer](Controller[T]):                                                                                                                     
    pass        


class PydanticController(BaseController[PydanticSerializer]):
    pass


# This raises UnsolvableAnnotationsError
class UserController(PydanticController):
    def get(self) -> ...:
        ...                                                                                                                                                                 
 
Error                                                                                                                                                                       
                
dmr.exceptions.UnsolvableAnnotationsError: Type args () are not correct for <class 'UserController'>,
at least 1 type arg must be provided

Expected behavior

UserController should inherit the serializer from its concrete parent PydanticController,                                                                                   
which already has serializer = PydanticSerializer set.


--

Thanks for the awesome library, I just started exploring it and I'm really enjoying it so far!

--

### How it should be?

Subclassing a concrete `Controller` subclass (one that already has a resolved serializer)                                                                                   
should work without requiring the type argument to be re-specified.                                                                                                         
                                                                                                                                                                            
`UserController(PydanticController)` should behave the same as `UserController(BaseController[PydanticSerializer])`.

### Used versions

- `django-modern-rest==0.5.0`                                                                                                                                               
-  `Python 3.14.0` 

### OS information

- `Linux tuxedo-stellaris 6.17.0-111019-tuxedo x86_64 (Ubuntu 24.04)`

#bug #good_first_issue #help_wanted #django_modern_rest sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn 📝 Add a Django command to export OpenAPI schemas (#858) It migth be useful to people who want to share the schema. Or automate something with it. I propose to add a django command: dmr_export_schema. Args: • Where to find schema, I think we should reuse import_string logic from Django. Required • All json formatting ones: sort_keys and indent • Format: json or yaml, check that yaml is installed. Default is json We should print it to the stdout always. Usages:

# regular:
python manage.py dmr_export_schema server.urls:schema

# pretty:
python manage.py dmr_export_schema server.urls:schema --format json --indent=2 --sort-keys

This would need tests, we can test it as a subprocess, it is a django command after all. And docs. #enhancement #good_first_issue #help_wanted #django_modern_rest sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn 📝 Support `orjson` as a possible backend for `JsonParser` / `JsonRenderer` (#857) Currently we always use json as a module in JsonParser and JsonRenderer: django-modern-rest/dmr/parsers.py Lines 132 to 134 in 69822ff But, we can make this module customizable. We can pass orjson module there, since it also has a similar API. Something like:

class JsonParser(Parser):
    __slots__ = ('_json_module', ...)
    def __init__(self, json_module: _JsonModule = json, ...) -> None:
       self._json_module = json_module

And later self._json_module.loads(...) This would need multiple test cases: install orjson as unit-test dependency and add unit tests for this new renderer / parser. And we can document that with an example in the integrations.rst docs. #enhancement #good_first_issue #help_wanted #django_modern_rest sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn 📝 Add docs and example about `django-health-check` integration (#831) One can use https://github.com/codingjoe/django-health-check for health checks. No special integration from our side is required. This information can be added here: https://github.com/wemake-services/django-modern-rest/blob/master/docs/pages/integrations.rst #documentation #enhancement #good_first_issue #help_wanted #django_modern_rest sent via relator

🚀 New issue to ag2ai/faststream by @dumpler 📝 Bug: Logger not properly passed to Confluent Kafka Producer and AdminClient (#2691) Describe the bug There are two related issues with logger configuration in the Confluent Kafka components: 1.  Late Logger Setup in AsyncConfluentProducer  In faststream/confluent/helpers/client.py at line 46, the Producer object is created before the _setup() method is called for loger_state. This results in the Producer receiving a NoSetLoggerObject instead of the intended logger passed during initialization. 2.  Missing Logger in AdminClient  The AdminClient in AdminService does not accept a logger parameter, even though it should. Currently, only the configuration is passed, leaving the AdminClient without proper logging. How to reproduce Include source code:

import logging

import uvicorn
from fastapi import FastAPI
from faststream.confluent.fastapi import KafkaRouter

logger = logging.getLogger("faststream")

router = KafkaRouter(
    bootstrap_servers="kafka:9092",
    enable_idempotence=True,
    allow_auto_create_topics=False,
    schema_url="/asyncapi",
    include_in_schema=True,
    logger=logger,
)

app = FastAPI()
app.include_router(router)

uvicorn.run(app, host="0.0.0.0", port=8000)

Expected behavior 1. The Producer in AsyncConfluentProducer should use the logger passed to KafkaRouter. 2. The AdminClient should inherit the same logger as other components. Observed behavior 1. The Producer uses NoSetLoggerObject instead of the provided logger. 2. The AdminClient lacks logger configuration, leading to potential silent failures or inadequate logging. Environment Running FastStream 0.6.3 with CPython 3.13.1 on Linux #bug #good_first_issue #faststream #ag2ai sent via relator

🚀 New issue to ag2ai/faststream by @hmvp 📝 Bug: topic patterns are not correctly documented (#2804) Describe the bug When using a pattern for a kafka topic the generated asyncapi spec (and docs) does not include that handler How to reproduce With something along the lines of:

broker = KafkaBroker(...)

router = KafkaRouter()

@router.subscriber(pattern="some.wildcard.topic.*")
def handle_event(event: Event): ...

broker.include_router(router)

app = AsgiFastStream(
        broker,
        asyncapi_path="/docs",
    )

Expected behavior The subscriber is included in the asyncapi spec and docs. As far as I can see the asyncapi spec actually allows for this even when using Path variables. Observed behavior The asyncapi docs don't contain that subscriber. Screenshots Environment Running FastStream 0.6.7 with CPython 3.14.0 on Linux Additional context #bug #good_first_issue #faststream #ag2ai sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn 📝 Test and declare officail `NamedTuple` support (#774) Here's the code:

>>> from typing import NamedTuple
>>> class A(NamedTuple):
...     x: int
...     y: int
...     
>>> import pydantic
>>> pydantic.TypeAdapter(A).validate_python({'x': 1, 'y': 2})
A(x=1, y=2)
>>> pydantic.TypeAdapter(A).validate_python({'x': 1, 'y': 'a'})
Traceback (most recent call last):
  File "<python-input-11>", line 1, in <module>
    pydantic.TypeAdapter(A).validate_python({'x': 1, 'y': 'a'})
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^
  File "/Users/sobolev/Desktop/django-modern-rest/.venv/lib/python3.13/site-packages/pydantic/type_adapter.py", line 441, in validate_python
    return self.validator.validate_python(
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
        object,
        ^^^^^^^
    ...<6 lines>...
        by_name=by_name,
        ^^^^^^^^^^^^^^^^
    )
    ^
pydantic_core._pydantic_core.ValidationError: 1 validation error for call[A]
y
  Input should be a valid integer, unable to parse string as an integer [type=int_parsing, input_value='a', input_type=str]
    For further information visit https://errors.pydantic.dev/2.12/v/int_parsing

As we can see, NamedTuple models work well with pydantic. So, here's what we need to do: 1. Add a test case to test_plugins/test_pydantic that it works with NamedTuple 2. Add a doc example here https://django-modern-rest.readthedocs.io/en/latest/pages/getting-started.html#showcase 3. Add a changelog entry, that it is now officially supported We welcome new contributors :) #enhancement #good_first_issue #help_wanted #django_modern_rest sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn 📝 Provide `dmr.cookies.set_cookies` helper function (#773) Currently we have two places where we duplicate this code: django-modern-rest/dmr/streaming/controller.py Lines 172 to 178 in a6bc356 and django-modern-rest/dmr/response.py Lines 256 to 259 in a6bc356 So, it can probably be useful to others as well. Let's move this to cookies.py as a public helper function. Also, document it in public-api.rst This is a very easy task for new contributors. #enhancement #good_first_issue #help_wanted #django_modern_rest sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn 📝 Provide our own `settings` fixture (#760) When using settings fixture from pytest-django we frequently change them. However, we have dmr_clean_settings fixture, which should be use when we touch our own settings. So, let's add a new fixture to dmr_pytest.py which will return unchanged settings: LazySettings, but will also use dmr_clean_settings. Also, remove all dmr_clean_settings from our own tests, where settings is used. #enhancement #good_first_issue #help_wanted #django_modern_rest sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn 📝 Use the latest django version by default (#759) Currently we use 5.2 by default: django-modern-rest/pyproject.toml Line 77 in bea5f2d But, we need to use the latest one. Which is 6.0. Also, we would need to change this CI job to use 5.2 instead: django-modern-rest/.github/workflows/test.yml Lines 71 to 78 in bea5f2d #good_first_issue #help_wanted #django_modern_rest sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn 📝 Support `Path` with `*args` (#754) Right now Path component only supports parsing from request.kwargs. Which is like 99% of cases. However, parsing from request.args is not supported: django-modern-rest/dmr/components.py Lines 655 to 662 in b3f9c08 What should we do instead? 1. When request.args is provided we should require models like:

>>> import pydantic
>>> class UserId(pydantic.BaseModel):
...     user_id: int

>>> PathModel = pydantic.RootModel[tuple[tuple[int, ...], UserId]]

>>> PathModel.model_validate((('1', '2', '3'), {'user_id': 10}))
RootModel[tuple[tuple[int, ...], UserId]](root=((1, 2, 3), UserId(user_id=10)))

1. We would return tuple[Args, Kwargs] from this component if request.args is set 2. Test this with unnamed re_path urls https://docs.djangoproject.com/en/6.0/topics/http/urls/#using-unnamed-regular-expression-groups 3. Test this in tests/test_unit/test_components/test_path.py 4. Document this feature in docs/pages/components/path.rst 5. Provide an example in docs/examples/components/path_args.py and include it to path.rst 6. Provide a changelog entry 7. Remove _UNNAMED_PATH_PARAMS_MSG and all translations of this string, recompile all translations with make translations Contributions are welcome! This is an intermediate level task :) #enhancement #good_first_issue #help_wanted #django_modern_rest sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn 📝 Test `Controller[BaseSerializer]` corner case (#749) Currently we don't test that Controller[BaseSerializer] is not a valid way of creating a controller class. It must accept subclasses for BaseSerializer, but not BaseSerializer itself. We need: • a test case here https://github.com/wemake-services/django-modern-rest/blob/master/tests/test_unit/test_controllers/test_extend_controller.py • a possible fix to raise an error when BaseSerializer is given to a controller here:  django-modern-rest/dmr/controller.py  Lines 157 to 164 in acb9c17 This is a very easy task, so new contributors are very welcome! #bug #good_first_issue #help_wanted #django_modern_rest sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn 📝 Support `openapi.yaml` (#745) Litestar supports openapi.yaml view, so should we: https://docs.litestar.dev/latest/usage/openapi/ui_plugins.html It should be only available if msgspec is installed, it can dump yaml with msgspec.yaml. Everything else should be identical to openapi.json view. This is a rather easy task, so new contributors are very welcome! #documentation #good_first_issue #help_wanted #django_modern_rest sent via relator

задача очень большая, языков много! подключайтесь :)

🚀 New issue to wemake-services/django-modern-rest by @sobolevn 📝 Translate `django-modenr-rest` to your native language! (#718) Docs: https://docs.djangoproject.com/en/6.0/topics/i18n/ How to do it? 1. Run poetry install --all-groups --all-extras 2. Run poetry run django-admin makemessages -l YOUR_LOCALE, for example: poetry run django-admin makemessages -l ru_RU, full list of locales: https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes 3. Translate the new file created in dmr/locale/YOUR_LOCALE/LC_MESSAGES/django.po 4. Run poetry run django-admin compilemessages 5. Done! You are awesome, submit the PR :) We welcome all contributions! #enhancement #good_first_issue #help_wanted #django_modern_rest sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn 📝 Deploy example application somewhere (#691) We have an example Django app that we can deploy somewhere: https://github.com/wemake-services/django-modern-rest/tree/master/django_test_app So, users would have a real life application to test and interact with. I propose finding a service that: • Is free for our case • Can support deployments from GitHub Actions, so we can do that in CI as well • Provides some kind of a permanent link, so we can share it • Does not require complex deployment strategy Like PythonAnywhere or Heroku or Vercel, etc. Any help is appreciated. #documentation #enhancement #good_first_issue #help_wanted #django_modern_rest sent via relator