71–78 of 78 posts
Earlier quoted context omitted.
Why not just use SQLAlchemy with Django and ignore the built-in ORM?
Because the Admin and other features won't work?
After that you can use SqlAlechemy as a side channel, just like a lot of people use NoSQL databases.
And here's a link to the Vagrant instance https://github.com/apolloclark/discover-flask-vagrant
Earlier quoted context omitted.
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 Djan…
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 any…
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.
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.
Earlier quoted context omitted.
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 w…
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.
I do run our requirements.txt through https://caniusepython3.com every few months though.
Earlier quoted context omitted.
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.
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/
Then there's a bunch of deployment tools like ansible, fabric, and marionette which don't really need to be python3 compatible for use.
Then there's tools like MySQL-python, python-gflags, python-cjson, INITools, filechunkio, which have python3 compatible alternatives, often in the standard library.
That brings the total up to 331
That leaves basically 3 categories of things left: mozilla tools, database connectors (many of which probably have python3 bindings though I haven't looked), and single sign on tools. Those account for 12 of the remaining 29 libraries.
That's pretty ready.
I've also recently been using Django, and I'd say the biggest advantage of Flask is simplicity.
When you get to something the scale of Django, there's a whole load of decisions and culture baked into the approach, and you have to learn that in order to use it.
For small projects, I'd recommend Flask.
Earlier quoted context omitted.
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 any…
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.
You're forgetting the first rule of optimization: profile.