Drop support for Python 2?

[pgjones]

I'd like to drop support for Python 2, type hint this codebase, and make use of features like dataclasses. I've a local version where I've done this - to allow testing of mypyc (it does speed things up). I know around this time last year there was a need/desire to keep Python 2 support for urllib3 (have I remembered this correctly?). Is there still a motivating need for Python 2 support?

To clarify I think the status quo is currently fine, however if Python 2 isn't needed/desired then great.

[pquentin]

urllib3 does not use h11 (yet?) and will soon issue a v2 that drops Python 2 support anyway. We do use h11 in https://github.com/python-trio/hip that does support Python 2. I'd be happy to remove Python 2 support there too, but @njsmith has been opposed to it in the past.

[njsmith]

Yeah, even I'm running out of excuses to keep py2 support at this point :-)

[bluetech]

So are we OK with dropping Python 2 for the next version? I am willing to work on it if so.

The reason I want to drop Python 2 is that I want to add inline type annotations to h11, like we did for wsproto, if that's desirable. It is possible to use type comments but that's painful.

[pquentin]

Yes, you can open a pull request to remove Python 2 support! (And another one later for type annotations, I guess)

[pgjones]

@bluetech I have a typed branch - I'll review your PR then push it up (although I'm aiming to merge the line ending PR and release before dropping Py2).

[bluetech]

I have a typed branch

Awesome. Feel free to add me as a reviewer.

[Kriechi]

Done in v0.12.0 (2021-01-01).

[hugovk]

Looks like much of this comment could be removed now? There is no longer self._start or self.compress in the file:

h11/h11/_receivebuffer.py

Lines 23 to 43 in fb6c715

	# Note that starting in Python 3.4, deleting the initial n bytes from a
	# bytearray is amortized O(n), thanks to some excellent work by Antoine
	# Martin:
	#
	# https://bugs.python.org/issue19087
	#
	# This means that if we only supported 3.4+, we could get rid of the code here
	# involving self._start and self.compress, because it's doing exactly the same
	# thing that bytearray now does internally.
	#
	# BUT unfortunately, we still support 2.7, and reading short segments out of a
	# long buffer MUST be O(bytes read) to avoid DoS issues, so we can't actually
	# delete this code. Yet:
	#
	# https://pythonclock.org/
	#
	# (Two things to double-check first though: make sure PyPy also has the
	# optimization, and benchmark to make sure it's a win, since we do have a
	# slightly clever thing where we delay calling compress() until we've
	# processed a whole event, which could in theory be slightly more efficient
	# than the internal bytearray support.)

[Kriechi]

would you mind opening this as a new issue / improvement / feature request ?

[hugovk]

Sure, please see #152.