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 <petterfribe...@gmail.com>
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 <MyType>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-developers+unsubscr...@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
> <https://groups.google.com/d/msgid/django-developers/a43092e4-34a1-403a-beef-a2c4cac710ebn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAMyDDM3PTv0Bre7aBDWW%3DFx1j3Az2GihPBqJ3tetKjf3cXtVkA%40mail.gmail.com.
