3 ms·

> Have you ever hunted bugs caused by accidentally using a global variable in a function in a Jupyter notebook? Nope! > Have you ever scratched your head beca

> Have you ever hunted bugs caused by accidentally using a global variable in a function in a Jupyter notebook? Nope! > Have you ever scratched your head because your code broke after restarting the Python kernel? Also nope! I'm technically a data scientist but I don't use notebooks very often. Even when I did, though, I can't recall having this error very often. Is this really necessary? Anyway, this kind of thing is only useful if people adopt it. The people who are likely to install this tool and use it probably already avoid this issue while the people who have this issue will never hear of this tool or will not consistently employ it. I guess I'm just salty from years of dealing with people who give their Python code half-hearted incorrect type hints but never run a static type checker on their code.

codetrotter 2y ago
> Anyway, this kind of thing is only useful if people adopt it. The people who are likely to install this tool and use it probably already avoid this issue while the people who have this issue will never hear of this tool or will not consistently employ it. I could see projects adopting this, or something like it, in their CI pipelines. Both for open source projects, but also at companies with a lot of internal repositories with Python code – especially if it is common that other people with little experience for some repo contribute code to it. In the case of an open source project if it’s a popular repo that a lot of people are users of and different people frequently contribute to for the first time. And in the case of company internal repositories, if it’s code that different teams only touch now and then, with only a smaller group of people intimately familiar with all of the inner workings of the code and the other people being mainly focused on other repos in the company but still having to sometimes contribute changes because their code is relying on the code in that other repos.

codetrotter 2y ago

> Anyway, this kind of thing is only useful if people adopt it. The people who are likely to install this tool and use it probably already avoid this issue while the people who have this issue will never hear of this tool or will not consistently employ it. I could see projects adopting this, or something like it, in their CI pipelines. Both for open source projects, but also at companies with a lot of internal repositories with Python code – especially if it is common that other people with little experience for some repo contribute code to it. In the case of an open source project if it’s a popular repo that a lot of people are users of and different people frequently contribute to for the first time. And in the case of company internal repositories, if it’s code that different teams only touch now and then, with only a smaller group of people intimately familiar with all of the inner workings of the code and the other people being mainly focused on other repos in the company but still having to sometimes contribute changes because their code is relying on the code in that other repos.