Dustin Spicuzza

I think that makes sense. I'd be in favor of distributing a vscode-compatible install by default, but make other configurations possible. Not sure how that would work quite yet though.

If one were to go that route, I'd want to use cython to generate that I think.

Wouldn't cffi require compilation of some kind?

The 2017 HAL + Python 3.6 is significantly faster: ``` admin@roboRIO-2423-FRC:~# time python3 -c 'import hal' real 0m2.089s user 0m0.940s sys 0m0.170s admin@roboRIO-2423-FRC:~# time python3 -c 'import wpilib' real 0m4.119s...

Well. HAL seems to be faster this year. But wpilib is about the same... I imagine it has to be due to all of the imports we're doing. We could...

Here's HAL for this year, looks like it's a bit slower: ``` time python3 -c 'import hal' real 0m0.978s user 0m0.637s sys 0m0.259s ```

Full results: ``` lvuser@roboRIO-2423-FRC:~$ time python3 -c 'import hal' real 0m0.981s user 0m0.637s sys 0m0.262s lvuser@roboRIO-2423-FRC:~$ time python3 -c 'import wpilib' real 0m2.606s user 0m2.213s sys 0m0.504s lvuser@roboRIO-2423-FRC:~$ time python3...

Looks like we're in the same ballpark this year: ``` lvuser@roboRIO-2423-FRC:~$ time python3 -c 'import hal' real 0m1.041s user 0m0.708s sys 0m0.227s lvuser@roboRIO-2423-FRC:~$ time python3 -c 'import wpilib' real 0m2.874s...

This is a bug in WPILib (https://github.com/wpilibsuite/allwpilib/issues/4067). As a workaround, you can create a compressor object directly: ```python self.compressor = wpilib.Compressor(0, wpilib.PneumaticsModuleType.CTREPCM) ```

One question is how poorly this would interact with something doing inspection of wpilib for autocomplete et al.