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

🚀 New issue to wemake-services/django-modern-rest by @sobolevn 📝 Test and document that default values for components are supported (#1494) Currently we don't ever test or document that a code like this: from dmr import Body, Controller from dmr.plugins.pydantic import PydanticSerializer class MyController(Controller[PydanticSerializer]): def post( self, parsed_body: Body[dict[str, str] | None] = None, ) -> str: print(parsed_body) return 'done' is even supported. What is important here? 1. We must call the endpoint function as-is, without any work from our part. Defaults must be real python defaults. And work the same way 2. But, if there are default for Body, we must issue required: false schema for the whole body Snapshot test is required for this change. #good_first_issue #help_wanted #opensource_september #django_modern_rest sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn 📝 `CookieJWT[A]syncAuth` and `HeaderJWT[A]syncAuth` have the same security schema name (#1587) This makes it impossible to use them together in a single endpoint / contoller together by default. Only a single jwt security schema / requirement will be generated. Which is not correct. We need to change the CookieJWT[A]syncAuth one to be jwt_cookie #bug #good_first_issue #help_wanted #openapi #opensource_september #django_modern_rest sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn 📝 `_validate_throttling` check is a bad design :( (#1600) This code django-modern-rest/dmr/validation/endpoint_metadata.py Lines 934 to 971 in 6649d05 knows a lot about specific backends for throttling. But, why do we do this in metadata validation? Why don't we create .validate method in throttling (and auth just in case) objects instead? Like we do for parser and renderer objects: django-modern-rest/dmr/parsers.py Lines 47 to 58 in 6649d05 This way we can validate objects directly where they know how to self-validate. #feature #good_first_issue #help_wanted #opensource_september #django_modern_rest sent via relator

🚀 New issue to wemake-services/django-modern-rest by @vyhuholl 📝 Seeded OpenAPI examples of `datetime` and `time` change with the current time (#1632) What's wrong? Found while working on #1629. With DMR_SETTINGS = {'openapi_examples_seed': 1} and the same PYTHONHASHSEED, examples of datetime and time fields are different on every run: class _Event(msgspec.Struct): created_at: dt.datetime day: dt.date at: dt.time duration: dt.timedelta class _EventController(Controller[MsgspecSerializer]): def get(self) -> _Event: raise NotImplementedError Two runs 3 seconds apart, both with PYTHONHASHSEED=0: 02:18:43 {"created_at": "2000-10-08T03:39:12.378838", "day": "2025-09-16", "at": "18:36:00.366279", "duration": "P0D"} 02:18:46 {"created_at": "2000-10-08T03:39:16.378838", "day": "2025-09-16", "at": "18:36:03.421377", "duration": "P0D"} polyfactory generates these with Faker, and Faker's defaults end at the current time: datetime uses date_time_between, which ends at "now", and time uses time_object, which picks a time between 1970 and now. The seed fixes the random part, but the range moves with the clock, so the value moves too. date uses date_this_decade, which ends at today, so it changes once a day. So a schema with such fields is never the same on two runs, even though the seed_example_factory docstring says that seeding per build "keeps a schema reproducible on its own". How it should be? The same openapi_examples_seed should give the same examples at any time. _ExampleFactory in dmr/openapi/mappers/example.py can override get_provider_map() and give datetime, date and time fixed bounds instead of "now". timedelta could get a range there too: its examples are always P0D now, because time_delta() without end_datetime starts and ends at "now". Used versions django-modern-rest 0.15.0, polyfactory 3.3.0, faker 40.39.0 Reproduced on c35128a. OS information macOS 27.0 #bug #good_first_issue #help_wanted #openapi #opensource_se

🚀 New issue to wemake-services/django-modern-rest by @Izcarmt95 📝 OpenAPI: duplicated tags when both Router(tags=...) and @modify(tags=...) set the same tag (#1656) When an operation has a tag in @modify(tags=...) and its Router has the same tag in Router(tags=...), the generated OpenAPI operation lists the tag twice. UIs like Scalar then show every operation twice, once per tag entry. from dmr import Controller, modify from dmr.openapi import build_schema from dmr.plugins.pydantic import PydanticSerializer from dmr.routing import Router, path class UserController(Controller[PydanticSerializer]): @modify(tags=['Users']) def get(self) -> str: return 'ok' users = Router('/users', [path('/all', UserController.as_view(), name='users')], tags=['Users']) api = Router('api') api.include(users, namespace='users') schema = build_schema(api) print(schema.paths['/api/users/all'].get.tags) # ['Users', 'Users'] Expected: ['Users']. The router tags and the endpoint tags should be merged without duplicates. This looks related to the change for #1299, which now propagates router metadata to included routes. • django-modern-rest 0.15.0 • Django 5.2, Python 3.13 ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ AI disclaimer: an AI assistant was used only to help write this issue. #bug #good_first_issue #help_wanted #openapi #opensource_september #django_modern_rest sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn 📝 Improve `dmr` skill with `concrete_views` example (#1670) We should state that using concrete_views is better than implementing your own views that do not change anything. Add this to the dmr skill. #feature #good_first_issue #help_wanted #django_modern_rest sent via relator