Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JupyterLab 4.0

blog.jupyter.org

Post reply on HN
Print view View original

181–190 of 199 posts

Re: JupyterLab 4.0

#181

Post by specproc »

akkad33 wrote: post #162
specproc wrote: post #67

Earlier quoted context omitted.

I've not been back to full-fledged Jupyter since getting in to VSCode. Most of my analytical work now is done in .py files, broken up into blocks with `#%%`. Real notebooks feel really clunky since adopting the approach.

Do you find it clunky that with cells inside py files the results appear to the right? It reduces a lot the screen real estate

I guess this is preference.

I like to have the relevant code and output side-by-side, and dislike scrolling past outputs to get at code. Again, pure preference.

My screen copes fine with two tabs and the sidebar hidden most of the time, but more real estate would be nice.

What I'd love would be to pull tabs out into separate windows, like in a browser, and have the Jupyter output and variable inspector on a second screen. If anyone knows a way to do this (not new window) I'd love to hear. Last time I looked seriously this wasn't possible.

Re: JupyterLab 4.0

#182

Post by petemir »

petemir wrote: post #50
rollinDyno wrote: post #22

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 would love to use vs code for notebooks, but I just cannot get the interactive console to work as I would like. Right know I don’t exactly recall the problem, but it had to do with the keyboard shortcuts and running the piece of code in the interactive console. For some reason other shortcuts took precedence, even if I disabled them, so I couldn’t get my code to reliably run on the console.

Well, I resetted my vs code environment in order to start fresh and check if my problem was still there. My issue is that VS Code interactive windows do not share the same "working space" as the cells. I usually use the interactive window to try stuff, which then gets crystallized in the notebooks. The interactive VS Code consoles are disjointed from the notebook, making it a pain to test stuff with already-defined variables and libraries.

Re: JupyterLab 4.0

#183

Post by spywaregorilla »

fluidcruft wrote: post #178
spywaregorilla wrote: post #167

Earlier quoted context omitted.

I don't think it's a huge leap to say your functions are stored in this .py file vs. in a cell above. the magic commands simply allow you to reload the functions automatically without needing to reimport / reload the kernel.

It is a huge gap when the notebook is documentation. Moving functions out either duplicates documentation or separates them. Notebooks are vastly superior for documentation. Extracting functions from notebooks into a py file isn't difficult (see nbdev for example)

Notebooks are good for demonstration, not documentation. They are bad for documentation because you need to put docstrings and comments in the code while desiring to put the same content in the markdown.

Re: JupyterLab 4.0

#184

Post by JonChesterfield »

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.

Re: JupyterLab 4.0

#185

Post by slt2021 »

kzrdude wrote: post #152
enriquto wrote: post #130

Earlier quoted context omitted.

This is exactly what jupytext gives you. The "pairing" is optional (and sometimed confusing). You can just work with .py files as notebooks and never ever see a .ipynb on your disk again. The notebook .py files are just regular python files with comments that can be edited at hand wih any text editor. Thus you can easily collaborate with your local graybeards that will dislike editing text on their web browsers.

What I miss is a notebook launcher button that creates a .py notebook. Don't understand why we don't have that (i could not myself find a way to configure and add it.) I'm not sure why you think it's viable to collaborate with others who don't use jupyter? I mean on any software project, if we don't agree how to compile or run a project, then we usually can't collaborate IMO. Changes become nonsensical (breaking the…

I think collaborating with .py files is easier over git.

I could not find a way how to check-in .ipynb file and let reviewer review code only, and ignore the metadata part

if jupytext will allow me to work in jupyter, check in file to git and create MR and let other people easily see, review and comment my code that would be great

Re: JupyterLab 4.0

#186

Post by fluidcruft »

spywaregorilla wrote: post #183
fluidcruft wrote: post #178

Earlier quoted context omitted.

It is a huge gap when the notebook is documentation. Moving functions out either duplicates documentation or separates them. Notebooks are vastly superior for documentation. Extracting functions from notebooks into a py file isn't difficult (see nbdev for example)

Notebooks are good for demonstration, not documentation. They are bad for documentation because you need to put docstrings and comments in the code while desiring to put the same content in the markdown.

I typically don't find docstrings are particularly useful for documenting an analysis or understanding what a function is doing. Even analyses that are repeated with different data. When you are debugging or reviewing an analysis, the docstrings are the least of your concerns. Validity is far more important.

I would take a notebook that demonstrates what's happening to my data any day over a docstring that may or may not be correct. Particularly if I have to render it in yet a third system to juggle and manually keep in sync.

So we've gone from notebooks to... notebook + py + docstring... I'm sure we can think of another useless layer of indirection to bolt on.

Re: JupyterLab 4.0

#187

Post by spywaregorilla »

fluidcruft wrote: post #186
spywaregorilla wrote: post #183

Earlier quoted context omitted.

Notebooks are good for demonstration, not documentation. They are bad for documentation because you need to put docstrings and comments in the code while desiring to put the same content in the markdown.

I typically don't find docstrings are particularly useful for documenting an analysis or understanding what a function is doing. Even analyses that are repeated with different data. When you are debugging or reviewing an analysis, the docstrings are the least of your concerns. Validity is far more important. I would take a notebook that demonstrates what's happening to my data any day over a docstring that may or may…

> Particularly if I have to render it in yet a third system to juggle and manually keep in sync.

I'm not sure you know what a docstring is if this is your response.

Re: JupyterLab 4.0

#188

Post by fluidcruft »

spywaregorilla wrote: post #187
fluidcruft wrote: post #186

Earlier quoted context omitted.

I typically don't find docstrings are particularly useful for documenting an analysis or understanding what a function is doing. Even analyses that are repeated with different data. When you are debugging or reviewing an analysis, the docstrings are the least of your concerns. Validity is far more important. I would take a notebook that demonstrates what's happening to my data any day over a docstring that may or may…

> Particularly if I have to render it in yet a third system to juggle and manually keep in sync. I'm not sure you know what a docstring is if this is your response.

If you are putting your docstrings in the py and they contain things like equations or figures or images, you have to render them to get the same effect that you would have just reviewing cells in the notebook. And as far as I know you can't even spread docstrings out over the body of a functions, the way you could if you broke the function up into cells. Docstrings are not literate programming.

Re: JupyterLab 4.0

#189

Post by spywaregorilla »

fluidcruft wrote: post #188
spywaregorilla wrote: post #187

Earlier quoted context omitted.

> Particularly if I have to render it in yet a third system to juggle and manually keep in sync. I'm not sure you know what a docstring is if this is your response.

If you are putting your docstrings in the py and they contain things like equations or figures or images, you have to render them to get the same effect that you would have just reviewing cells in the notebook. And as far as I know you can't even spread docstrings out over the body of a functions, the way you could if you broke the function up into cells. Docstrings are not literate programming.

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

Re: JupyterLab 4.0

#190

Post by fluidcruft »

spywaregorilla wrote: post #189
fluidcruft wrote: post #188

Earlier quoted context omitted.

If you are putting your docstrings in the py and they contain things like equations or figures or images, you have to render them to get the same effect that you would have just reviewing cells in the notebook. And as far as I know you can't even spread docstrings out over the body of a functions, the way you could if you broke the function up into cells. Docstrings are not literate programming.

> 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 when you are describing a complex calculation.

> If your logic is broken up across cells then you cannot use it anywhere but in that notebook...

You don't seem to understand how notebooks can be used and processed themselves. They are just data and there are libraries for loading and transforming them. You might check out pydev and papermill to get an idea about this (and maybe also literate programming in general).

Post reply on HN