> Flask is very easy and simple. It's fun to put a few endpoints in a single file. However when your application starts growing into an endless of endpoints, tons of models and views, or your team is having more people, it is very necessary to have some sort of structure in your application.
How is this different than the typical Blueprints setup? My Flask applications are split into modules, each with its own Blueprint; this helps organize large projects.
CakePHP does the same routing by naming convention, and I can't stand it. Forcing you to name your functions based on the url is horribly inflexible and has bit me in the ass before. There are sloppy ways around it such as modifying .htaccess, but it leads to an inconsistent codebase where either only some routes are done the way the framework intends, or all routes are done an entirely different way.
I've been instructed to add endpoints with a specific URL, but the corresponding naming requirements for routing was already taken by another method that was heavily used throughout the application. So either tell marketing that won't work because of technical reasons (which doesn't go over so well), or re-name a bunch of perfectly good code because the framework is inflexible.
Yep. Maybe not true, but also sounds too much for me like object-orientation is the saviour to all structural problems, and by just using it all these issues will go away.
No, that is not the case, practice taught us now for years it can even become the opposite; heck why are universities still teaching this without questioning :(
No programming paridigm will solve every problem well. And plnety of problems are easy enough that any paradigm will solve them well enough.
The author is simply offering one solution to a particular problem from one paradigm. Plus it's python so it mixes and matches with functional programming more than most.
I don't think it's a case of seeing everything through a beginner's lens of "freshman level object-orient all the things".
I thought the whole idea of Flask was to keep it simple. Reduce the amount of boilerplateing and potentially "useless" features of other frameworks, i.e. Django + DRF. For what I've seen so far, it looks like you've put the Django + DRF features on top of Flask.
My question would be, why should I use Assemby instead of Django + DRF?
Instead of shitting on Flask (which is in fact great as-is and nicely suited to large projects via Blueprints), why not just build your own web framework and try to get support from the community based entirely on the merits of your framework? And I agree with others comments that this project seems to be adding mostly a bunch of magic Django-esque contraptions to the code, which I very deliberately choose Flask to avoid.
Indeed, it's surprising that someone is building today a framework in Python that is not async, when it's pretty easy to do so (compared to eg. the twisted days, but even to pre3.6 days).
That's an odd assertion. What kind of things do you think most projects do? I'd say most projects have network IO happening (querying databases, storing data to e.g. S3, communicating with other web services), in which case async absolutely is helpful and far more performant.
This phrasing turned me off. In the USA there are political connotations such that to over half the population, the meaning of 'making great again' is the exact opposite.
Probably another case of code that is published, but never executed. The first block of code on the tutorials page has the missing def keyword. Feels like a human editing error to me.
If you want a very Object Oriented Python web framework thats actively maintained and older than Django and Flask check out CherryPy. It was the only framework I saw that you just make a class and expose your routed methods and they become end-points. Every other Python framework looked odd to me with all the annotations.
Have used it fot 3+ years in production and its done me well.
Some good ideas here. Similarly, one thing that bugs me about all/most frameworks is that you have to spend a significant amount of time “wiring things up,” ... connecting models to views to the admin.
That should happen automatically in my opinion. I’d like to create a model class in a models folder and have it found, loaded, tied to views, templates, the admin already. Customizable still of course.
Would also like an admin page to download common models like wordpress plugins. Say CMS with comments, roles, history/audit etc. All built to standard interfaces. Why do I have to reinvent this and wire it up every single project?
Also flowers and Trump themes are a weird combo. Especially when Flask is relatively unchanged. The design is either great or not depending on your perspective.
One tip: add a comment to the thread giving the backstory of how you came to work on this, and explaining what's different about it. That tends to seed discussion in a good direction. Good luck!
Literally throwing a dictionary on the floor and pointing would work. Or checking whether the name is being used via a 2-sec google search? People avoid start companies with the same name as other companies -- it's not that hard.
In this case, what about Fett? Flask + (D)jango Fett
It is a terrible name. You can do web dev in pure Assembly and it actually makes sense in contrast with yet another framework over a framework over an interpreter over POSIX-libraries.
E. g. monitoring for mission critical servers. You really don't want the whole stack of unverified goodies on these machines, but since you already have TCP/IP for SSH, writing a simple web-server that reports machine health over HTTP is like a half-day job.
And it's verifiable since it's small. It doesn't drag the whole Python infrastructure with it.
In the context of discussing the library's marketing/presentation I think the the branding is also fair game. It's also a little odd how at the bottom of the page it gives credits to the image as a non-commercial license. Personally I would recommend avoiding any licensed assets in such a project all together (when possible).
But at the end of the day if you build and release an OSS project you should get to do whatever you want with it, like the use of emojis that was discussed in the postwoman.io project that came up last week.
My opinion is who cares, we should be discussing its technical merits first and foremost on a forum like this.
How is this different than the typical Blueprints setup? My Flask applications are split into modules, each with its own Blueprint; this helps organize large projects.