Refactor/rename "private" wrappers to not lie about being private so type hinting and autocomplete work

[negentropicdev]

For example, this is the docstring for _FIFO:

However this is in fact returned to user code via the Session.fifos property but cannot be imported and therefor type hinted properly because of the underscore. This is a pervasive pattern throughout nifpga making development slower using this library since most type hints become Any and intellisense/autocompletion is impossible. These "private" classes are in fact the public API of parts of the library and should be refactored as such.

Effort has been put into ensuring functional docstrings are throughout the code yet they remain out of reach to editors. Reading documentation is much slower than being able to get code completion in the editor.

Additionally, it should be possible to provide consistent public APIs so that the different internal types aren't exposed to users and there wouldn't need to be so much reliance on type unions:

I'm happy to take a crack at this and submit a PR if this sounds good. It should be possible to accomplish without impact to user code but I'd like to discuss a few options and preferences since there are gaps in docstrings across related code. e.g. _FxpFifo has docstrings for methods but _DataConvertingFifo does not so one of my questions is would it be better to:

• collapse to a single class with a flag for the type so it can internally differentiate behavior
• utilize inheritance and docstring the super class method definitions
• something else?

[strainmike]

That seems reasonable. Its definitely not intentional that intellisense and autocomplete don't work.

The main goal of the class being private in this case was to make the constructor private. There are probably better ways to do that in python these days.

Feel free to take a shot at it. I would probably try inheritance from an abstract base class first if that works out well. I'm not sure how detailed that can get though since operations like read/write would use different types depending on the class used.

[negentropicdev]

I tend to not worry about that too much myself, if the rest of the API isn't open to poke things in/out unnecessarily to get the parts needed to fulfill the init params then having access to a constructor is kind of moot.

[negentropicdev]

Presumably the aim is to maintain support for Python 2? Presumably there's some ADG customer somewhere still locked in...

[negentropicdev]

nvm, I see that 2.7 deprecation was called out and everything requires 3.5+ now. I'll work with this in mind and probably clean up a few of the lingering 2 details.