
Some Sessions from the Python Language Summit - lukastyrychtr
https://lwn.net/SubscriberLink/821412/9fbb4093d7945bdb/
======
miohtama
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.

~~~
jventura
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](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](https://news.ycombinator.com/item?id=23335704)).
I’m able to share all the python code but adapt the UI using the native
tools..

------
jkingsbery
> 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.

~~~
flohofwoe
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](https://github.com/wren-lang/wren))

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

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

~~~
nhgiang
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.

~~~
andreareina
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](https://github.com/pytest-
dev/pytest-subtests)

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

[https://github.com/pytest-dev/pytest/issues/916](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.

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

