241–250 of 413 posts
Earlier quoted context omitted.
I code against both Django and Tornado. My Tornado based HTTP servers call C extension while they're handling GETs and POSTs. And that's why I'm staying on 2.7.8 until a customer pays me to port to 3.
I'm curious why 2.7.8? What is preventing you from using 2.7.9+?
Earlier quoted context omitted.
What critical packages still need to be ported to Python 3? Might be a fun project if they're open source.
For me, the google api client libraries, and AWS Lambda. That last one isn't totally Django related, but we use it for certain service calls, and it'd be nicer to be able to maintain one version of the language across the django app and related services. We ended writing a service in PHP to use Google's APIs, and are mostly using Scala or JS instead of Python for the Lambda services because this project is basically…
https://github.com/google/google-api-python-client/
I see only one Py3 bug is the open issues. And I think even their ancillary library Python Flags is now officially Py3 compatible, even though there has been a Py3 fork of it for years.
I was surprised to see the elimination of the encoding comments, I thought that the default encoding would be platform dependent. After a little research I found PEP 3120 which mandates UTF-8 for everybody, implemented in Python 3.0. It also goes into the history of source encoding for 1.x and 2.x. I wonder why there aren't more problems with Windows users whose editors don't use UTF-8 by default?
Says who?? Someone with delusions of grandeur, obviously. Because that's not up to anyone to say. Python 2 is obviously NOT going away any time soon. You can't just look at reality and claim the opposite just because it pleases you. Python 2 is here to stay and is in MUCH better shape than Python 3, in terms of actual production usage globally. Python 3 is a bad joke that someone wants to force down people's throats…
Earlier quoted context omitted.
Claiming people have been brainwashed because you happen to have a different use case than them is not appropriate for HN, nor anywhere. And speaking to your earlier point as somebody using Python 3 in production, says me . Nobody in here cares whether you in particular gets to see the advantages of the new version; but you don't get to say "nobody is using it in production", you don't get to say it's "forced down pe…
Oh, it's not appropriate? Should I go sit in the corner now? Who the FUCK do you think you are??
Earlier quoted context omitted.
Which comments are you interpreting as demands? >> A lack of being paid (money at least) doesn't imply no obligations, nor freedom from criticism. > Excellent, then you should be fine with me criticizing the attitude that's been displayed here. Great. Do you actually have a response to this point in context, then? > This is the same as the IE6 situation: Want support for it? Pay extra for it! You did not argue this.…
You're appropriating criticism that was not directed to you, but to coldtea. Here and elsewhere. Edit: Yes, appropriating . You're taking criticism I specifically directed at coldtea, applying them to your comments and then complaining it doesn't fit. I am done talking to you. Edit 2: This was not meant to sound as aggressive as it did, sorry.
So, after a poor evolution strategy that lead the Python world to be split in two and forces maintainers to offer two versions for the same library, and upstream maintainers to offer support for two different python versions, the same is happening for Django! I speculate that the latest Django 1.x will remain used - and possibly the most used - for a lot, lot of time.
Python 3 is a seriously misguided project. It's got tons of newer-to-Python fans (your HN downvoter demographic), and tons of silent-majority "real-world" users especially in scientific programming who just don't like it. I moved to 3.4 a year ago and, as a data scientist, I have to say I find nothing in 3 to be better than 2, other than the extremely marginal default float arithmetic. I may be wrong for web developm…
Please don't make generalizations about people who disagree with you just to score a rhetorical point, and please don't break the HN guidelines by going on about downvotes: https://news.ycombinator.com/newsguidelines.html.
Oh my god stop. You're all over this thread. What bit you ? This is the price you pay for staying on an old version . You do not get to stick to an old version AND demand that others do too. You CAN stay on Python 2. You CAN stay on Django 1.11. It's LTS. So is Python 2.7. You get to use both until 2020 with no issues. After that, not upgrading is a technical debt that will start to accrue, faster and faster as you c…
We detached this subthread from https://news.ycombinator.com/item?id=13434460 and marked it off-topic.
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 always expected Pyramid to offer some performance benefits over Django, given the origins (taking the best of framework X and Y), esp given that you can choose your own ORM (e.g., SQLAlchemy), etc. However, once you're out of the unrealistic scenarios (single query benchmarks, etc.), it doesn't do that well[1]. It's not prohibitively slow, but to make the jump from something as well documented and with as large a c…
The next release, Django 1.11, will be a long-term support release, and the one after that, Django 2.0, will no longer support Python 2. https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ I've grow to highly respect the Django project for its good documentation, its healthy consideration for backwards compatibility, security, steady improvements and all round goodness.
Interestingly, I have the exact opposite view on Django. I hate their API and overall architecture, which I find to be the result of glueing features on top of features for many years. The internal code also is just like that: looks like every single method is riddled with out-of-band conditionals, which is the result of a community that prefers to hack things to work, instead of rethinking/refactoring.
The overall architecture is sound though. Tight coupling of core components, loose coupling of non-core components. Keep in mind that it's an "opinionated" framework though, so they do safely assume that if you're using django you want to be using its core components as a bundle, and will work with them as designed.