Live data from Hacker News

Removing Python 2.x support from Django for version 2.0

github.com

401–410 of 413 posts

Re: Removing Python 2.x support from Django for version 2.0

#401

Earlier quoted context omitted.

I used Pyramid for a couple of large projects back when it was Pylons, and around the time of the merger that resulted in Pyramid. Django has grown up a lot in the last several years. It used to be really hard to use a different templating language, and I personally really dislike Django's templating language. That was the biggest turn off for me every time I looked into Django. If it had been pluggable earlier, this…

Thanks for the reply. What makes Pyramid better for you than e.g., Falcon? From your comment, it sounds like a lot of the value you've gleaned from Pyramid is based on the framework staying out of your way, so why not use something 5x faster that does the same thing? Does Pyramid provide some unmatched abstractions? (I'm coming from a position of no true experience in Pyramid)

Yes, there isn't feature parity between pyramid and falcon.

You have event system, security abstraction, all kinds of overloading helpers for views and internal machinery that falcon doesn't seem to provide at least from my cursory look. Compare the size of documentation and configuration options between both projects.

Also looking at this http://klen.github.io/py-frameworks-bench/ the 5x better speed of falcon seems to be completly made up or occur in some very specific situation. More realisticly it looks like falcon can be 30% faster in some scenarios not involving storage - but for the price of giving you less options.

Which probably means that if you use any kind of storage the difference between those two can be ignored.

Re: Removing Python 2.x support from Django for version 2.0

#402
post #245

Earlier quoted context omitted.

Oh, it's not appropriate? Should I go sit in the corner now? Who the FUCK do you think you are??

We've banned this account. Please stop creating accounts to break the HN guidelines with. https://news.ycombinator.com/newsguidelines.html

Well stop being so fussy and grow up. Also, update your dumb policies to something more useful that actually facilitates discussion, not just sheep baa-ing.

Re: Removing Python 2.x support from Django for version 2.0

#403

Earlier quoted context omitted.

It already exists, as a Python2 fork: https://github.com/naftaliharris/placeholder

This is the greatest thing ever - for systems work, python3 is a nightmare. Thanks for sharing this.

What's special about "systems work" that makes python3 worse in your experience? (also, was is "systems work" for you, since I might be misinterpreting that -> I am assuming "low-level unix scripting" or something like that)

Re: Removing Python 2.x support from Django for version 2.0

#404
post #361

Earlier quoted context omitted.

>Python 2 is slowly being EOL'd and if you're starting a brand new Django project there's no reason on earth you should choose Python 2 anymore. Except that there are still some critical packages that aren't on Python 3 yet. Not to mention a lot of functionality breaks even if the libraries do exist, which means you have to code things up quite differently sometimes.

1) Super super SUPER old argument (that's completely wrong and out of date FWIW) 2) Let's see some proof of your argument, because many packages and platforms are happily supporting Python 3 now. Put your money where your mouth is.

Still having issues with AWS related packages not being fully ported. A lot of our workflows in Pandas broke. It operates quite differently in Python 3 for certain operations like typing data frames which messed up some of our ETL. Also, more explicit encoding was needed.

Re: Removing Python 2.x support from Django for version 2.0

#405
post #393
post #389

Earlier quoted context omitted.

"With dynamic typing, the runtime will not warn you, which means you won't know until some crap data comes and your code chokes. With static typing, you are forced to explicitly Do The Right Thing, so entire classes of bugs are just Not Possible." See what I did there? toyg, I found your comment unbearably rude, condescending and arrogant, and downvoted it for that reason.

> See what I did there? Confused your terminology? With static typing, the compiler will warn you, not the runtime. Regardless, the difference is that in practice, file-handling boundary calls don't need to be as flexible as internal interfaces, and it's obviously much more difficult to figure out what The Right Thing To Do is in the latter case (or whether there is a Right Thing at all, in a lot of cases). How many…

Have you considered that if you find yourself debating for 8 years without success, you're debating the wrong side? :)

Yes, Python 3 is an improvement over Python 2. I like Python 3. No, Python 2's unicode support was fine, contrary to OP's claim.

Re: Removing Python 2.x support from Django for version 2.0

#406
post #400
post #372

Earlier quoted context omitted.

Could you write your UI in c++ with custom bindings and have the rest of the app in python? Qt's binding support has been it's biggest issue since forever.

Maybe, but I like using Python for the GUI too. It was really nice back when it worked.

A project you might be interested in is libui (https://github.com/andlabs/libui). I can't comment on it because I haven't used it and it's still quite young but it looks promising, it's on my radar to learn soon. Native widgets and written in c so the bindings should be stable. I've never written bindings for c++ but I'm guessing it's not easy because all the c++ toolkit bindings are unstable.

It has quite a few bindings already, here are the python ones: https://github.com/joaoventura/pylibui .

Re: Removing Python 2.x support from Django for version 2.0

#407

Earlier quoted context omitted.

You talk as if the switch doesn't look like a bunch of arbitrary decisions made on the appearance of purity. If more of an attempt had been made a maintaining compatibility, there wouldn't be nearly as much fight. Python 3 becomes a bit uncanny valley for me when I try to code in it and I tend to use a different language as there less of an internal code switch, especially as I still have to maintain large numbers of…

They got rid of a lot of cruft that's with us since 1.5.x. Python 3 is a great language, much better than Python 2 when you explore the differences.

The truth is, it's Python. I'm not looking for a great language, I'm looking for language that'll help me get work done... quickly and not give me a migraine if I have to come back to it (Perl). The 3 changes are just big enough to catch me (and every other Python programmer I've worked with) so that I can't just program, which tends to push me towards keeping it in 2.7 or switching to another language, where the similarities don't exist to pull me into bad habits. The whole mess really sours me on the language that made me love programming again.

Re: Removing Python 2.x support from Django for version 2.0

#408
post #403

Earlier quoted context omitted.

This is the greatest thing ever - for systems work, python3 is a nightmare. Thanks for sharing this.

What's special about "systems work" that makes python3 worse in your experience? (also, was is "systems work" for you, since I might be misinterpreting that -> I am assuming "low-level unix scripting" or something like that)

In my last three companies, the bulk of the infrastructure was defined and managed via Python scripts (a lot of this predated Ansible being great), so what gets forgotten is the literal billions of lines of custom wrappers and classes that are broken, usually on the print statement v function debate or how string formatting works. I can't justify hiring someone to dig through all that code just to bring it up to snuff and everything needs tweaking. Usually we end up just writing new code in another language and call it from python or the other way around. I can't seem to get comfortable handling both versions in one project without getting REALLY frustrated. So, yeah, a fork with the niceties from python3 that allow my tech debt to still run (and hopefully better), allowing me to replace bits (likely into non python languages - Go is growing on me) at a time and not en masse is pretty frikken awesome.

Re: Removing Python 2.x support from Django for version 2.0

#409
post #361

Earlier quoted context omitted.

>Python 2 is slowly being EOL'd and if you're starting a brand new Django project there's no reason on earth you should choose Python 2 anymore. Except that there are still some critical packages that aren't on Python 3 yet. Not to mention a lot of functionality breaks even if the libraries do exist, which means you have to code things up quite differently sometimes.

1) Super super SUPER old argument (that's completely wrong and out of date FWIW) 2) Let's see some proof of your argument, because many packages and platforms are happily supporting Python 3 now. Put your money where your mouth is.

Agree. The argument was semi-relevant but on the way out when I learned to program 6 years ago.

If in half a decade things haven't been ported there are more serious issues.

Re: Removing Python 2.x support from Django for version 2.0

#410
post #195

Earlier quoted context omitted.

No - but you've set me on the right track, there looks to be a pykdeuic4-3.4 executable (I had assumed if there were anything like that it would be a case of update-alternatives, but apparently not?). Will try that when I get home.

In general, I've found that Ubuntu versions of the last 1-2 years support Python 3 fine, you just have to use the "python3-*" packages.

Fair enough. E.g. I was assuming the reason PyQwt didn't exist for python3 was because Ubunty hadn't packaged it, but having looked further it seems the library itself is unmaintained.
Post reply on HN