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

21–30 of 78 posts

Re: Discover Flask

#21

Post by rockyearth »

ergo14 wrote: post #18
level09 wrote: post #16

Great job. I recommend Flask to everyone who wants a clean and modern framework that is simple to use and manage/deploy. I'm also planning to write a series on how to build a simple SAAS with flask, hope some will find that interesting.

Flask is using globals everywhere, and for very long time did not support Python 3.x.

Although most of the methods are globally bound to the current request, Flask is thread safe and I can't see any problem with it. (except that it encourages beginners to use globals, which might be process and thread-unsafe).

Re: Discover Flask

#22

Post by ryannevius »

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 get me wrong; I love Flask. It launched me into web development with Python at a time when Django only confused me. But I just can't justify using Flask for a big project anymore when Django is just so much faster to work with (for me). If I need to, I can customize nearly any part of Django I want, store it as a project template, and use `django-admin startproject myproject --template="https://sometemplate.com/in/a/git/repo.git" ` to start a new project with it.

Re: Discover Flask

#23

Post by auvrw »

devishard wrote: post #12
icpmacdo wrote: post #8

Earlier quoted context omitted.

Any experience with meteor vs flask and if its worth going through one or the other these days. Flask seems better hooked up to Postgres than meteor and having weird stuff with mongo but I'm still new to backend.

I would choose Flask over Meteor any day. JavaScript is the unholy union of various browsers introducing hacks which are then standardized by committee. Considering that's the design process, it actually is pretty well done. But there's no reason to inflict JavaScript on yourself when you can use a language with a coherent design. I haven't used meteor, but I have used a few other JS frameworks and libraries on the b…

reframing the question to "python vs. node" on the server-side, the answer seems very dependent on the use-case. there's not (to my knowledge?) much agreement in the python community about how to compile to javascript, much less regarding an ecosystem of client-side libraries. if a rich client-side that shares logic with the server-side is part of the story, i don't think python is a good choice. i wonder if the Django project could do anything a/b this or if it's too big a chunk to bite off?

all that aside, i like Flask a whole lot. Proxy objects are brilliant, and i wouldn't be surprised if koa.js was partially influenced by Flask. i'm considering going back and fiddling w/ Sinatra for the project after next as i'm given to understand that it was a partial inspiration for Flask's routing.

all in all, there's a lot of cross-pollination. i suppose jquery + html -> frontend framework (angular, marionette, etc.) -> express.js + sequelize/bookshelf -> Flask + SQLAlchemy would be a pretty smooth transition w/ lots of docs, stack overflow, community, and sample code to help out.

Re: Discover Flask

#24

Post by veeti »

rockyearth wrote: post #21
ergo14 wrote: post #18

Earlier quoted context omitted.

Flask is using globals everywhere, and for very long time did not support Python 3.x.

Although most of the methods are globally bound to the current request, Flask is thread safe and I can't see any problem with it. (except that it encourages beginners to use globals, which might be process and thread-unsafe).

I really don't see any benefit or sense in the Flask way of exposing request state through imported globals. It makes testing of views unnecessarily complex: you have to either patch the import or set up the thread local context in every test. And like you mentioned, it encourages unnecessary coupling.

It would be so much simpler to just have a request argument passed to each view.

Re: Discover Flask

#25

Post by MichaelBurge »

lrem wrote: post #17
devishard wrote: post #10

Earlier quoted context omitted.

Python 2.7 will be around for a while due to legacy code, but it's only a matter of time before Python 3.x is more widely used. Don't invest time learning skills that will only dwindle in value. Some stuff is broken in the ecosystem. That's true of all ecosystems. If you're coming from the JS world it's far, far better. But if you are importing every 0.x versioned library that vaguely solves a problem close to your p…

> Python is a solid choice of language for the back ends of web applications. With caution advised when it comes to scaling. You might, or might not, pay a pretty hefty premium in the amount of hardware needed.

You can always rewrite it if needed. A tactical rewrite of specific heavily-used routes that cuts out unnecessary abstractions often doesn't take too long and gets most of the benefit.

I can't see even a slow interpreted language being unable to process 100 requests/second. That leaves like 40 million clock cycles per request. Especially since they tend to come with built-in bytecode compilers, and most of the pure algorithmic code is written in C. Most web requests just don't take that much work to answer.

Most performance issues I see with web applications are somebody writing ORMTable->find(x) in a loop or the equivalent, and then papering it over with a cache(or 3). Or memory leaks. Or badly-written SQL queries(no index, too many indices, disabling seq scans, using CTEs to elegantly 'refactor' SQL, etc.). Or doing blocking calculations/service requests as part of the original web request. The underlying language is almost never what's holding them back.

Re: Discover Flask

#26

Post by nawitus »

ianamartin wrote: post #19
lrem wrote: post #17

Earlier quoted context omitted.

> Python is a solid choice of language for the back ends of web applications. With caution advised when it comes to scaling. You might, or might not, pay a pretty hefty premium in the amount of hardware needed.

I don't want to come across as a Python zealot here, but in my experience, Python has almost never been the problem in scaling. Certainly not to the extent where I would say that it costs a premium in hardware. Though, I suppose it depends on the application. My experience has been that Python will give you more than enough rope to hang yourself with, and lots of apps that are meant to scale have some homegrown crap…

> Run one instance of your app per core you have available and use IPTables to round robin (or whatever. you can get fancier if you feel like it) to each app instance.

But if you're using Flask and you have 4 cores with 4 instances, and you're making 4 database requests at the same time you're whole application is suddenly locked. And it's not uncommon for a single view to make up to 4 separate database requests. Most modern web applications are I/O bound, therefore a single Node.js process would have better performance here.

Re: Discover Flask

#27

Post by bliti »

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…

I work with both Django and Flask too. The difference is that with Flask you have the flexibility of doing things your way. Useful for systems that don't fit the typical CRUD architecture.

Re: Discover Flask

#28

Post by nawitus »

devishard wrote: post #12
icpmacdo wrote: post #8

Earlier quoted context omitted.

Any experience with meteor vs flask and if its worth going through one or the other these days. Flask seems better hooked up to Postgres than meteor and having weird stuff with mongo but I'm still new to backend.

I would choose Flask over Meteor any day. JavaScript is the unholy union of various browsers introducing hacks which are then standardized by committee. Considering that's the design process, it actually is pretty well done. But there's no reason to inflict JavaScript on yourself when you can use a language with a coherent design. I haven't used meteor, but I have used a few other JS frameworks and libraries on the b…

> But there's no reason to inflict JavaScript on yourself when you can use a language with a coherent design.

JavaScript has a coherent design specially if you're using ES6+ in strict mode with a linter. Modern JavaScript is a great language, and comparable to Python.

Re: Discover Flask

#29

Post by Ao7bei3s »

veeti wrote: post #24
rockyearth wrote: post #21

Earlier quoted context omitted.

Although most of the methods are globally bound to the current request, Flask is thread safe and I can't see any problem with it. (except that it encourages beginners to use globals, which might be process and thread-unsafe).

I really don't see any benefit or sense in the Flask way of exposing request state through imported globals. It makes testing of views unnecessarily complex: you have to either patch the import or set up the thread local context in every test. And like you mentioned, it encourages unnecessary coupling. It would be so much simpler to just have a request argument passed to each view.

But then you have to explicitly pass the context to everything you call.

Dynamic scoping would solve this problem (and similar problems, like dependency injection), but Python doesn't have that.

Flasks way emulates it as well as possible.

Re: Discover Flask

#30

Post by ianamartin »

nawitus wrote: post #26
ianamartin wrote: post #19

Earlier quoted context omitted.

I don't want to come across as a Python zealot here, but in my experience, Python has almost never been the problem in scaling. Certainly not to the extent where I would say that it costs a premium in hardware. Though, I suppose it depends on the application. My experience has been that Python will give you more than enough rope to hang yourself with, and lots of apps that are meant to scale have some homegrown crap…

> Run one instance of your app per core you have available and use IPTables to round robin (or whatever. you can get fancier if you feel like it) to each app instance. But if you're using Flask and you have 4 cores with 4 instances, and you're making 4 database requests at the same time you're whole application is suddenly locked. And it's not uncommon for a single view to make up to 4 separate database requests. Mos…

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 you stick your sessions, there's no problem with a database lock.

Post reply on HN