From david at boddie.org.uk Tue May 15 17:52:26 2018 From: david at boddie.org.uk (David Boddie) Date: Tue, 15 May 2018 23:52:26 +0200 Subject: [Mobile-sig] PyCon US 2018 talk about BeeWare Message-ID: <1746860.Se02nLzlrp@aurora> I saw that Russell gave a talk about BeeWare at PyCon: https://www.youtube.com/watch?v=qaPzlIJ57dk It's interesting to see that the focus of presentations about BeeWare has shifted from how the tools work to how they are used. For me this is as interesting as the content of the presentation itself. It got me thinking about what makes a solution Pythonic, which is usually a bit too philosophical for my taste, so I found it interesting to consider the different elements of a solution that needs to target various platforms. On different platforms we have different implementations of the language - well, two at least: CPython (desktop platforms, Android, iOS) and VOC (Android). What people might consider Pythonic depends on their attachment to CPython, but even using the reference implementation doesn't guarantee a Pythonic language environment - as noted in the Q&A, people may expect certain supporting libraries to be present for proper Python. The GUI toolkits are typically different on each platform. Despite the availability of middleware (mostly Qt) that could smooth over the differences between platforms, there is still a perception that toolkits that access native controls are the way to go. Another issue is the perception of the style of the APIs exposed to Python - some toolkits, like PyGTK are considered Pythonic while others are not. Tkinter also sets a standard and enjoys a privileged position that is perhaps not so helpful when thinking about newer platforms. The deployment mechanisms are different on many of the platforms. While CPython has developed its own mechanisms for deploying software (eggs, wheels, whatever), it has tended to be parallel to the mechanisms used on each platform unless the platform itself gained its own support for handling Python packaging (as in Debian, for example). Traditionally, a parallel universe of packages that exists alongside a platform's own collection seems fine. However, whether we like it or not, modern platforms tend to dictate how software is packaged, and this history of not integrating all that well has not prepared CPython well for those platforms. Traditionally, the end result of this diversity has been the tendency for CPython to grow its own solutions to the above issues, and one could argue that this wasn't helped by its popularity as a web server language where Python developers could perhaps define their own standards. It shouldn't have been a zero sum game between web frameworks and other uses of the language but attention was very much focused on web technologies for many years. Now the focus is more on data science and scientific computing it remains to be seen whether better integration with underlying platforms will occur and whether popular development technologies (virtualenv, pip) will help or hinder this. In the end it always seems to come down to finding a way to place abstractions over differences in the underlying platforms, even if there was never a commonly agreed abstraction for a feature. Python was once viewed by many as a glue language, used in places where it made sense and where expectations were set appropriately high or low. Python is now used in places where it might be unrealistic to provide NumPy, for example, but does that mean a compatible wrapper around a platform's native numeric libraries is needed for the solution to be truly Pythonic on that platform? I see that Toga provides another layer of abstraction and I worry that there's a danger of spreading things a little thin with that, covering all the variations between platforms and their quirks while having to compete with both native and other middleware toolkits. For me, that has always been an awkward feature of wxPython: it competes with its own dependencies. Anyway, please feel free to disagree with any or all of the above if you like. ;-) David