Some Sessions from the Python Language Summit | Hacker News Reader

Some Sessions from the Python Language Summit

lwn.net

32 pointslukastyrychtr14 comments

Nice points about the mobile Python. My old company ported Python to Symbian operating system (Nokia phones) around 2008. The problem for Python in mobile is the same as for JavaScript / React Native: The startup time is slow because modules cannot be imported or statically loaded fast.

Even though mobile phones have gotten fast, this is an severe issue with React Native apps. And Facebook is pouring in a lot of engineering to tackle it. But the progress is incremental at the best. As a result some code gets rewritten in C++ because of this issue (see e.g. Trust Wallet). Even though I love Python as a programming language I would not recommend it for consumer grade mobile application development and I feel it is unlikely to get there ever unless some breakthrough happens in runtime development.

I have an Android app on the Play Store which uses Python and can confirm that the startup time is slow because of the imports. I think one possible solution could be to invoke the start of the interpreter outside the UI thread, at least it could give the illusion of a faster app start. Unfortunatelly the app gives me ~5€/month so it is not profitable enough for me to care.

I opened source the idea at https://github.com/joaoventura/pybridge

The thing that makes this different from a pure android python project is that I only use Python as a kind of mobile RPC backend. The UI is completely native in Java/Kotlin.

As a side note, today I’ve open sourced the same technique, but for iOS (https://news.ycombinator.com/item?id=23335704). I’m able to share all the python code but adapt the UI using the native tools..

> One of the problems that CPython has struggled with over the years is its C API for extensions.

Honest question: is there an example of a language that does C extensions well? As a professional programmer, I have worked at different times with C extensions in Node.js, Java, R, and Erlang, (in addition to Python). Erlang and Node.js were maybe ok, but had their own challenges.

I found Lua <=> C interop very easy to use, I guess because Lua has been designed as an extension language for otherwise native projects (but it works just as well in the other direction, extending Lua projects with native code).

The same is most likely true for other "scripting languages" where the main purpose is to add a scripting API to otherwise native applications (like Wren: https://github.com/wren-lang/wren)

LuaJIT's FFI inspired the PyPy team's CFFI (which also works with CPython.) https://cffi.readthedocs.io

Tcl used to be a pleasure, then again I haven't touched it since 2002.

I was going to mention Tcl. I suspect that the richer the semantic model of the language, the more challenging it is to provide a straightforward C API.

Curious for people who have tried Hypothesis, what did you think? Is it worth using if you've been using standard unit tests?

For instance, in traditional tests you may need two test cases for some behaviour. One is for usual inputs and one for some edge case.

With Hypothesis, you can combine those two tests into one, by letting Hypothesis generate the inputs for you. Hypothesis is pretty smart to find edge cases that you usually don't think of.

Overall, it reduce my time to write tests by at least half, maybe 75% even.

The caveats are: 1/ Tests may take visibly longer to run. 2/ If you have setup/teardown or fixtures that you want to repeat each generated input, you have to do this manually. This is imo the biggest weak point of Hypothesis right now.

I like pytest for the ergonomics of its static setup/teardown/fixtures (plus not having to stuff everything into a unittest.TestCase). Unless you mean using generated input in those bits? In which case yeah, not ideal. At $dayjob we do some chonky processing; generating new input for each property we're testing is just barely ok right now, but that's probably not going to hold for very long.

[1] https://github.com/pytest-dev/pytest-subtests

Sorry for not being clear. This is what I was talking about:

https://github.com/pytest-dev/pytest/issues/916

It is a known issue. Basically your fixture/setup/teardown, which you expect should run for every example generated by Hypothesis, actually only run once.

Oh yeah I remember that. Hasn't been an issue for me, thankfully.

> Hypothesis is pretty smart to find edge cases that you usually don't think of.

This is worth reemphasizing.

For certain kinds of hard problems, I've found it really valuable for building confidence in an implementation.

If you happen to have a reference implementation, with a small surface API, it can be a very fast way to write tests: tell hypothesis to input anything it wants and validate that both libraries produce the same result. It's not magic, you will probably still have to give hints about how to build interesting inputs, but still a very quick way to get a lot of coverage. (Also be sure to crank up the number of examples to build more confidence, 100 is often not enough to really explore an input space).

It might take time getting used to thinking in terms of properties/invariants, but IME it's definitely worth it. Both for covering a larger portion of the input space as for eliciting the thought of what properties we want from the system.

Reply on news.ycombinator.com