6 ms·

I don't know anything of flask or python really. Is Flask in python 2 or 3? Do I go learn python 2.7 right now or Python 3? Is stuff broken the the eco system.

I don't know anything of flask or python really. Is Flask in python 2 or 3? Do I go learn python 2.7 right now or Python 3? Is stuff broken the the eco system. Does it make sense moving over from JavaScript for easier backend CRUD'ish app's? Thanks HN.

cyphar 11y ago
You can use Flask with either Python 2 or Python 3. I personally use Python 3 for everything, so I can't comment on packages that don't work in Python 2.
- icpmacdo 11y ago
  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.
  - devishard 11y ago
    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 backend. My major criticisms of JS on the back end are: they like magic, in that they tend to decouple code to the point that there's no way to trace the code. Instead, pieces are structured and tied together by convention, i.e. thingController goes with thingModel, and stuffController goes with stuffModel. It creates terse code, but a) if you need to do anything slightly unique (and you will) you're screwed, b) it's a huge pain to debug and trace because you can't just read function calls, and c) since the JS world doesn't care about reverse compatibility, you have to always know when the convention changes, and if you fall a few versions behind, you're basically stuck there. In particular, Ember.JS gave me PTSD. Meteor may avoid some of these issues, but when I evaluated it a while back it didn't seem like it did.
    - auvrw 11y ago
      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.
      - devishard 11y ago
        I don't think many python devs are espousing Python for the client side. I use react/underscore/Jasmine/sinon with ES6 run through Babelify for the client side. Sharing logic between client and server side means that your client and server side don't have clearly-defined responsibilities. The one exception to this might be input syntax validation, but generally that's a place where you don't want to roll your own anyway.
        auvrw 11y ago
        idk, could imagine wanting computation to run on the client when it's a desktop (to save server cycles) or the server when it's mobile (to save battery)... not a level of optimization i practically run into, but not an unreasonable example. i guess a better thing to say is "exactly": specs often change and responsibility gets shifted around. so "runs everywhere" can be useful, whether it be js or otherwise.
        devishard 11y ago
  - deleted 11y ago
    [deleted]
devishard 11y ago
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 problem, no ecosystem will save you. Python is a solid choice of language for the back ends of web applications.
- lrem 11y ago
  > 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.
  - ianamartin 11y ago
    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 of an architecture, or people try to get fancy when they don't need to and try to write go or scala in Python. If you have a clear understanding of your data model, Python backends scale quite well vertically. 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. Boom. You are now banging on all 4 or 8 or however many cores your server has without the context switch overhead of the multiprocessing module and also without the headaches that go along with the shared memory space of the multithreading libs. Not to mention cleaner, nicer code. If you build your product to work well in this way, then scaling horizontally also becomes a non-issue as far as Python code is concerned. You just put haproxy in front of multiple machines, set up health checks, and for the vast majority of use cases, you're done until you need to scale the storage horizontally. Then you have some serious decisions to make. But that's a different topic. But back to my original point: every case where I've seen Python being all slow has really been an artifact of a crap architecture, or bolting on crap front end frameworks, or depending too much on an ORM like SQLAlchemy without really understanding your data and depending on it to do everything for you instead of thinking rationally about what your data is. Or some combination of all three above. Yes, I know that there are languages that execute much faster than Python. I work with C#/.NET/SQL Server almost as much as I use the Python/Pyramid/PostgreSQL stack. I can write a crappy, slow, messy architecture on either stack. And in fact, when I was first getting to know C# and still writing Python code in that language, I did that. The bottom line is that if you understand the strengths, weaknesses, and idioms of the language you are working with right now, almost every high-level language in common use today is sufficient for massive-scale deployments for the most common types of web apps. Heavy computing or scientific purposes obviously excepted. But most web apps that scale to hundreds of millions of users are basically "window-on-data" type applications. I can't really think of a case where some other language besides Python would be noticeably cheaper hardware-wise. Maybe you have to know your entire stack a bit better if you want scalable Python apps, maybe you have to do a little more Jiggery-Pokery with your Linux servers, but if you are serving at massive scale, you are going to have to go there anyway, especially when you start dealing with storage. That's part of the game.
tedmiston 11y ago
Most people will tell you they're using 2.7 in production.
- dorfsmay 11y ago
  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.
  - drdaeman 11y ago
    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.)
    - dorfsmay 11y ago
      This used to be an issue, but, in the past 2 years pretty much all the most used libraries have added a python 3 version.
      - tedmiston 11y ago
        I wish I could say this about our dependencies but it's not quite true yet. I do run our requirements.txt through https://caniusepython3.com https://caniusepython3.com every few months though.
  - tedmiston 11y ago
    There are a good amount of dependencies that haven't been ported to 3 yet. Using one of these directly, or as a secondary dependency, is the reason running 3 in prod is impractical for many of us. http://py3readiness.org/ http://py3readiness.org/

cyphar 11y ago

You can use Flask with either Python 2 or Python 3. I personally use Python 3 for everything, so I can't comment on packages that don't work in Python 2.

icpmacdo 11y ago
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.
- devishard 11y ago
  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 backend. My major criticisms of JS on the back end are: they like magic, in that they tend to decouple code to the point that there's no way to trace the code. Instead, pieces are structured and tied together by convention, i.e. thingController goes with thingModel, and stuffController goes with stuffModel. It creates terse code, but a) if you need to do anything slightly unique (and you will) you're screwed, b) it's a huge pain to debug and trace because you can't just read function calls, and c) since the JS world doesn't care about reverse compatibility, you have to always know when the convention changes, and if you fall a few versions behind, you're basically stuck there. In particular, Ember.JS gave me PTSD. Meteor may avoid some of these issues, but when I evaluated it a while back it didn't seem like it did.
  - auvrw 11y ago
    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.
    - devishard 11y ago
      I don't think many python devs are espousing Python for the client side. I use react/underscore/Jasmine/sinon with ES6 run through Babelify for the client side. Sharing logic between client and server side means that your client and server side don't have clearly-defined responsibilities. The one exception to this might be input syntax validation, but generally that's a place where you don't want to roll your own anyway.
      - auvrw 11y ago
        idk, could imagine wanting computation to run on the client when it's a desktop (to save server cycles) or the server when it's mobile (to save battery)... not a level of optimization i practically run into, but not an unreasonable example. i guess a better thing to say is "exactly": specs often change and responsibility gets shifted around. so "runs everywhere" can be useful, whether it be js or otherwise.
        devishard 11y ago
- deleted 11y ago
  [deleted]

devishard 11y ago

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 problem, no ecosystem will save you. Python is a solid choice of language for the back ends of web applications.

lrem 11y ago
> 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.
- ianamartin 11y ago
  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 of an architecture, or people try to get fancy when they don't need to and try to write go or scala in Python. If you have a clear understanding of your data model, Python backends scale quite well vertically. 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. Boom. You are now banging on all 4 or 8 or however many cores your server has without the context switch overhead of the multiprocessing module and also without the headaches that go along with the shared memory space of the multithreading libs. Not to mention cleaner, nicer code. If you build your product to work well in this way, then scaling horizontally also becomes a non-issue as far as Python code is concerned. You just put haproxy in front of multiple machines, set up health checks, and for the vast majority of use cases, you're done until you need to scale the storage horizontally. Then you have some serious decisions to make. But that's a different topic. But back to my original point: every case where I've seen Python being all slow has really been an artifact of a crap architecture, or bolting on crap front end frameworks, or depending too much on an ORM like SQLAlchemy without really understanding your data and depending on it to do everything for you instead of thinking rationally about what your data is. Or some combination of all three above. Yes, I know that there are languages that execute much faster than Python. I work with C#/.NET/SQL Server almost as much as I use the Python/Pyramid/PostgreSQL stack. I can write a crappy, slow, messy architecture on either stack. And in fact, when I was first getting to know C# and still writing Python code in that language, I did that. The bottom line is that if you understand the strengths, weaknesses, and idioms of the language you are working with right now, almost every high-level language in common use today is sufficient for massive-scale deployments for the most common types of web apps. Heavy computing or scientific purposes obviously excepted. But most web apps that scale to hundreds of millions of users are basically "window-on-data" type applications. I can't really think of a case where some other language besides Python would be noticeably cheaper hardware-wise. Maybe you have to know your entire stack a bit better if you want scalable Python apps, maybe you have to do a little more Jiggery-Pokery with your Linux servers, but if you are serving at massive scale, you are going to have to go there anyway, especially when you start dealing with storage. That's part of the game.

tedmiston 11y ago

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

dorfsmay 11y ago
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.
- drdaeman 11y ago
  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.)
  - dorfsmay 11y ago
    This used to be an issue, but, in the past 2 years pretty much all the most used libraries have added a python 3 version.
    - tedmiston 11y ago
      I wish I could say this about our dependencies but it's not quite true yet. I do run our requirements.txt through https://caniusepython3.com https://caniusepython3.com every few months though.
- tedmiston 11y ago
  There are a good amount of dependencies that haven't been ported to 3 yet. Using one of these directly, or as a secondary dependency, is the reason running 3 in prod is impractical for many of us. http://py3readiness.org/ http://py3readiness.org/