131–140 of 184 posts
I understand that Flask has become popular because it is easy to learn, but my experience is that as your knowledge progresses it just keeps getting in your way. I particularly dislike some design choices which look like afterthought hacks, such as global variables for current request and using abort() functions instead of raising exceptions directly. EDIT: To avoid hollow naysaying, here are some alternatives to Fla…
I'm someone who quit web programming in around 2008 while IE6 was still a thing. I used to write PHP without a framework. As someone just getting back into it, Django and Flask or downright magical. I can do so much so quickly that would have taken days to do before. With Flask-RESTful you can turn some code into a microservice in about 10 minutes.
For me, this is what makes these libraries great, not that they will fit every need of every app ever.
Earlier quoted context omitted.
> Flask has a stigma for not being that good when building larger apps Not sure how to quantify that "large" but I've worked on some api backend services written in Flask with a quarter million lines of python code and not feeling "outgrowing" Flask. Granted, it took some good design and effort to make all piece s work together. These days, horizontally scale apps is the way to go.
In my experience, Django is less suitable for large projects than Flask. The nature of Django encourages tight coupling between unrelated parts of the system - Models intertwine database operations and business logic, ModelViews intertwine db operations, business logic and the interface layer. This is manageable in the small, but when you hit scale, this tight coupling adds a whole bunch of unnecessary complexity to…
That being said when you are careful you can probably end up with reasonably structured applications in either Django, Pyramid or Flask.
Newly released version of PyPi is built in Pyramid.
Earlier quoted context omitted.
> Any articles or blog posts you can recommend to give some examples or comparison? Not really sorry, it's all personal experience. > I'm happy with the python ecosystem and have yet to find a django only module where no other alternative exist. What about all the cases where you need support from database schemas? For example let's say you want to have access to Stripe subscriptions from Python and cache them to you…
> For example let's say you want to have access to Stripe subscriptions from Python I will use the official stripe flask checkout example[0]. > and cache them to your database, you'll need something like dj-stripe. There's nothing "in Python" other than an API client because the Python stdlib doesn't have a model ORM. With their OpenAPI definitions[1] to create the needed sqla model boilerplate, which creates the nee…
Ok, so let's say someone else wants to apply this pattern (it's extremely common after all). Should they do the same thing as you did?
Should the next guy as well? Where does it stop? At some point, you write a library right?
Well that library will end up containing the ORM models. So your choice ends up being between "I will roll my own models" (whether they're autogen'd from openapi or not doesn't matter) and "I will use someone else's models". You're back at exactly the same point as earlier, none of this actually achieved anything, other than give you extra work.
The point I was trying to originally make is that saying you'll do it "in pure Python" instead of "in Django" doesn't actually work. If by "Python" you mean "SQLAlchemy" that makes more sense.
At the end of the day, I wish the Django ORM were ripped out of Django so we could have libraries that depend on Django's ORM without them depending on the entire Django stack. There's also a lot of demand for the other side of this, which is having Django's ORM be replaceable by SQLAlchemy. Then you're no longer talking about "Django vs Flask", but "djangorm vs sqlalchemy".
The final step after this would be to have the Django ORM support SQLAlchemy's model declarations. The Django and SQLA model declarations are already very similar. Then we live in a world where you can swap out the ORM API at the application layer, but have libraries that are compatible with both and don't need to be reimplemented for both Django and SQLAlchemy. (I strongly believe the distinction between the two model APIs is not useful right now due to how similar they are)
This is epic. In theory now from V1 onwards it should be easier to convince people at big serious corps to use Flask as it cuts down a lot of Django bloat especially for smaller applications, microservices and other nimble backends.
What's your application server setup like? Is there a standard for this? I tried using UWSGI and Gunicorn with varied results. It was just a pain to setup. I hope things have improved.
Earlier quoted context omitted.
Did you ever attempt to use PyPy? Flask works with it, and in my experience the handful of times I've needed Python to be more performant, PyPy got me there easily. My use-case was I was doing a heavy part of an ETL pipeline out of MySQL and it was taking an unreasonable amount of time. PyPy was a roughly ~8x speedup, which ended up being faster than doing direct manipulation with MySQL via the cli (!!!).
For interest sake, can SQLAlchemy run on PyPy; pgsql driver support? thanks,
Earlier quoted context omitted.
I thought what the parent comment meant was that there's little to no magic in Flask compared to some macro-framework like Django/Spring. Can you get any more explicit than Flask and still be called a framework, without hitting the socket levels?
There's a bit of magic in Flask - the global object is an example.
Earlier quoted context omitted.
In my experience, Django is less suitable for large projects than Flask. The nature of Django encourages tight coupling between unrelated parts of the system - Models intertwine database operations and business logic, ModelViews intertwine db operations, business logic and the interface layer. This is manageable in the small, but when you hit scale, this tight coupling adds a whole bunch of unnecessary complexity to…
Might want to tell instagram https://m.youtube.com/watch?v=lx5WQjXLlq8
Earlier quoted context omitted.
There's a bit of magic in Flask - the global object is an example.
This one trips up every podcast host and blogger. It is not a global object, it just pretends to be with some wrapper magic. Like an attribute method it is not a simple variable.
Earlier quoted context omitted.
> For example let's say you want to have access to Stripe subscriptions from Python I will use the official stripe flask checkout example[0]. > and cache them to your database, you'll need something like dj-stripe. There's nothing "in Python" other than an API client because the Python stdlib doesn't have a model ORM. With their OpenAPI definitions[1] to create the needed sqla model boilerplate, which creates the nee…
> I will use the official stripe flask checkout example[0]. [...] to create the needed sqla model boilerplate, which creates the needed pgsql tables Ok, so let's say someone else wants to apply this pattern (it's extremely common after all). Should they do the same thing as you did? Should the next guy as well? Where does it stop? At some point, you write a library right? Well that library will end up containing the…
They can, I recommend they look at the swagger-codegen[0] api stub templates. There clients as well.
[0]: https://github.com/swagger-api/swagger-codegen/tree/master/m...
> At some point, you write a library right?
Normally a flask-ext forms around a established python library. Yes now we are back at the tight integration problem, but at-least your knowledge of the py library will not be lost in another eco-system.
> I wish the Django ORM were ripped out of Django so we could have libraries that depend on Django's ORM without them depending on the entire Django stack... Django ORM support SQLAlchemy's model declarations... Then we live in a world where you can swap out the ORM API at the application layer, but have libraries that are compatible with both and don't need to be reimplemented for both Django and SQLAlchemy.
Amen Brother!