Live data from Hacker News

JupyterLab 4.0

blog.jupyter.org

191–199 of 199 posts

Re: JupyterLab 4.0

#192

Earlier quoted context omitted.

I must be missing something because I am not immediately seeing the value-add. Do you prefer the separation of input/output or is it something else. I believe all of the debug, extensions, and hinting work the same as the standard notebook.

I'm glad you asked, because you made me think about why. Initially, I guess I just thought it was kinda neat and stuck with it, but on reflection this is what I personally feel I get out of it: - Same interface for analysis, scripting, and building more complex multi-file pipelines. I can also use the #%% notation to break up and debug scripts, which is probably teaching me all sorts of bad habits but it's something…

I am torn on the separation of the output from input. I expect half the time I would be happy for the extra vertical space and the other half I world be annoyed I could not immediately correlate code with output.

Anyway, thanks for spreading the workflow, and I will definitely try it out in the coming weeks.

Re: JupyterLab 4.0

#193
post #87

Earlier quoted context omitted.

Pycharm's notebook debugger is top notch, but their notebook implementation is, imo, clunky and slow.

Give it another shot if you haven't recently. I was a hardcore Jupyter Lab user and PyCharm pulled me away with their recent updates. Same hotkeys, good integrated tool support. The VS Code implementation of notebooks has too much vertical space for me.

I'll try then! Last I remember they had some weird variable loading policy: even under small cell executions there'd be noticable delay before variables got 'refreshed', even when lazy loading was configured. Maybe only a problem on my end though.

Re: JupyterLab 4.0

#194
post #47

I have been using VSCode notebooks with .ipynb file extensions, this gives me many advantages as I am able to configure things I'm not able in JupyterLab. I also have access to a very rich ecosystem of plugins. If there is anyone aware of VSCode as a solution but keeps using JupyterLab, could they explain why?

I too use VS Code as my Jupyter platform (running remotely on a powerful EC2 instance with 32 CPUs and 256GB RAM — my own desktop is a 7 year old Intel core i7 with 8GB RAM). VS Code’s Remote extension is amazing, works over any SSH host and seamlessly blends local and remote. It’s also fast since the UI is local while the filesystem and execution is remote. The experience is a lot better than JupyterLab (which I am…

That sounds amazing. I am going to try this today. I have been irrational to the point of not trying this because I just love the notebook so much even though I love VS Code too. I imagine you just would never go back to notebooks.

That is nice the company pays for all that cloud compute but for an individual it would just seem more practical to build a beast of a machine.

Re: JupyterLab 4.0

#195

Earlier quoted context omitted.

> And as far as I know you can't even spread docstrings out over the body of a functions, I really feel like you do not understand what a docstring is. This does not make any sense. > the way you could if you broke the function up into cells If your logic is broken up across cells then you cannot use it anywhere but in that notebook...

I realize you think the problem is that I don't understand what docstrings are, but it's more that you don't understand the sorts of documentation I'm talking about. docstrings are fine for a certain type of limited documentation that is formatted to prevent syntax errors. But they are extremely limited. Reading docstring/doxygen style documentation is the slowest and most error prone in my experience. Particularly w…

I do all of my code in notebooks. If your docstring is slow to read, it is a bad docstring. To be clear, a docstring is the thing you get when you have a function, you don't know what it does, and you press shift tab to bring up the brief description of what it does in a pop up (in jupyter lab). It should be the quickest, least error prone form of documentation because it is available on demand and is supposed to be short.

Using notebooks as functions is a bad idea. I think papermill is trash.

Notebooks are good for illustrating what you did and what you got. They are not good for illustrating how you did it.

Re: JupyterLab 4.0

#196
post #177
post #149

Earlier quoted context omitted.

32 vCPU / 256 GB instances like r6a.8xlarge is about $900/month (r6ad which has local disk is about $100/month more), I don't see there being much other major costs with such setup?

Unlike individuals, large enterprises rarely pay sticker price but a heavily discounted negotiated rate for software and services. I can’t say how much exactly but it’s less than that.

With respect to EDP, AWS doesn't do "discounted negotiated rates", only discounts tied to specific committed spend levels (non-negotiated).

Re: JupyterLab 4.0

#197
post #45

I've been using Jupyter Notebooks for 7+ years but keep failing to find a use case for JupyterLab. JupyterLab feels like a clunky web based IDE. I check it every year or so and go back to Notebooks. I used to and still run a Littlest Jupyter Hub: https://tljh.jupyter.org/en/latest/ for my org. I keep thinking whether migrating to full blown JupyterLab is worth the pain. With the improvements that Visual Studio Code h…

I've been using Jupyter Lab for ages now since it had a dark mode and Notebooks didn't. It's been so many years though maybe that has changed by now and I haven't noticed.

Re: JupyterLab 4.0

#198

I like my repl. Can anyone tell me whether these notebook things are an improvement? They look a little like a repl instance with a history tracking how you got there which seems like a potential upgrade.

As you guessed, the history tracking is one of the killer features. Imagine it being super easy to edit the history of a REPL session (delete, reorder, merge, and edit contents of each command) and rerun... That's a notebook! Notebooks also allow for markdown input and rich HTML output (which is killer for plotting) making it possible to polish your REPL history into a document you'd actually want to share with a colleague to explain something like a data analysis workflow.

I actually started in notebooks and then learned to love the REPL as a simplified "scratchpad notebook." I'd say in many ways notebooks are an improvement that cater heavily to REPL-lovers, but that for some quick tasks, the extra complexity isn't always worth it.

Re: JupyterLab 4.0

#199

Earlier quoted context omitted.

I realize you think the problem is that I don't understand what docstrings are, but it's more that you don't understand the sorts of documentation I'm talking about. docstrings are fine for a certain type of limited documentation that is formatted to prevent syntax errors. But they are extremely limited. Reading docstring/doxygen style documentation is the slowest and most error prone in my experience. Particularly w…

I do all of my code in notebooks. If your docstring is slow to read, it is a bad docstring. To be clear, a docstring is the thing you get when you have a function, you don't know what it does, and you press shift tab to bring up the brief description of what it does in a pop up (in jupyter lab). It should be the quickest, least error prone form of documentation because it is available on demand and is supposed to be…

It truly is fascinating that you continue to insist that I don't know what a docstring is. Notebooks are good for certain things and not good for others. This conversation is going nowhere.
Post reply on HN