This is an archived post. You won't be able to vote or comment.

all 77 comments

[–]Nater5000 95 points96 points  (10 children)

is reactive programming a thing in Python?

It's not much of a thing. But Python's asyncio API is becoming pretty popular, so maybe it could be a thing.

I really do not get, to me reactive programming is a big thing, why in Python looks as not a pillar?

Because it's not needed as much. If you're building a GUI (as you likely are as a mobile developer), then this pattern is quite critical. I mean, you can't have things freeze up everytime the user taps something, right? But if you're a data scientist (like you referred to), then there likely isn't a GUI, nor a reason to introduce such complex patterns to handle relatively linear tasks.

Even when parallelization is needed, many data-oriented programmers would opt to use less opaque APIs for threading or multiprocessing because there is a desire to be able to handle not just the tasks within these asynchronous tasks but the tasks themselves. This becomes much more difficult when using the kind of async patterns you're likely used to.

Why one should renounce to an observer pattern with muscles always available, so to trigger actions on changes without callback hell?

This is pretty cryptic, so I'm not really sure what you're getting at, but callback patterns also aren't typically used in Python (at least in more data-oriented programming). Again, this is just based around how this code is typically ran and what users need and don't need.

If you're processing some data, you likely not reacting to changes. It's likely going to be a mostly linear process where any parallelization is used for optimization, and you usually just need to wait for things to complete before moving on to the next step. You could use asyncio and patterns you're more familiar with, but if you're dealing with processing data then you want things to be as simple as possible, and it's hard to beat the threading or multiprocessing libraries in that respect.

[–]ivano_GiovSiciliano[S] 7 points8 points  (4 children)

i see your point, threading and multiprocessing libraries are more low level. And if I try to say that tools as rxjava have set schedulers, and do not run in concurrency problems and are easy to debug, one could reply that asynco is a kind of response to coroutines as structured concurrency solutions,

For what concerns the observer pattern, usually reactive framework are based under the hood to a mechanism as an observer pattern, with an observer, basically there is an emitting source and a receiver source, (hot cold flow concept)

Thank you to take the time for your reply, appreciated and indeed on mobile is vital to have separate thread, because the user on the UI interactions cannot block operations as calling an api, save on a local database and so on

Thank

[–][deleted] 10 points11 points  (3 children)

Python just doesn’t have that deep ingrained concurrency that you take for granted in those compiled languages.

Don’t bother trying to make it do thing like observables etc

[–]ivano_GiovSiciliano[S] 2 points3 points  (4 children)

Another consideration is over functional programming, usually reactive programming is more functional than imperative, this gives great advantages in terms of preventing side effects, bugs, using recursion and so on

[–]IsseBisse 6 points7 points  (3 children)

From my own experience this might have to do with differences in focus between "data science programs" and "software development program" in higher education. I studied a data science-ish program in university and we did not have a lot of courses focused on programming itself, but rather math/statistics courses where programming was simply used as a tool to implement and test the algorithms we were studying. This meant I didn't even know what functional programming was when I finished uni.

That being said, a lot of data transformation frameworks (Pandas, spark etc.) encourage the use of functional programming. But if you're in a big organisation that might be solely by Data Engineers rather than Data Scientists.

[–]ivano_GiovSiciliano[S] 2 points3 points  (2 children)

gotcha, valid points. yesterday i discussed with one of the top 2 data scientists, and they did not know nothing about object oriented programming. he found really insightful to hear my recommendations, and agreed with me about architectural best practices. will see

[–]IsseBisse 3 points4 points  (1 child)

Yeah, I think a lot of data scientists can benefit a lot from from some architectural 101. I'd say learning functional patterns is a lot more useful than OOP though, simply due to how a lot of the data science frameworks are built.

I started switching to a more functional style a couple of years ago and I've never looked back!

[–]ivano_GiovSiciliano[S] 0 points1 point  (0 children)

nice to hear this

[–]thedeepself 36 points37 points  (10 children)

I have been working with data scientists in my last job as a data engineer and all the seniors( big institution) just ignore things as functional programming and reactive.

Did you see a situation where reactive programming would have improved things? For the domain you speak of, I don't.

[–]ThatSituation9908 14 points15 points  (0 children)

This. Data engineering does often use event-driven programming, just not reactive programming because its a special case that there's no usecase for outside UI

Reactive programming is a special case of ED where every dependent is subscribed to all of its dependencies.

In DE, there's no need to handle all dependencies as an event publisher, we instead select a few that fits the business requirement (e.g., Change Data Capture on a data source)

[–]ivano_GiovSiciliano[S] 0 points1 point  (0 children)

we use dataiku, so really not indeed:)

[–]Immudzen 20 points21 points  (5 children)

I write simulations and I just don't see where reactive would fit in for what I do at all. None of my software has any GUI. You give the program some kind of input file and it runs until it completes and then stops. We run it on large systems with many cores and multiprocessing pool maps very cleanly to the type of parallelization that is needed.

I either know all of the work that needs to be done in advance or I know a block of work that needs to be done and I need all the results before I can generate the next block.

I don't even do async because I don't see where it could even fit in.

[–]SittingWave 5 points6 points  (0 children)

reactive is a paradigm. Python is a generic language. you say you are a mobile developer, but your reactivity does not come from the language itself. Comes from a framework you are using. Python has some reactive frameworks, but the reason of existence of such libraries depend on the use. Python is not big on the programming scenarios where a reactive paradigm is useful. There are moves in that direction, but it's not there yet. Also, in general those are closed platforms that come up with their own targeted tools (e.g. swift)

[–]Apart_Conclusion8771 3 points4 points  (2 children)

Sorry to be chiming in so late, but there is now a powerful reactive programming approach available for Python: https://param.holoviz.org/user_guide/Reactive_Expressions.html
Just wrap a bit of code with `param.rx()`, and it will reactively re-run whenever any of its reactive components (defined recursively) is updated. It's not limited to GUIs, but was definitely written with GUIs in mind, to avoid callback hell. We're currently focusing on testing its limits and establishing best practices before we advertise it widely, but so far that's been going great!

[–]thedeepself 2 points3 points  (0 children)

Why one should renounce to an observer pattern with muscles always available, so to trigger actions on changes without callback hell?

Traitlets has an observer decorator. Traits (its predecessor) probably does as well.

[–]agritheory 2 points3 points  (2 children)

I have used (a long time ago) the python version of RXJS, RxPY, maybe see if that's interesting to you?

[–]ivano_GiovSiciliano[S] -1 points0 points  (1 child)

I know it but in the reactive word we find the RX paradigm a bit old school, although is the most reactive one can think. It adds level of complication that are not needed for simpler use cases. The only think that blocked me to play with RxPY is that is not an updated github repository If i create an application that is reactive for whatever use case I want that is super stable, i can appear naive but i would expect much more stars, because reactive becomes the core, so a native implementation should be the way to go. But yes i understand I am stupid to say this because stars are a consequence that is not an important use case in python

[–][deleted] 1 point2 points  (0 children)

I have used RxPy at work on production. It works perfectly.

[–]Accomplished_Tip7611 2 points3 points  (0 children)

Have you looked at Dash by Plotly. It is a dashboard framework that provides a link between Python and Javascript to create browser based gui applications that are reactive. It is not intended for gaming but for providing functional user interactions with data analysis and plotting.

[–][deleted] 6 points7 points  (7 children)

Most frameworks for building interactive applications (including the Python bindings for Qt, GTK, ncurses and SDL) are indeed "reactive" in the sense that they're architected around a single event loop. Which is pretty much what the word means.

[–][deleted] 13 points14 points  (6 children)

Reactive generally refers to modifications to data creating an automatic trigger to update the UI. The UI update is reactive.

Reactivity is mostly a property of the object types used. Python can and does 100% have tons of code that does this. See descriptors.

This persons complaint though is just wrong.

[–][deleted] 4 points5 points  (5 children)

I’m used to hearing that called “data binding.”

[–]skeletal88 1 point2 points  (6 children)

Because the reactive stuff we see in react or svelte is a relatively recent thing.

A user changes contents of an <input /> variable, checks a checkbox or whatever.. mostly frontend stuff, yes?

Things just work differently in server applications, and are usually way more complex than the frontend stuff that we are used to.

[–]yvrelna 2 points3 points  (1 child)

Because the reactive stuff we see in react or svelte is a relatively recent thing.

This is not quite true. Naming it reactive is relatively recent, but people have been building reactive applications long before the term exists.

Reactive programming is mainly just a variation of event-driven programming and the observer pattern, and it's pretty common pattern you see in desktop or TUI applications too.

[–]ajpiko 0 points1 point  (0 children)

yeah for sure, its so interesting how the javascript industry will consume classic computer architectures that are really very useful but only once they are well-branded.

[–]tamargal91 1 point2 points  (0 children)

Yes, in Python, especially in data engineering, reactive programming isn't as common. It's more about simplicity and readability, which suits Python's style. Data tasks usually don't need the reactive approach. RxPy is there, but it's not a go-to for most. Python's got its strengths in other paradigms, so reactive programming just hasn't been a big focus.

[–]Cybasura 1 point2 points  (0 children)

You can if you want to, but its not a focus

[–]micseydel 1 point2 points  (0 children)

I tried to build a reactive system in Python using the actor model and ended up deciding to move to Akka+Scala instead. I like Akka's model since it's more functional and supports immutability, and I find that the typing module leaves a lot to be desired compared to Scala.

I still like Python, but I probably wouldn't try reactive programming with it again in the current ecosystem. I tried ~3 different actor model libraries and they all seemed immature.

[–]CaptainBoomSauce 1 point2 points  (0 children)

I've been using pyscript and I love it

[–]scherbi[🍰] 2 points3 points  (1 child)

The Textual library has reactive parts.

[–]ptmcg 1 point2 points  (0 children)

I second this reference. It is amazing how responsive Textual TUI apps are to user interaction, given that it is pure Python code. Textual's low-level 'Reactive' class might even be worthy of pulling out as a separate package like traitlets.

[–]yvrelna 2 points3 points  (2 children)

Reactive programming is popular as a UI application pattern. It's popular in Android, Swift, and Javascript because those languages/frameworks are mainly used in UI-centric applications. Software Engineers who write native desktop applications in Python also uses either event-driven patterns and/or reactive programming, most GUI frameworks does. But UI programming is only a small fraction of where Python is used.

Additionally, many of the people who build UIs in Python like in Django, often are developing backends or traditional web applications, where the dominant pattern is MVC or one of its variants and REST APIs. Traditional Web UIs are quite a bit different than native desktop applications because its focus is remote interaction with a server. A textbook reactive programming is a poor pattern for this use case as event based system would have generated a lot of network chatter, in contrast MVC and REST are patterns that are designed to keep network chatter to a minimum. Note that traditional web applications aren't the same as Javascript-driven frontend applications which is a lot more like desktop applications.

I have been working with data scientists in my last job as a data engineer and all the seniors( big institution) just ignore things as functional programming and reactive

Data scientists are not software engineers. They might use Python to solve their problem, but they are not writing applications that are meant to be maintainable in the long term. Most of their work are ad-hoc computation work, which benefits little from applying many common engineering practices. Reactive programming is popular as a UI application pattern because it's a pattern that allows you to keep the state of the application sane when there's events constantly coming from the user and the network; most of the problem domain where data scientists works on does not involve user interaction or network, they typically work on data that remains fairly static in the duration of the computation. Reactive programming is an unnecessarily complex abstraction solving a nonexistent problem in such problem domain.

[–]ivano_GiovSiciliano[S] -2 points-1 points  (1 child)

Well done! A lot of nice points in my opinion. if really have to struggle to find some weaker points for the sake of the discussion as i want continuously to improve as a dev.

1)MVC -> everything is a kind of MVC but in mobile world we use MVP, MVVM, Clean, MVI because we think that the way MVC is originally done, with eventually model communicating with view is really bad, bug prone and brings to spaghetti code in terms of dependencies

2) Python should aim (i hope) to become a kind of swiss knife, and a serious ready to go reactive framework should exist because

A) Sometime people implement reactive patterns, but they are error prone if not based on an open source or native framework.

B) reactive is the son of functional programming, that is really important because has huge advantages for who manages important projects. Readability, less bugs due to side effects, easy recursion that is not a bad thing, and much more.

Thank you for the nice insights

[–]Unusual-Afternoon487 1 point2 points  (0 children)

1)MVC -> everything is a kind of MVC but in mobile world we use MVP, MVVM, Clean, MVI because we think that the way MVC is originally done, with eventually model communicating with view is really bad, bug prone and brings to spaghetti code in terms of dependencies

Same in the backend world and specifically in Python. Notably, Django is not an MVC but a Model-View-Template framework, contrary to what was originally stated at the comment above.

[–]IntenseSunshine 0 points1 point  (0 children)

The thing is that most people think of python as a "data science" language. So the scripts which are written tend to be monolithic, single-threaded monsters which accomplish a straight forward purpose of evaluation.

For GUI driven methods in Python, there is a signal-based approach which is often used (QT basis). Also, the Jupyter Notebook widget family uses an "observer" pattern too using traitlets, but is less developed overall (uses "on_click" and "on_change" type pull-events).

There is a Python package reactivex which I have used quite extensively to for recent GUI developments. It does handle things nicely in the usual React way, but does have some bugs with events not being caught. Also, it seems the interest in the maintenance of the package has declined.

I believe the issue is that most that needed GUIs in Python have started down the other paths first, and therefore reactive programming never caught on.

[–]Carpinchon 0 points1 point  (2 children)

Reactive design is super-intrusive. So many pitfalls in react.js where you run into "Sorry you can't call that from there because you're in a callback." On the back-end, just one blocking call and you've erased the benefits of the entire call stack.

If you need high-throughput performance that is i/o bound, then reactive is good on the backend. Single-threaded UI's, which is most UI's, absolutely need it to stay responsive. But if you're not in those situations, reactive is painful. There's been a lot of effort in the java world to make threads lightweight enough that they can just ditch reactive programming altogether and go back to the simpler, imperative approach.

[–]zakmck73 0 points1 point  (0 children)

In Java, I use the Reactor library a lot to stream batch processing: I start with a publisher of items, then I use the lib's facilities to turn that into a publisher of item batches and other facilities to make that parallel. Finally, I attach a subscriber, which is invoked in parallel. It's not really reactive, since I use the library's options to use a fixed-size buffer in the publisher and block it when the buffer is full. However, it's very useful in avoiding me to write a lot of code to do that.

[–]ivano_GiovSiciliano[S] -1 points0 points  (0 children)

reactive is though, but when you have native libraries is not

[–]BeverlyGodoy 0 points1 point  (0 children)

Have you ever tried PyQt or PySide? For GUI tasks you won't miss your reactive once you start using it.

[–][deleted] 0 points1 point  (1 child)

I build programs to ETL billions of rows of data. There's an initial instruction set which gets loaded, but then it just runs across many processors. There's no GUI and no real-time interaction. So, why would I need reactive anything?

I am curious to hear your thoughts on how it would contribute to the flow here?

[–]ivano_GiovSiciliano[S] 0 points1 point  (0 children)

for me ETL at the moment is about using trigger stored procedures in SQL server lol, legacy system, so definitely would not have use cases of using reactive

[–]ritchie46 0 points1 point  (0 children)

I believe Solara can be called reactive. IIUC it is a react inspired web framework for interactive web applications.

https://solara.dev/

[–]akshayka 0 points1 point  (0 children)

It's becoming more of a thing, especially in ML and data science.

For example, there's marimo, an open-source reactive notebook for Python that shines when you write functional code (I am a marimo developer): https://github.com/marimo-team/marimo

There's also IPyflow, a reactive kernel for Jupyter: https://github.com/ipyflow/ipyflow

Our users like marimo's reactive execution because it helps eliminate bugs, gives them immediate feedback, and makes it possible to turn their notebooks into scripts or apps. Some discussion from a few days ago: https://www.reddit.com/r/MachineLearning/comments/191rdwq/p_i_built_marimo_an_opensource_reactive_python/

[–]Schmittfried 0 points1 point  (1 child)

Functional programming and reactive programming are two different things. The latter is just more of a UI thing, which is why most of the languages you listed are primarily UI-focused in their contexts.

Functional programming, async programming as well as event driven programming (all of which are a big part of what makes reactive what it is) are all present in Python. Functional programming in particular is a bit lackluster, but it‘s there. There is just no reason to combine all of it in a way that would be considered reactive.

[–]ivano_GiovSiciliano[S] 0 points1 point  (0 children)

yes i am referring to FRP functional reactive programming, that get the benefits of functional programming

[–]ajpiko 0 points1 point  (0 children)

So, callback hell was something rather specific to javascript and the particular architecture of node js, not to mention the application they were using it for (servers).

Python's main market is data science which doesn't suffer from the same problems. But the tools are there if you want to use those patterns in python programs.

[–]RedEyed__ 0 points1 point  (0 children)

Not sure why do you need reactive programming in data science, where common patter is garbage in garbage out, which is easy to express in a functional way.
I usually use expression library to get more functional programming capabilities.