Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Discover Flask

discoverflask.com

Post reply on HN
Print view View original

51–60 of 78 posts

Re: Discover Flask

#51

Post by drdaeman »

dorfsmay wrote: post #37
tedmiston wrote: post #32

Earlier quoted context omitted.

Most people will tell you they're using 2.7 in production.

Because of legacy, but these days there is no reason not to use python 3 on new projects. Note that Python 2.x will no longer be supported in 2020.

New projects depends on that legacy - in form of existing libraries. So, one may find themselves writing somewhat more code than they had expected, either as a new libraries or patching the existing ones to work with Python 3.

Well, not that doing so is a bad thing - it's the contrary, esp. if the patch goes to the upstream - but still this may be frustrating to some.

(Most common libraries are actually work pretty well with Python 3. But there are still a lot of stuff PyPI that's Python 2-only at the moment.)

Re: Discover Flask

#52

Post by Beltiras »

siddhant wrote: post #41
ryannevius wrote: post #22

It's interesting (exciting) to see all of the excitement about Python frameworks on HN lately. I've used both Flask and Django extensively, and highly recommend them. I used to be on the Flask "micro-framework" bandwagon...until I realized that almost everything I was integrating into Flask was already included in Django (e.g. a test suite, an ORM, database migrations, authentication, an admin interface, etc.). Don't…

Django is cool, and has been my choice for a fair number of projects. Although recently I had an interesting experience with it when I wanted to use websockets (yes, I know it's not written for that use case). It was stunning that most of the solutions out there rely on some sort of a hack to get it working. I ended up porting over my project to Tornado, because I need websockets for a lot of the features I'm working…

The Django community knows full well that this is a missing feature in modern web development. There was a talk featuring this topic at DUTH this fall. https://opbeat.com/events/duth/#twisted-and-django

Re: Discover Flask

#53

Post by ianamartin »

nawitus wrote: post #50
ianamartin wrote: post #30

Earlier quoted context omitted.

That hasn't been my experience. If your ACLs are set up properly, you won't encounter a full table lock, and therefore won't have problems like you described. I agree that this could be a problem in theory. In practice, it has not been. Again, it boils down to how you architect your code. EDIT: you need to stick your sessions to a specific instance. Otherwise, you are correct that there's a problem. But as long as yo…

I wasn't talking about database locks. My point was that making a database request takes a really long time relative to processing a request in the web application. Therefore the web application spends most of the time doing nothing and waiting for the database request to complete.

So, write data-backed applications without calling a database?

Not sure what you are getting at here.

If you are talking about the raw scalability of your database, yes, you are correct. The speed with which you are able to get info from your DB will be a limiting factor.

But that's a totally different point than the one I was making, which was about how to scale Python, not your database.

If I understand you correctly, the time spent in retrieving stuff from your database will be a limiting factor no matter what language you are using. The DB I/O will eventually limit C# or go or node.js or whatever. I really don't see how this is relevant.

But since you brought it up, you can really cut down on data access times by relying less on ORMs and getting your fingers dirty with stored procedures and building tables that make sense to SQL instead of pretending everything in your RDBMS is a class.

Re: Discover Flask

#54

Post by mixmastamyk »

wcarss wrote: post #47
CuriouslyC wrote: post #45

Earlier quoted context omitted.

This is mostly true if your application is mostly CRUD with HTML endpoints (the use case Django was designed for), particularly very "solved" use cases like blogs. (As an aside, for very crud-heavy applications that are client-heavy with primarily JSON data endpoints, I suggest using PostgREST if possible. It is almost certainly going to be better than any CRUD API you produce yourself) If your application is mostly…

> The main problem I see with flask is that it isn't obvious to people picking up the library the right way to structure and scale an application code base. I wholeheartedly agree! Do you have any resources in mind (even perhaps not specific to flask) that you think would be useful to people hitting that wall?

These came up last week:

https://etscrivner.github.io/posts/2014/10/building-large-fl...

https://news.ycombinator.com/item?id=11121355

Re: Discover Flask

#55

Post by radlad »

lucian1900 wrote: post #44
ryannevius wrote: post #22

It's interesting (exciting) to see all of the excitement about Python frameworks on HN lately. I've used both Flask and Django extensively, and highly recommend them. I used to be on the Flask "micro-framework" bandwagon...until I realized that almost everything I was integrating into Flask was already included in Django (e.g. a test suite, an ORM, database migrations, authentication, an admin interface, etc.). Don't…

If Django replaced their very limited ORM for SQLAlchemy, I'd agree. There are just so many apps that end up requiring queries complex enough that with the Django ORM you have to resort to raw SQL. With SQLAlchemy, you can express any SQL you want without giving up composition.

Why not just use SQLAlchemy with Django and ignore the built-in ORM?

Re: Discover Flask

#56

Post by ivoras »

lucian1900 wrote: post #44
ryannevius wrote: post #22

It's interesting (exciting) to see all of the excitement about Python frameworks on HN lately. I've used both Flask and Django extensively, and highly recommend them. I used to be on the Flask "micro-framework" bandwagon...until I realized that almost everything I was integrating into Flask was already included in Django (e.g. a test suite, an ORM, database migrations, authentication, an admin interface, etc.). Don't…

If Django replaced their very limited ORM for SQLAlchemy, I'd agree. There are just so many apps that end up requiring queries complex enough that with the Django ORM you have to resort to raw SQL. With SQLAlchemy, you can express any SQL you want without giving up composition.

Can you give an example for a thing where with the Django ORM you have to resort to raw SQL?

Re: Discover Flask

#57

Post by collyw »

radlad wrote: post #55
lucian1900 wrote: post #44

Earlier quoted context omitted.

If Django replaced their very limited ORM for SQLAlchemy, I'd agree. There are just so many apps that end up requiring queries complex enough that with the Django ORM you have to resort to raw SQL. With SQLAlchemy, you can express any SQL you want without giving up composition.

Why not just use SQLAlchemy with Django and ignore the built-in ORM?

Because the Admin and other features won't work?

Re: Discover Flask

#58

Post by collyw »

ivoras wrote: post #56
lucian1900 wrote: post #44

Earlier quoted context omitted.

If Django replaced their very limited ORM for SQLAlchemy, I'd agree. There are just so many apps that end up requiring queries complex enough that with the Django ORM you have to resort to raw SQL. With SQLAlchemy, you can express any SQL you want without giving up composition.

Can you give an example for a thing where with the Django ORM you have to resort to raw SQL?

Conditional aggregates were a problem until 1.8 or 1.9. Joins on more that one field would be another.

Re: Discover Flask

#59

Post by jonwayne »

siddhant wrote: post #41
ryannevius wrote: post #22

It's interesting (exciting) to see all of the excitement about Python frameworks on HN lately. I've used both Flask and Django extensively, and highly recommend them. I used to be on the Flask "micro-framework" bandwagon...until I realized that almost everything I was integrating into Flask was already included in Django (e.g. a test suite, an ORM, database migrations, authentication, an admin interface, etc.). Don't…

Django is cool, and has been my choice for a fair number of projects. Although recently I had an interesting experience with it when I wanted to use websockets (yes, I know it's not written for that use case). It was stunning that most of the solutions out there rely on some sort of a hack to get it working. I ended up porting over my project to Tornado, because I need websockets for a lot of the features I'm working…

The whole "WSGI revision" effort is intended to solve the problem of websockets (and HTTP 2.0) across frameworks and servers.

Re: Discover Flask

#60

Post by nawitus »

ianamartin wrote: post #53
nawitus wrote: post #50

Earlier quoted context omitted.

I wasn't talking about database locks. My point was that making a database request takes a really long time relative to processing a request in the web application. Therefore the web application spends most of the time doing nothing and waiting for the database request to complete.

So, write data-backed applications without calling a database? Not sure what you are getting at here. If you are talking about the raw scalability of your database, yes, you are correct. The speed with which you are able to get info from your DB will be a limiting factor. But that's a totally different point than the one I was making, which was about how to scale Python , not your database. If I understand you correc…

Node.js can asynchronously make multiple (i.e. hundreds) database requests without locking the instance.
Post reply on HN