search

RussBaz / enforce

Python 3.5+ runtime type checking for integration testing and data validation
542 stars 21 forks source link

Huge README update #15

Closed TheDataLeek closed 8 years ago

TheDataLeek commented 8 years ago

Updated readme to better reflect current (and future) status of this project.

What are your thoughts on when we can get a more recent version on PyPI? It would also be cool to post this to reddit (once we get a "stable" version on pypi) to get some more publicity.

RussBaz commented 8 years ago

Right, the new README is generally correct but I would like to raise to points:

  1. Dicts are not technically supported beyond checking whether it is a Dict or not. (Lists are in the state of flux because of point 2)
  2. Checking every item is indeed a very serious hit to performance. Moreover, it can make type checking iterators and generators rather impossible (without missing the point of using them). Therefore, I am considering making them wrapped in a proxy object and hence throw type exceptions only when they are accessed incorrectly in the function body.

I have been waiting for the release of Python 3.5.2. It fixed a major bug with init in Generics but also caused a number of new issues which I will mention in a separate issue later on.

I believe the best way to deal with those 'container' types (i.e. Dicts, Lists, etc.) performance issues, is by implementing Generics first as they are like in-built system 'Generics'. I have some ideas how it can be done. I will keep you updated on this issue.

We can potentially introduce a configurable 'eager'/'lazy' switch to enforcement of types. And then we can also introduce a limit to how deep we should check the data passed.

I would liike to release a next stable version as soon as all tests are green and Generics are working reasonably well. I think, if I am not overloaded again, it might happen this month. I shall create a 'release' issue at some point this week.

So, what do you think?

(PS. The current architecture cannot throw an exception due to Python recursion level being exceeded during the type validation as it is uses generators to avoid recusrion by implementing its own stack)

TheDataLeek commented 8 years ago

Sorry I'm only now getting back to you, it's been a rough past few weeks on my end.

Some thoughts...

  1. I really like the idea of wrapping iterables in a proxy object and raising an error if the type mismatches. I think this "lazy" method of ensuring type safety is a good way to go, how feasible is it?
    • I also think that the config setup can intertwine nicely with this solution, and it's a lot nicer than other more performant methods.
  2. Honestly iterables/nested object types are a nightmare. I think 90% of our userbase will honestly just use 10% of the functionality we offer, and I would love to push out a more full-featured version of our codebase to PyPI. I think we have a really solid tool here, and I would love for it to get more attention, even if we don't fully yet support complex types. (having this be an alternative to MyPy would be awesome)
  3. What are your thoughts hooking this up to TravisCI or some other CI tool? We could then display test status buttons next to each version (dev/master) as a way of showing current status. We could also use a code coverage tool like Coveralls to show more information about the different states of the codebase.
RussBaz commented 8 years ago

Responding to your previous message:

  1. Lazy type evaluation for wrapped types is possible. I just need a lot of time to implement it. It is pretty much covers the generics too.
  2. OK. I agree.
  3. Would be awesome! I experimented with some of them but did not have enough time to properly integrate with this repository. Test coverage results from the command line tools seemed very good, though.