Django specific PyCharm niggles list.

[carltongibson]

Holding area for my PyCharm niggles.

• [ ] Help > Submit Feedback... goes to a blank browser page (likely my blocking extensions) but I don't have the capacity to jump through whatever hoops are there.

[carltongibson]

• [x] New Django template preview should be tied to the Browser buttons.

Update: Looks fixed in 2023.3 EAP 4.

[carltongibson]

• [x] This may be a Neapolitan typing question, but on a Neapolitan CRUDView, self.object is always an optional (but force unwrap in use) instance of the class self.model, not : Model which it's inferred as.

[pauleveritt]

• [ ] New Django template preview should be tied to the Browser buttons.

Can you explain "tied to"? Do you mean, our JCEF preview widget window thingy should have forward/backward buttons?

[carltongibson]

@pauleveritt No, I mean the Safari button just opens the template in the browser. (Which is the issue being fixed by the new previews)

It should open the browser, but with the preview address. So 127.0.0.1:8000/url-from-preview/

If it can't do that I'd hide the buttons totally.

[pauleveritt]

• [x] This may be a Neapolitan typing question, but on a Neapolitan CRUDView, self.object is always an optional (but force unwrap in use) instance of the class self.model, not : Model which it's inferred as.

Pasha noted that you have it annoyed as Model. He added: "One should probably use generics here. If it is even possible to describe using the current type system. Django is notoriously complicated in that regard (hence adhoc support we have)."

[carltongibson]

Pasha noted that you have it annoyed as Model. He added: "One should probably use generics here. If it is even possible to describe using the current type system. Django is notoriously complicated in that regard.

Ah, yes. That's basically where I got to.

I don't mind… well, I would do... adding Generics in the base class but what I'm anti is users having to write, this kind of thing...

class MyModelCRUDView(CRUDView[MyModel]):
      model = MyModel
      object: MyModel

I want the subclass to look like (just:

class MyModelCRUDView(CRUDView):
      model = MyModel

And have self.object then picked up as being a MyModel instance.

... (hence adhoc support we have).

I guess my question is this, is there any way as a library author that I can provide PyCharm with the info it needs here?

(Neapolitan's CRUDView also has a get_urls() method, returning a list of url patterns that I'd love to be able to get picked up by the Endpoints tool.)

[carltongibson]

New Django Structure tool in 2023.3 EAP looks good.

https://blog.jetbrains.com/pycharm/2023/10/2023-3-eap-4/

• [ ] Doesn't look like it picks up Neapolitan views though...

I wonder if this is related to the views not being picked up by the Endpoints tool either? 🤔

If I were trying to build this I would enumerate the urlpatterns. DRF's EndpointEnumerator has code that looks like...

        for pattern in patterns:
            path_regex = prefix + str(pattern.pattern)
            if isinstance(pattern, URLPattern):
                path = self.get_path_from_regex(path_regex)
                callback = pattern.callback
                if self.should_include_endpoint(path, callback):
                    for method in self.get_allowed_methods(callback):
                        endpoint = (path, method, callback)
                        api_endpoints.append(endpoint)

            elif isinstance(pattern, URLResolver):
                nested_endpoints = self.get_api_endpoints(
                    patterns=pattern.url_patterns,
                    prefix=path_regex
                )
                api_endpoints.extend(nested_endpoints)

        return sorted(api_endpoints, key=endpoint_ordering)

... this handles the descent into the include() patterns, which the Endpoint tool doesn't yet handle, and would work with Neapolitan's *MyCRUDView.get_urls() too.

It's hard to know though exactly what info PyCharm is looking for.

[carltongibson]

Looks like the Django Structure works per-app — so if you don't define an app-level urls.py is says "no views", even though they're routed in the root URL conf.

It's pretty common not to use an app-level urls.py

[pauleveritt]

I'm asking internally about "I guess my question is this, is there any way as a library author that I can provide PyCharm with the info it needs here?" ... sorry, was traveling last week.

[carltongibson]

Hey @pauleveritt, no stress! I'm not (at least not currently) at a weeks-level kind of resolution here 😅

My plan was to dump things here, mark them off as they get fixed, and try and resolve as much as I can my end. (e.g. When I get a moment, I will remove the offending Model annotation from Neapolitan that Pasha noted, so at least that's cleaner there...)

If it's useful for you to checkin and use for feedback, that's awesome. (Otherwise I'm not offended if you ignore me 😜)

I was thinking maybe talking with @sarahboyce (slowly, without urgency) would be handy too, (as you'll know what I'm getting at — despite the terrible lack of details — perhaps more directly Sarah).

[pauleveritt]

Unfortunately the point about Neapolitan and endpoints/structure isn't good news: we don't currently have a way for that. Would require a plugin.

[carltongibson]

Grrr. Is that the same for include()d URL patterns?

Above...

If I were trying to build this I would enumerate the urlpatterns...

[carltongibson]

Pasha noted that you have it annoyed as Model. He added: "One should probably use generics here. If it is even possible to describe using the current type system. Django is notoriously complicated in that regard (hence adhoc support we have)."

OK, this issue will be resolved by https://github.com/carltongibson/neapolitan/pull/35 — remove the spurious annotation.

The generic approach doesn't look possible, so it'll need a mypy plugin. (That's also the only way to keep the code you type how I want it to look, so I'll, slowly, investigate that.)

[carltongibson]

Remaining issue here is about the URL/endpoint detection.

The code sketch in https://github.com/carltongibson/notes/issues/27#issuecomment-1785867791 is what I'd look at there.

[pauleveritt]

Ever done a mypy plugin? Curious how painful it is or isn't.

[carltongibson]

Nope. I'm about to find out 😅

[sarahboyce]

Grrr. Is that the same for include()d URL patterns?

Above...

If I were trying to build this I would enumerate the urlpatterns...

I believe I have confirmed this: https://github.com/sarahboyce/PyCharm-Django-test

[sarahboyce]

YouTrack ticket: https://youtrack.jetbrains.com/issue/PY-71314/Django-endpoints-and-views-not-detected-when-added-to-urls-with-include

[carltongibson]

Good work @sarahboyce — I'm pretty convinced that using iter(urlpatterns) on the ROOT_URLCONF is the approach that will work here.

Thanks for doing the extra work here!