Replies: 7 comments 6 replies
-
This sounds really useful. I'm thinking about streaming from a mqtt server, but haven't thought about the details. Or maybe wrapping a serial terminal session? |
Beta Was this translation helpful? Give feedback.
-
beside the entry point where we should normalize options such as All I am saying is that WebSockets are already possible via To be clear, I am not opposed, I just struggle to see ourselves re-purposing potentially the whole |
Beta Was this translation helpful? Give feedback.
-
@WebReflection Many Python folk don't know web APIs and having a (thin) wrapper around the built in API would, I believe, be very helpful. The value comes in several ways:
I appreciate you pushing back @WebReflection - you make an important point. But the TL;DR is simply that a whole host of Pythonistas have a blessed Pythonic way to get stuff done. 😃 |
Beta Was this translation helpful? Give feedback.
-
Imo that would be helpful for folks, but I think perhaps we could go a level up and offer a websocket manager to manage connections and handle things for users, but perhaps that could be a bit too opinionated? 🤔 |
Beta Was this translation helpful? Give feedback.
-
IMHO a recipe may be as good as wrapping 'everything'. This is the case even for a pythonic wrapper. IMHO the same work, in terms of examples, needs to be done. Having said that - wrapping aspects like json, bytearray is well worth the effort for ease of use and minimizing implementation errors. As an example I refer to Jeff's recipe for uploading and downloading a file. Could have made special wrapper to do this but actually better to spell out the In fact this is a super useful reference which has been referred to several times to help people with questions about this action. |
Beta Was this translation helpful? Give feedback.
-
Just adding this for posterity since we all agreed during the community call today: I'm definitely +1 on the proposal, keeping the same attention to "levels of abstraction" that considered around |
Beta Was this translation helpful? Give feedback.
-
this MR should address and somehow comply with the proposed solution: #2042 |
Beta Was this translation helpful? Give feedback.
-
Related to #1987 - we should add a consistent and well supported Pythonic means of using web sockets to the
pyscript
namespace. As with our approach tofetch
, we should try to come up with an unopinionated "Pythonic" version of the underlying JS WebSocket API built into the browser.This discussion is so we can arrive at a consensus for a solution before any implementation takes place.
I'd like at least a thumbs up from @WebReflection and others related to PyScript before we implement anything (so we avoid the refactor we did with
fetch
). Prodding @JeffersGlass @fpliger @FabioRosado @madhur-tandon @mchilvers @antocuni for more 👀 on this. 🙏To kick things off, here's a straw man example 😱 that should work in exactly the same way with both Pyodide and MicroPython:
THIS IS A FIRST DRAFT and likely missing things, wrong or clunky. I've tried to add comments to the appropriate MDN docs for the protocol, and highlight where we need to make design decisions - mostly relating to how JS / Python types line up for the sending and receiving of data. My gut feeling is we should do the same Python<->JS translations as per the existing
fetch
API (as discussed from here).Please add feedback, ideas and constructive critique.
Thank you! 👍
Beta Was this translation helpful? Give feedback.
All reactions