[njsmith]

This is a slightly wacky solution to #8. By "slightly wacky" I mean that contains the following line of code:

cls.__class__ = cls

Based on watching some of his talks I feel fairly confident that @dabeaz will appreciate this, but I am less certain about whether it's actually a good idea, so would appreciate comments ;-).

Actually, my main hesitation is that I'm not really sure whether doing table-based dispatch on the return value from next_event ever makes much sense -- in my experience so far, libraries usually have a pretty small and specific set of events that they're looking for at any given time. But maybe it's useful for those who like more declarative state-machine kind of approaches? And it's not a big deal to support; it's like 2 extra lines of code that don't touch anything else in h11 at all.

This is a reworked version of @RazerM's work in #11.

[codecov-io]

Current coverage is 100% (diff: 100%)

Merging #18 into master will not change coverage

@@           master   #18   diff @@
===================================
  Files          20    20          
  Lines         867   869     +2   
  Methods         0     0          
  Messages        0     0          
  Branches      169   169          
===================================
+ Hits          867   869     +2   
  Misses          0     0          
  Partials        0     0          

Powered by Codecov. Last update 9c0a553...f6c685d

[njsmith]

@Lukasa: do you happen do have any opinion on this?

[Lukasa]

The implementation is bonkers, but the goal is sound. Wanting to do dict-dispatch or the equivalent of singledispatch based on event type is a good idea, and if this can do that without difficulty or reduction in supported Python versions then I say why not?

[njsmith]

It's not entirely unprecedented: after all, type.__class__ is type :-). But, yeah, bonkers is a good description :-)

Oh well, let's do it!