💡 Ideas

[laymonage]

Hey, thanks for creating this package!

I had been sitting on this idea since last year, but I didn't take a stab at this until a few weeks ago. After getting an initial implementation to work, a friend told me that he has previously seen your package and thought that mine has a similar idea (he's right). Congrats on beating me to it!

I looked at your code and I must say that you've handled the edge cases very well! I haven't handled most of them in my implementation.

My approach is a bit different, though. I considered scanning for *.py files and using import_module() as you did, but I discovered Python's pkgutil.walk_packages() function which seemed cool, so I tried using it. For this reason, my implementation heavily depends on treating the files as modules, rather than just Python files. The end result is pretty much the same, though!

---

As I treat the files as modules, I didn't like the idea of naming the modules with <> to support path converters, as that would make the module name invalid (and you can't import it from your code normally). To work around this problem, I allowed users to define the path using a path variable in the module, similar to view.url in your implementation. However, instead of completely overriding the route, it only overrides the path for that level. In addition, descendant paths will automatically use it as their parent path. For example:

# accounts/username/__init__.py
path = "<str:username>"

def dispatch(request, username, *args, **kwargs):
    ...

# accounts/username/media.py

def dispatch(request, username, *args, **kwargs):
    ...

accounts/<str:username>/
accounts/<str:username>/media/

Also, worth noting that walk_packages is still able to find the modules even if you name them with <>, so it can still work.

I also thought about using re_path() if there's a variable e.g. re_path = r"..." in the module, but I haven't fully thought about this yet.

---

I considered a few names for the view function, e.g. default (alluding to export default), index, view, dispatch, etc. In the end, I chose dispatch, drawing inspiration from Django's class-based views.

It's also because I thought of detecting functions that are named after the request method that they handle, e.g. get(), post(), etc., and providing a default dispatch() that wraps those functions, just like how Django's class-based views work. I haven't implemented this, though. Just throwing this here, in case you're interested!

---

That said, I just did this mostly out of curiosity. I don't plan on making it an actual package, as I don't have a real project to test my implementation on, nor do I have the resources to maintain it. So, I really appreciate you taking the time to actually publish this as a package!

Anyway... the other reason why I did this was that I thought it would be an interesting idea for a DjangoCon talk. Unless you also happen to do the same, I'm planning on submitting my idea to DjangoCon Europe this year. If I get selected, I'll be sure to credit you in the talk.

Let me know what you think, and I hope you don't mind!

[jerivas]

Hey, thanks for sharing your ideas! I'm glad I'm not the only one who thought about this.

I think it's hard to strike a balance between the completely file-based approach popularized by frontend frameworks and keeping the code Pythonic (that is avoiding those ugly module names). I like your solution of just supporting the filename conventions but providing the path variable as a escape hatch. I also like the idea of HTTP verbs as functions 👍

Would you be interested in contributing those features? I'd be happy to merge those contributions and hopefully you can share the package as part of your talk (which I also think is a great idea).