Re: Fellow Reports - August 2022
Week ending August 28, 2022 *Triaged: * https://code.djangoproject.com/ticket/33954 - NaN can be stored in DecimalField but cannot be retrieved (accepted) https://code.djangoproject.com/ticket/33955 - AttributeError in admindocs ViewDetailView (accepted) https://code.djangoproject.com/ticket/33941 - AutoField -> BigAutoField causes PostgreSQL sequence value changes (fixed) https://code.djangoproject.com/ticket/33956 - timesince filter localization doesn't work for ru-RU (invalid) https://code.djangoproject.com/ticket/33957 - The "Save and ..." buttons in the admin panel stopped working (duplicate) *Reviewed/committed: * https://github.com/django/django/pull/15949 - Fixed #33916 -- Added support for serialization of enum.Flag in migrations. https://github.com/django/django/pull/15982 - Refs #18707 -- Corrected django.test.Client signature in docs. https://github.com/django/django/pull/15991 - Fixed #33830 -- Fixed VariableDoesNotExist when rendering ClearableFileInput. https://github.com/django/django/pull/15973 - Fixed #33938 -- Fixed migration crash for m2m with a through model in another app. https://github.com/django/django/pull/15993 - Fixed #33953 -- Reverted "Fixed #33201 -- Made RenameModel operation a noop for models with db_table." https://github.com/django/django/pull/15969 - Fixed #33928 -- Avoided unnecessary queries when cascade updating. https://github.com/django/django/pull/15995 - Fixed #33952 -- Reallowed creating reverse foreign key managers on unsaved instances. https://github.com/django/django/pull/16002 - Fixed #33954 -- Prevented models.DecimalField from accepting NaN, Inf, and -Inf values. *Reviewed: * https://github.com/django/django/pull/15992 - Fixed #24179 -- Added filtering to selected side of vertical/horizontal filters. *Authored: * https://github.com/django/django/pull/16000 - Refs #30511 -- Updated docs about auto-incrementing primary keys on PostgreSQL. Best, Mariusz -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2901073c-484e-467c-8f81-7c1318258ddcn%40googlegroups.com.
Re: Fellow Reports - August 2022
Week ending August 21, 2022 *Triaged: * https://code.djangoproject.com/ticket/33925 - Testing tools Management Commands example fails (invalid) https://code.djangoproject.com/ticket/33916 - Support for serialization of combination of Enum flags. (accepted) https://code.djangoproject.com/ticket/28405 - CICharField on a ModelFormSet doesn't catch unique constraint violations with different capitalization (duplicate) https://code.djangoproject.com/ticket/33927 - Rendering a read-only ArrayField with choices crashes. (accepted) https://code.djangoproject.com/ticket/28861 - Add schema tests for CIText fields (invalid) https://code.djangoproject.com/ticket/33929 - Field Reference in FilteredRelation Does Not Recognize Previously Defined FilteredRelation (duplicate) https://code.djangoproject.com/ticket/33930 - Add id="deleted-objects" to template admin/delete_confirmation.html (accepted) https://code.djangoproject.com/ticket/28806 - Mechanism of fetching related objects violates READ COMMITTED assumption of Django ORM (wontfix) https://code.djangoproject.com/ticket/33932 - Altering AutoFields with renaming a column crashes on PostgreSQL. (accepted) https://code.djangoproject.com/ticket/33933 - Cannot use GeoIP2 without setting up gdal anymore (duplicate) https://code.djangoproject.com/ticket/33935 - Support unaccent function in JSONField values (duplicate) https://code.djangoproject.com/ticket/33936 - BaseModelForm.save() ValueError lacks useful information (duplicate) *Reviewed/committed: * https://github.com/django/django/pull/15959 - Fixed #33901 -- Skipped varchar_pattern_ops/text_pattern_ops index creation when db_collation is set. https://github.com/django/django/pull/15922 - Refs #28333 -- Added partial support for filtering against window functions. https://github.com/django/django/pull/15957 - Fixed #26780 -- Added prefetch_related() support for sliced queries. https://github.com/django/django/pull/15954 - Fixed #33778 -- Updated build-system configuration. https://github.com/django/django/pull/15961 - Fixed #33909 -- Corrected django.dispatch.receiver() signature. https://github.com/django/django/pull/15964 - Fixed #33932 -- Fixed altering AutoFields to OneToOneField on PostgreSQL. https://github.com/django/django/pull/15967 - Fixed #33930 -- Eased customization of delete_confirmation.html template in the admin. https://github.com/django/django/pull/15966 - Used CSS flex for admin's submit row. *Authored: * https://github.com/django/django/pull/15970 - Refs #26511 -- Fixed KeyTextTransform() on MySQL. Best, Mariusz -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/90cf6360-8516-4f0e-a6e2-847e99cd014bn%40googlegroups.com.
Re: modelform_factory and __module__ name
That helps, thanks. I don't think it's worth it either, because, ultimately, it'll still be "wrong". The right __module__ is wherever you called modelform_factory from. The perils of meta programming... On Monday, August 29, 2022 at 11:33:50 AM UTC+2 j.bre...@netzkolchose.de wrote: > Looks to me like being carried forward from the very first metaclass > ``MediaDefiningClass``, which happens to be defined in > django.forms.widgets. > > Should be fixable by explicitly adding a __module__ notion to type(). > > Not sure though if it is worth additional code just for the sake of > pretty __module__ alignment. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/f92a5960-eb09-4bdc-9788-6e7fc51f56d1n%40googlegroups.com.
Re: modelform_factory and __module__ name
Looks to me like being carried forward from the very first metaclass ``MediaDefiningClass``, which happens to be defined in django.forms.widgets. Should be fixable by explicitly adding a __module__ notion to type(). Not sure though if it is worth additional code just for the sake of pretty __module__ alignment. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/e92af240-bca0-7144-7fd6-1613ee5c5e9d%40netzkolchose.de.
modelform_factory and __module__ name
Hi all, Not quite sure if this is the right forum, but it concerns Django itself and static analysis of it. I'm working heavily on static analysis of the Django code base, including mypy and Django-stubs. For the life of me, I cannot figure out why the class returned by modelform_factory has "django.forms.widgets" as its __module__. I can see it having "django.forms.models" or the like, but the former makes no sense. It's not a huge issue, as ultimately dynamic classes will have localized module names but it's been bugging me for a while. Give it a try in a plain Django installation: model passed to modelform_factory and inspect the module name. Best, Silvio -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6db415e1-1abb-4f62-9658-3c57298555dfn%40googlegroups.com.
Re: Change `to_python` and `to_url` to be class methods on path converters
Thank you for your response!
> [...] Keeping responsibilities separate ("convert slugs to/from URL's"
versus "be a slug") is a generally desirable property. [...]
While I do agree with you, I'm kind of wondering if it's desirable that
Django enforces how and when the responsibilities are kept separate.
Couldn't that be something left for the developer to decide?
In my case it happens to almost look like copying rather than keeping
responsibilities separate, i.e. the opposite of the DRY principle.
> This change would also complicate the URL parsing process: it would need
to check whether the methods are class or instance level, and instantiate
the converter or not. We wouldn't want to force all converters to move to
use classmethods as that would be a backwards incompatible change,
requiring a deprecation cycle.
I was kind of aware of that, but more of wondering if it you saw it worth
to deprecate the non-classmethod interface in favor of one expecting
classmethods. But I understand that it's barely any gain for the amount of
work it involves.
---
In any case, I realised that it's actually currently possible to implement
these 2 methods as classmethods, if I wrap the registration in a
lambda/callable. e.g.
```
register_converter(lambda: Slug, "my-slug")
```
/Petter
torsdag 25 augusti 2022 kl. 09:58:50 UTC+2 skrev Adam Johnson:
> I can see the appeal of allowing you to have fewer classes, but I don't
> think that's a good thing in itself. Keeping responsibilities separate
> ("convert slugs to/from URL's" versus "be a slug") is a generally desirable
> property.
>
> This change would also complicate the URL parsing process: it would need
> to check whether the methods are class or instance level, and instantiate
> the converter or not. We wouldn't want to force all converters to move to
> use classmethods as that would be a backwards incompatible change,
> requiring a deprecation cycle.
>
> On Wed, Aug 24, 2022 at 7:35 PM Petter friberg
> wrote:
>
>> Hi,
>>
>> I ran in to the situation of wanting `to_python` and `to_url` be
>> decorated with `@classmethod` to avoid having to declare an additional
>> (kind of no-op) class with those 2 methods.
>>
>> Given that I have a couple of custom python data structures that can be
>> encoded into path params, it would be slightly more cleaner if my custom
>> class(es) would be the ones declaring `def to_python` and `def to_url` to
>> comply with the path converter interface. Rather than having some
>> additional `class Converter`.
>>
>> Below follows an invented example, where I pretend to have some product
>> slug composed of a slugged name and integer code. Imagine seeing something
>> like “white-socks-123456789” in a URL.
>>
>> ```
>> class Slug:
>> regex = r".+"
>>
>> def __init__(self, slugged_name, sku):
>> self.slugged_name = slugged_name
>> self.sku = sku
>>
>> @classmethod
>> def to_python(cls, value):
>> name, _, sku = value.rpartition("-")
>> if not name:
>> raise ValueError("invalid name segment")
>>
>> try:
>> sku = int(sku)
>> except ValueError as exc:
>> raise ValueError("sku needs to be a number") from exc
>>
>> return cls(name, sku)
>>
>> @classmethod
>> def to_url(cls, slug):
>> return f"{slug.slugged_name}-{slug.sku}"
>>
>>
>> register_converter(Slug, "my-slug")
>> ```
>>
>> Could changing the converter interface be something to consider?
>> At least I couldn’t see any obvious problems with expecting these 2
>> methods as `@classmethod` (or even `@staticmethod`?) instead. But I could
>> very well be missing something.
>>
>> Thanks!
>> Petter
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-develop...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/a43092e4-34a1-403a-beef-a2c4cac710ebn%40googlegroups.com
>>
>>
>> .
>>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/9bc4c604-743e-4dbb-b2b1-9d971fa2ceb6n%40googlegroups.com.
