371–380 of 413 posts
Earlier quoted context omitted.
Why can't your Python 2 services talk to your Python 3 web app?
Why should I maintain code, servers and libs in 2 versions of a backend programming language?
Earlier quoted context omitted.
Just use C++ and your Qt bindings will never go away!
Qt is a point in C++'s favour, but not enough to outweigh the downsides of the language.
Qt's binding support has been it's biggest issue since forever.
Earlier quoted context omitted.
I would bet my horse on https://trypyramid.com/ when it comes to API consistency, I've updated my applications from 0.9 to 1.7 and that was a breeze. Over the years it was exceptionally great experience.
I've been talking to some of the developers on FreeNode about their support of old releases. In particular, related to statements about "Once 1.8 comes out, 1.6 will no longer receive patches". 1.7 came out 9 months ago and 1.8 is in beta. In other words, they don't really have a LTS process. And the developers seem to think this is totally ok. In my experience, anything that doesn't have a commitment to at least fix…
- request/response (webob) gets its own updates.
- templates get their own updates.
- sqlalchemy gets its own updates Etc.
You WILL get security fixes for most of your application even without upgrading the framework itself (the attack surface for pylons/pyramid itself is smaller than monolith).
By being on a lower version you don't really miss much - the API's are very stable. And 99% of time you can update pyramid version itself without risking application breakage (the chance of it is probably a lot lower than with monolithic framework).
I know about very heavy websites that are still using pylons(precursor to pyramid) in production without issues (8 years now).
Earlier quoted context omitted.
I would bet my horse on https://trypyramid.com/ when it comes to API consistency, I've updated my applications from 0.9 to 1.7 and that was a breeze. Over the years it was exceptionally great experience.
My problem with Pyramid (although having never used it in production) is the same as my problem with Flask. They say "Start small, finish big", and push the fact that Pyramid scales from a single file codebase, up to many files. This is something that I just haven't seen in practice. A Django project requires quite a few files, so it's never a great answer when the total amount of business logic is The biggest red fl…
I have a Python 2.7 project that has been running smoothly for many years now and I'm having trouble finding a reason to upgrade to Python 3. The project uses the unicode type to represent all strings, and encodes/decodes as necessary (usually to UTF-8) when doing I/O. I haven't really had any of the Unicode handling problems that people seem to complain about in Python 2. Can someone explain what benefit I would act…
"I have a Python 2.6 project that has been running smoothly, why upgrade to 2.7?" If you don't need any of the new features and fixes, don't, that's perfectly fine.
Earlier quoted context omitted.
There are some major products like Ansible, that are still only compatible with Python 2.7.
Yea, that really annoyed be about Ansible. You have to bootstrap systems like Ubuntu Xenial which only ship Python3 using the raw tasks. As seen with Django, they were able to support both. I've been able to support both with the code base to some of my projects as well. Currently I have one project I'd like to be Python3, but it will involve forking two dependencies (owfs and phidgets) and having them support Py3 (p…
> Ansible 2.2 features a tech preview of Python 3 support.
So they are working on it.
Earlier quoted context omitted.
The Python 2.x EOL was extended to 2020.
Yeah thats 3 years for now... thats very little time - especially if you have to migrate old projects.
1 week is not enough
1 month is not enough
1 year is not enough
5 years is not enough
10 years is not enough
20 years is not enough...
Do you really have Python projects that can't be migrated in 3 years?
At some point the line has to be drawn to move everyone forward. Extending the EOL for the last long-term of 2.7.x by 5 additional years is pretty generous.
Earlier quoted context omitted.
But the Python developers will abandon v2 sooner or later, so IMHO it's wise to start following the bilingual development guidelines https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef and eventually upgrade to v3. What are the alternatives? Forking the language or switching to another language look to have a higher cost.
Guide announced at PyCon last year that Python 2's end of life is extended to 2020. https://www.python.org/dev/peps/pep-0373/
(auto-correct)
Lots of beginners and low-attention devs will find "Django 3 needs Python 3" easier to keep straight than "Django 2 needs Python 3".