timothycrosley

> No importing basic type

This at least is being solved in Python: https://www.python.org/dev/peps/pep-0563/

> inline interfaces

Typed dicts in 3.8 look pretty similar at cursory glance https://www.python.org/dev/peps/pep-0589/

I'll definitely play around with it more!

Thank you for sharing! This looks really promising, I'll try to think of ways I can contribute to the project.

> TypeScript got typings right.

I have not used TypeScript, but looking at it's documentation the syntax for type annotations look identical. Would you be willing to expand on why you think its approach is better / how it's different?

I use Cython a lot! But mostly to speed up existing Python code, and build C-extensions faster. I don't see it as a strict subset of Python or a new language to build a community around. Nuitka I just started experimenting with to build standalone Python executable, and I really like the direction and roadmap they are following. In the end though both of these technologies seem like ways to somewhat speedup existing Python code and not attempts to introduce a strict language subset that would allow the greatest amount of optimization, and finally fix long running issues, like the inability to have multiple versions of a package installed.

I've been tracking nim, and would agree it's the most promising so far! I feel though that it's trying to be too flexible in many ways. Examples of this include allowing multiple different garbage collectors and encouraging heavy ast manipulation. I'm also afraid it is different enough to keep it from attracting a significant amount of developers from the Python community. Nonetheless, it's something I plan on using and contributing to, since it's the best option so far.

More and more I want someone to create a new language that amounts to a strict subset of Python, with mypy built-in, and is compilable into machine code. Python has by far my favorite syntax, community, and in my experience leads to the greatest productivity. There just happens to be a lot of overly dynamic features, that aren't even used by most, but used just enough to hold back optimization and structural improvement.

As an (unrelated to the Algorithm) Python developer, also named Tim, I've never been able to hear the last of it. Still a great algorithm, though!

Thoughts behind project: https://timothycrosley.com/project-6-cruft

Updated in latest release to use trailing underscore: https://timothycrosley.github.io/hypothesis-auto/CHANGELOG/ figured it would be the least painful the earlier I did it :)

Similar to parent I bet hard on Python in 2008. That means I've been writing Python for over 10 years. Sure, any programmer can pick up a new language, but I'm able to build (what I believe) are useful projects and release them in Python every single week, outside of my full time job, community involvement and family: https://timothycrosley.com/. That level of productivity only comes from long term investment in a language IMHO.

I'd use it!

That's a great call! I'll update this to use trailing underscore in a later version

> I think I would be more comfortable with it generating test files that I could keep beside my other tests.

This is a very interesting idea I might explore more!

`auto_pytest_magic` is only made available if you have pytest installed. You can enforce this by doing:

  pip3 install -U hypothesis-auto[pytest]

You are correct! Thanks for catching this! I'll fix the example later today

Yes! A smart one though, that limits itself to the type constraints you've specified to avoid redoing the work of your type checker.

It's an extension for hypothesis, and its value is 100% just convenience and accessibility. Really, it's meant to be a sort of gateway to doing full property-based testing, in the least barrier way possible. I wrote a bit more about why I created it here: https://timothycrosley.com/project-5-hypothesis-auto

While I agree, that `_param` generally means private, it is also a common way to allow parameters to be passed into a function where all other parameters are passed directly along via args and *kwargs to avoid naming collisions. An example of this is NamedTuple: https://docs.python.org/3/library/collections.html#namedtupl....

By default, the biggest value from this is catching unexpected runtime exceptions with certain values (the edge cases you don't think of yourself). To get the most value out of it, you can further specify what you expect from the result using the _auto_verify=Callable() parameter, or by looking at the individual test cases.

Simple example:

  from my_library import add
  from hypothesis_auto import auto_pytest

  @auto_pytest()
  def test_add(test_case):
     add_result = test_case() 
     if test_case.params.kwargs['number_1'] > 0 and test_case.params.kwargs['number_1']:
         assert add_result > test_case.params.kwargs['number_1']
         assert add_result > test_case.params.kwargs['number_1']

Thoughts behind project creation live here: https://timothycrosley.com/project-5-hypothesis-auto

Thoughts behind project creation live here: https://timothycrosley.com/project-5-hypothesis-auto

Hi @kburman,

For cases like that it would be best combined with a mock:

  @auto_pytest()
  def test_add(test_case, mocker):
      mocker.patch('db.call')
      test_case()

Note that this example utilizes the following pytest extension: https://github.com/pytest-dev/pytest-mock

However, I would also note, that just because you have some methods that have potentially dangerous side effects, in most large code-bases, not all functions do. Which is why it operates at a function by function basis. You can use this for new pure functions, while continuing to write other tests in the same fashion by hand.

Been doing this before the typing module was released, using hug: http://www.hug.rest/

FastAPI has a lot of advantages at this point for someone looking to do the same: https://github.com/tiangolo/fastapi

hug has some catching up to do, some of it just because it got in so early (It needs to be updated to be compatible with mypy and the types defined typing.py!) in any case using typing on API endpoints - independent of how you feel about Dynamic vs Static typing in general, just makes a lot of sense IMHO.

portray no longer requires a config to be present, instead you can just specify modules directly from the command line with `-m`: https://timothycrosley.github.io/portray/TROUBLESHOOTING/#no...

A lot of what you describe is for CPU bound problems, most of the problems I face personally and the the problem, in particular, the parent mentioned are IO-bound. Async in Python is a near-perfect fit for this kind of problem space and is really easy to reason about and debug as you can step through and debug one line of execution at a time.

Do you have any concrete examples?

Have you tried async? I find it much easier personally to reason about and debug than channels, and is perfect for IO-bound problems. If you really like channels, note that Python 3.9 will have sub-interpreters and channels as well: https://hackernoon.com/has-the-python-gil-been-slain-9440d28...

> This is exactly how I felt moving from a Python codebase to Go. But you realize on the 100th or so Python stacktrace that it's worth the investment up front, if not for type safety alone.

Luckily, you don't have to choose between those two outcomes:

https://github.com/python/mypy

Detailed explanation of why this project was created: https://timothycrosley.com/project-3-pdocs

The change away from pdoc3 and to a new fork of the original pdoc (called pdocs) has landed:

https://github.com/timothycrosley/portray/blob/master/CHANGE...

https://timothycrosley.github.io/pdocs/

Thanks!

~Timothy

The change away from pdoc3 and to a new fork of the original pdoc (called pdocs) has landed:

https://github.com/timothycrosley/portray/blob/master/CHANGE...

https://timothycrosley.github.io/pdocs/

Thanks!

~Timothy