Removing Python 2.x support from Django for version 2.0 • Hacker News Board

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

#391

Post by hedora » Fri, Jan 20, 2017, 4:19 AM UTC

brianwawok wrote: post #308

hedora wrote: post #293

Earlier quoted context omitted.

I usually work lower down the stack, and, frankly, that level of code quality would not be acceptable. (But what you describe matches my experince writing application level code) Here is a strawman low level test: Randomly generate a sequence of nonsensical (but legal) API calls by randomly generating some data layout, then feed it into a state machine of legal API calls (eg. CRUD), and check the return values. Once…

You are finding crash bugs with your test. Most Django regressions are logic bugs. Like some library overwrote a method and that method got a new param in Django, breaking the library. Good libraries with good tox suites catch this. Not all libraries are good.

I put all sorts of asserts in the state machine logic (this is the 'check the return values' part). When sufficiently clever, such checks can confirm a surprising range of high and low level behavior.

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

#392

Post by hedora » Fri, Jan 20, 2017, 4:58 AM UTC

brianwawok wrote: post #308

hedora wrote: post #293

Earlier quoted context omitted.

I usually work lower down the stack, and, frankly, that level of code quality would not be acceptable. (But what you describe matches my experince writing application level code) Here is a strawman low level test: Randomly generate a sequence of nonsensical (but legal) API calls by randomly generating some data layout, then feed it into a state machine of legal API calls (eg. CRUD), and check the return values. Once…

You are finding crash bugs with your test. Most Django regressions are logic bugs. Like some library overwrote a method and that method got a new param in Django, breaking the library. Good libraries with good tox suites catch this. Not all libraries are good.

The example you gave (wrong number of parameters in an override) would be caught by any sane statically typed language. (Though if you are distributing updates to .so's you need to explicitly check for ABI compatibility)

I had to search for Tox. It seems like analogous tools would be nice for statically typed "systems" languages too, though there is less need for them there (more bugs are caught at build time, instead of after deploy).

Debian sort of does the same thing when it builds packages, but only checks compatibility with current versions of dependencies. It would be nice if they also checked / tracked compatibility breakage (the "not all libraries are good" observation is language independent, and a "n days since we broke users of this library" label would be great).

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

#393

Post by toyg » Fri, Jan 20, 2017, 6:58 AM UTC

Radim wrote: post #389

toyg wrote: post #358

Earlier quoted context omitted.

This has been explained over and over. Those boundaries in python2 are very easy to get wrong and the runtime will not warn you, which means you won't know about them until some crap data comes down the wire and code chokes or (worse) silently corrupts data. In py3 you are forced to explicitly Do The Right Thing, so entire classes of bugs are just Not Possible. It shouldn't take 8 years to understand this issue, and…

"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 times do you need to change the encoding you use for writing files? How many times do you change an internal class or type? They are totally different ballgames.

> I found your comment unbearably rude, condescending and arrogant

Apologies, but after 8 years and countless hours of bickering on this point, patience can wear really, really thin.

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

#394

Post by oneweekwonder » Fri, Jan 20, 2017, 7:36 AM UTC

SEJeff wrote: post #249

mangeletti wrote: post #198

Earlier quoted context omitted.

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…

Flask was an April fools joke from Armin that became a serious thing. The thread locals hacks and use of globals is pretty horrible. I do quite like Falcon however if I want something != Django. http://lucumr.pocoo.org/2010/4/3/april-1st-post-mortem/ http://mitsuhiko.pocoo.org/flask-pycon-2011.pdf

What is your opinion of bottle.py?

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

#395

Post by vegabook » Fri, Jan 20, 2017, 8:00 AM UTC

toyg wrote: post #356

vegabook wrote: post #267

Earlier quoted context omitted.

rofl! Numeric was started in 1995.

The xml sig started in 1994 and is still active, together with the web sig. The numeric sig started in 2000 and is now dead.

Not denying that Python was/is big in web, but point is that other languages now do that better, which is not true of science.

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

#396

Post by sametmax » Fri, Jan 20, 2017, 8:40 AM UTC

TylerE wrote: post #342

gtaylor wrote: post #338

Earlier quoted context omitted.

The reasons to upgrade are often dependent upon your usage case. To me, the Unicode improvements are reason enough on their own before you even get into the other great stuff (async work, type hinting, stdlib cleanup, pyc rework, etc). asyncio is going to be a slow build, as the ecosystem starts unifying around it. But as that happens, we'll be much better off for it.

Ruby offered an immediate 25% performance increase. That's a lot less niche than Unicode.

LOL, "niche", says the english native.

Plus, 25% of performance, while nice, is not really something that would matter for most Ruby projects. They are web projects, and their bottleneck is not Ruby. Same for Python. While I'm telling you, good unicode support in most european countries is a HUGE deal.

But that's not all. Often People thinking about Python 3 think unicode, but for me there are 2 other things that made my life much nicer:

- better debugging. Error handling is a hell lot better, with better and messages, greater granularity, more safety nets... E.g: you can't compare some objects anymore, you have several exceptions to handle file opening, imports are absolute by default, division is what you expects, a lot more operations are lazy, the stdlib has been cleaned manu redundancies, encoding parameters everywhere, etc. - less verbosity. Writting is consistently reduced. You get finner file boilerplate, shortcuts for OO, unpacking generalization, yield from, f-strings, etc.

Now those are things that are not easy to sell. You don't see them as a reason to migrate when you hear about it. But once you used to them, going back to Python 2.7 feels so bad.

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

#397

Post by ergo14 » Fri, Jan 20, 2017, 9:17 AM UTC

tedmiston wrote: post #378

ergo14 wrote: post #376

Earlier quoted context omitted.

Yeah thats 3 years for now... thats very little time - especially if you have to migrate old projects.

The same argument could be made for any arbitrary amount of time though. 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 pr…

I think you completly misunderstood my comment ;-) And yes 3 years for some projects with small teams is barely enough :)

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

#398

Post by ergo14 » Fri, Jan 20, 2017, 9:18 AM UTC

linsomniac wrote: post #388

ergo14 wrote: post #373

Earlier quoted context omitted.

But you think about this in a wrong way - pyramid is a "glue" framework, unlike django. - 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…

... then isn't it not a big deal to commit to security updates?

Sure, as far as i can tell it was always being updated so far - even without written commitment.

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

#399

Post by miohtama » Fri, Jan 20, 2017, 9:32 AM UTC

bradmwalker wrote: post #178

ergo14 wrote: post #126

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.

WebSauna looks promising: https://websauna.org/docs/narrative/background/intro.html Offers Django feature parity with best of breed components.

You'll get Django parity with Pyramid modern design patterns.

If you have any questions please pop into the chat http://gitter.im/websauna/websauna

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

#400

Post by lmm » Fri, Jan 20, 2017, 11:27 AM UTC

flukus wrote: post #372

lmm wrote: post #272

Earlier quoted context omitted.

Qt is a point in C++'s favour, but not enough to outweigh the downsides of the language.

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.