pith. sign in

arxiv: 2606.23877 · v1 · pith:NRZOSFTFnew · submitted 2026-06-22 · 💻 cs.SE · cs.AI

JupOtter: Cell-Level Bug Detection in Jupyter Notebooks

Lukas Ottenhof , Thibaud Lutellier This is my paper

Pith reviewed 2026-06-26 06:59 UTC · model grok-4.3

classification 💻 cs.SE cs.AI
keywords Jupyter Notebooksbug detectioncell-level predictionOtterDatasettokenizationstatic analysislarge language modelssoftware engineering
0
0 comments X

The pith

JupOtter detects bugs at the cell level inside Jupyter notebooks and beats static analyzers plus large language models on two of three test sets.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper presents JupOtter as a bug-detection system built for Jupyter Notebooks that labels individual cells rather than entire files. It relies on a tokenization step that keeps cell boundaries visible, a prediction model trained to output cell-level bug flags, and a new dataset of more than 21,000 notebooks with fine-grained annotations. A reader would care because notebooks are now used for serious programs yet remain hard to debug with existing tools. The reported results show higher F1 scores than the baselines in most evaluated cases, suggesting the cell-level approach can locate errors more precisely in interactive data-science code.

Core claim

JupOtter features a notebook-specific tokenization strategy that preserves cell structure, a cell-level bug prediction technique, and the OtterDataset containing over 21,000 notebooks annotated for fine-grained cell-level bug detection; with these it achieves cell-level bug detection F1 scores that surpass static analyzers and large language models in two out of three evaluation datasets.

What carries the argument

Notebook-specific tokenization that preserves cell structure, which supplies the cell boundaries needed for the cell-level bug prediction technique.

If this is right

  • Bug reports can be tied directly to specific cells instead of whole notebooks, narrowing the scope of fixes.
  • The same tokenization and prediction steps can be reused to train models on additional notebook corpora.
  • Platforms that host notebooks could run cell-level checks before public sharing to reduce buggy examples.
  • Data-science pipelines that interleave code and results become easier to audit at the granularity where errors actually occur.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The cell-boundary tokenization might transfer to other notebook formats or literate-programming tools that share a similar cell structure.
  • If the method scales, it could support incremental checking while a user edits a notebook rather than only after the fact.
  • The existence of a large labeled cell-level dataset opens the door to comparing many different model architectures on the same benchmark.

Load-bearing premise

The OtterDataset supplies accurate and representative cell-level bug annotations that support reliable training and evaluation.

What would settle it

An independent re-annotation of a held-out portion of OtterDataset that produces substantially different cell labels and causes JupOtter's F1 advantage to disappear on the same test sets.

Figures

Figures reproduced from arXiv: 2606.23877 by Lukas Ottenhof, Thibaud Lutellier.

Figure 1
Figure 1. Figure 1: Overview of JupOtter, a bug detection system for Jupyter Notebooks. Our approach begins with source notebooks whose code cells are first extracted [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Example of a cell-level prediction output. Each cell is processed and [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
read the original abstract

Jupyter Notebooks are an increasingly popular coding environment used across many domains, especially in Python-based data science and scientific computing. Originally used for prototyping and interactive exploration, notebooks are increasingly used to develop more complex programs, leading to a rapid rise in buggy notebooks on platforms like GitHub. To address this trend, we present JupOtter, a bug detection system designed specifically for Jupyter Notebooks. JupOtter features three novel contributions: (1) a notebook-specific tokenization strategy that preserves cell structure, (2) a cell-level bug prediction technique, and (3) a new labeled dataset, OtterDataset, containing over 21,000 notebooks annotated for fine-grained cell-level bug detection. JupOtter achieves cell-level bug detection F1 scores that surpass static analyzers and large language models in two out of three evaluation datasets.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 1 minor

Summary. The paper presents JupOtter, a bug detection system for Jupyter Notebooks that includes a notebook-specific tokenization preserving cell structure, a cell-level bug prediction technique, and the OtterDataset (over 21,000 notebooks with cell-level bug annotations). It claims that JupOtter achieves cell-level F1 scores surpassing those of static analyzers and large language models on two of three evaluation datasets.

Significance. If the evaluation holds, the work addresses a practical need in data science and scientific computing by targeting bug detection at the cell granularity common in notebooks; the released dataset could serve as a community resource for further research on notebook-specific analysis.

major comments (2)
  1. [Abstract] Abstract: the headline claim of superior cell-level F1 performance over static analyzers and LLMs on two of three datasets supplies no information on evaluation methodology, baseline implementations, dataset splits, statistical significance testing, or potential confounds, rendering the claim impossible to assess from the provided text.
  2. [Dataset section] OtterDataset construction (section describing data collection and annotation): no details are given on how cell-level bug labels were produced, including labeling criteria at cell granularity, who performed the annotations, or any validation such as inter-annotator agreement statistics; without this, the F1 superiority result cannot be distinguished from artifacts of noisy or subjective ground truth.
minor comments (1)
  1. Clarify whether the tokenization strategy and cell-level prediction are positioned as incremental improvements or as fundamentally new techniques relative to prior notebook analysis work.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive comments. We address each major comment below and indicate planned revisions to the manuscript.

read point-by-point responses

  1. Referee: [Abstract] Abstract: the headline claim of superior cell-level F1 performance over static analyzers and LLMs on two of three datasets supplies no information on evaluation methodology, baseline implementations, dataset splits, statistical significance testing, or potential confounds, rendering the claim impossible to assess from the provided text.

    Authors: We agree the abstract is concise by design and omits methodological specifics. The full evaluation methodology, baseline details, dataset splits, and statistical tests appear in Sections 4 and 5. To improve standalone readability we will revise the abstract to briefly reference the evaluation setup and the three datasets. revision: yes

  2. Referee: [Dataset section] OtterDataset construction (section describing data collection and annotation): no details are given on how cell-level bug labels were produced, including labeling criteria at cell granularity, who performed the annotations, or any validation such as inter-annotator agreement statistics; without this, the F1 superiority result cannot be distinguished from artifacts of noisy or subjective ground truth.

    Authors: We concur that annotation details are required to support the validity of the results. The current manuscript lacks these specifics. We will expand the OtterDataset section with labeling criteria at cell granularity, annotator information, and inter-annotator agreement statistics. revision: yes

Circularity Check

0 steps flagged

No circularity: empirical ML evaluation on new dataset

full rationale

The paper is a standard empirical contribution: it introduces OtterDataset with cell-level annotations, describes a tokenization and prediction technique, and reports F1 scores on three evaluation sets. No equations, fitted parameters presented as predictions, self-citations used as load-bearing uniqueness theorems, or ansatzes smuggled via prior work appear in the abstract or described claims. The central result (F1 superiority) is an empirical measurement against external baselines, not a derivation that reduces to its own inputs by construction. The annotation quality concern raised by the skeptic is a correctness/validity issue, not a circularity reduction.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

Only the abstract is available; no free parameters, axioms, or invented entities can be identified from the provided text.

pith-pipeline@v0.9.1-grok · 5672 in / 989 out tokens · 23572 ms · 2026-06-26T06:59:26.627854+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

66 extracted references · 10 canonical work pages · 4 internal anchors

  1. [1]

    Why jupyter is data scientists’ computational notebook of choice,

    J. M. Perkel, “Why jupyter is data scientists’ computational notebook of choice,”Nature, vol. 563, no. 7732, pp. 145–147, 2018

    2018

  2. [2]

    Bug analysis in jupyter notebook projects: an empirical study,

    T. L. De Santana, P. A. d. M. S. Neto, E. S. De Almeida, and I. Ahmed, “Bug analysis in jupyter notebook projects: an empirical study,”ACM Transactions on Software Engineering and Methodology, vol. 33, no. 4, pp. 1–34, 2024

    2024

  3. [3]

    Self-supervised bug detection and repair,

    M. Allamanis, H. Jackson-Flux, and M. Brockschmidt, “Self-supervised bug detection and repair,”Advances in Neural Information Processing Systems, vol. 34, pp. 27 865–27 876, 2021

    2021

  4. [4]

    Defecthunter: A novel llm-driven boosted-conformer-based code vulnerability detection mechanism,

    J. Wang, Z. Huang, H. Liu, N. Yang, and Y . Xiao, “Defecthunter: A novel llm-driven boosted-conformer-based code vulnerability detection mechanism,”arXiv preprint arXiv:2309.15324, 2023

    work page arXiv 2023

  5. [5]

    If llms would just look: Simple line-by-line checking improves vulner- ability localization,

    Y . Li, X. Li, H. Wu, Y . Zhang, X. Cheng, Y . Liu, F. Xu, and S. Zhong, “If llms would just look: Simple line-by-line checking improves vulner- ability localization,”arXiv preprint arXiv:2410.15288, 2024

    work page arXiv 2024

  6. [6]

    A deep dive into large language models for automated bug localization and repair,

    S. B. Hossain, N. Jiang, Q. Zhou, X. Li, W.-H. Chiang, Y . Lyu, H. Nguyen, and O. Tripp, “A deep dive into large language models for automated bug localization and repair,”Proceedings of the ACM on Software Engineering, vol. 1, no. FSE, pp. 1471–1493, 2024

    2024

  7. [7]

    Deepbugs: A learning approach to name-based bug detection,

    M. Pradel and K. Sen, “Deepbugs: A learning approach to name-based bug detection,”Proceedings of the ACM on Programming Languages, vol. 2, no. OOPSLA, pp. 1–25, 2018

    2018

  8. [8]

    Better code, better sharing: on the need of analyzing jupyter notebooks,

    J. Wang, L. Li, and A. Zeller, “Better code, better sharing: on the need of analyzing jupyter notebooks,” inProceedings of the ACM/IEEE 42nd international conference on software engineering: new ideas and emerging results, 2020, pp. 53–56

    2020

  9. [9]

    Exploring the jupyter ecosystem: An empirical study of bugs and vulnerabilities,

    W. Jiang, D. Pressato, H. Darji, and T. Lutellier, “Exploring the jupyter ecosystem: An empirical study of bugs and vulnerabilities,” in2025 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM). IEEE, 2025, pp. 92–103

    2025

  10. [10]

    Codebert: A pre-trained model for programming and natural languages,

    Z. Feng, D. Guo, D. Tang, N. Duan, X. Feng, M. Gong, L. Shou, B. Qin, T. Liu, D. Jianget al., “Codebert: A pre-trained model for programming and natural languages,” inFindings of the association for computational linguistics: EMNLP 2020, 2020, pp. 1536–1547

    2020

  11. [11]

    Codet5: Identifier-aware unified pre-trained encoder-decoder models for code understanding and generation,

    Y . Wang, W. Wang, S. Joty, and S. C. Hoi, “Codet5: Identifier-aware unified pre-trained encoder-decoder models for code understanding and generation,” inProceedings of the 2021 conference on empirical methods in natural language processing, 2021, pp. 8696–8708

    2021

  12. [12]

    GraphCodeBERT: Pre-training Code Representations with Data Flow

    D. Guo, S. Ren, S. Lu, Z. Feng, D. Tang, S. Liu, L. Zhou, N. Duan, A. Svyatkovskiy, S. Fuet al., “Graphcodebert: Pre-training code repre- sentations with data flow,”arXiv preprint arXiv:2009.08366, 2020

    work page internal anchor Pith review Pith/arXiv arXiv 2009

  13. [13]

    Unixcoder: Unified cross-modal pre-training for code representation,

    D. Guo, S. Lu, N. Duan, Y . Wang, M. Zhou, and J. Yin, “Unixcoder: Unified cross-modal pre-training for code representation,” inProceed- ings of the 60th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), 2022, pp. 7212–7225

    2022

  14. [14]

    Deeplinedp: Towards a deep learning approach for line-level defect prediction,

    C. Pornprasit and C. K. Tantithamthavorn, “Deeplinedp: Towards a deep learning approach for line-level defect prediction,”IEEE Transactions on Software Engineering, vol. 49, no. 1, pp. 84–98, 2022

    2022

  15. [15]

    Software defect prediction via convolutional neural network,

    J. Li, P. He, J. Zhu, and M. R. Lyu, “Software defect prediction via convolutional neural network,” in2017 IEEE international conference on software quality, reliability and security (QRS). IEEE, 2017, pp. 318–328

    2017

  16. [16]

    A deep tree-based model for software defect prediction

    H. K. Dam, T. Pham, S. W. Ng, T. Tran, J. Grundy, A. Ghose, T. Kim, and C.-J. Kim, “A deep tree-based model for software defect prediction,” arXiv preprint arXiv:1802.00921, 2018

    work page internal anchor Pith review Pith/arXiv arXiv 2018

  17. [17]

    Linevd: Statement-level vulnerability detection using graph neural networks,

    D. Hin, A. Kan, H. Chen, and M. A. Babar, “Linevd: Statement-level vulnerability detection using graph neural networks,” inProceedings of the 19th international conference on mining software repositories, 2022, pp. 596–607

    2022

  18. [18]

    Untangling knots: Leveraging llm for error resolution in computational notebooks,

    K. Grotov, S. Titov, Y . Zharov, and T. Bryksin, “Untangling knots: Leveraging llm for error resolution in computational notebooks,”arXiv preprint arXiv:2405.01559, 2024

    work page arXiv 2024

  19. [19]

    Github jupyter notebooks dataset,

    CodeParrot, “Github jupyter notebooks dataset,” https://huggingface.co/ datasets/codeparrot/github-jupyter, 2022

    2022

  20. [20]

    P. S. Foundation,Built-in Exceptions, 2024, accessed: February 26, 2025. [Online]. Available: https://docs.python.org/3/library/exceptions.html

    2024

  21. [21]

    Jupotter: Cell-level bug detection in jupyter notebooks, supplementary material,

    L. Ottenhof and T. Lutellier, “Jupotter: Cell-level bug detection in jupyter notebooks, supplementary material,” 2026. [Online]. Available: https://zenodo.org/records/20706524

    work page arXiv 2026

  22. [22]

    A large- scale study about quality and reproducibility of jupyter notebooks,

    J. F. Pimentel, L. Murta, V . Braganholo, and J. Freire, “A large- scale study about quality and reproducibility of jupyter notebooks,” in2019 IEEE/ACM 16th international conference on mining software repositories (MSR). IEEE, 2019, pp. 507–517

    2019

  23. [23]

    Why do machine learning notebooks crash? an empirical study on public python jupyter notebooks,

    Y . Wang, W. Meijer, J. A. H. Lopez, U. Nilsson, and D. Varro, “Why do machine learning notebooks crash? an empirical study on public python jupyter notebooks,”IEEE Transactions on Software Engineering, 2025

    2025

  24. [24]

    Leveraging locality in abstractive text summarization,

    Y . Liu, A. Ni, L. Nan, B. Deb, C. Zhu, A. Hassan, and D. Radev, “Leveraging locality in abstractive text summarization,” inProceedings of the 2022 Conference on Empirical Methods in Natural Language Processing, 2022, pp. 6081–6093

    2022

  25. [25]

    Linevul: A transformer-based line- level vulnerability prediction,

    M. Fu and C. Tantithamthavorn, “Linevul: A transformer-based line- level vulnerability prediction,” inProceedings of the 19th International Conference on Mining Software Repositories, 2022, pp. 608–620

    2022

  26. [26]

    CodeSearchNet Challenge: Evaluating the State of Semantic Code Search

    H. Husain, H.-H. Wu, T. Gazit, M. Allamanis, and M. Brockschmidt, “Codesearchnet challenge: Evaluating the state of semantic code search,” arXiv preprint arXiv:1909.09436, 2019

    work page internal anchor Pith review Pith/arXiv arXiv 1909

  27. [27]

    Characterising bugs in jupyter platform,

    Y . Tang, H. Cao, Y . Chen, and D. Lo, “Characterising bugs in jupyter platform,” inProceedings of the 29th International Conference on Evaluation and Assessment in Software Engineering, 2025, pp. 136– 146

    2025

  28. [28]

    Bug characteris- tics in open source software,

    L. Tan, C. Liu, Z. Li, X. Wang, Y . Zhou, and C. Zhai, “Bug characteris- tics in open source software,”Empirical software engineering, vol. 19, pp. 1665–1705, 2014

    2014

  29. [29]

    How do bugs surface? a comprehensive study on the characteristics of software bugs manifestation,

    D. Cotroneo, R. Pietrantuono, S. Russo, and K. Trivedi, “How do bugs surface? a comprehensive study on the characteristics of software bugs manifestation,”Journal of Systems and Software, vol. 113, pp. 27–43, 2016

    2016

  30. [30]

    Jupyter notebooks on github: Char- acteristics and code clones,

    M. K ¨all´en and T. Wrigstad, “Jupyter notebooks on github: Char- acteristics and code clones,”The Art, Science, and Engineering of Programming, vol. 5, no. 3, pp. 15–1, 2021

    2021

  31. [31]

    Splitting, renaming, re- moving: a study of common cleaning activities in jupyter notebooks,

    H. Dong, S. Zhou, J. L. Guo, and C. K ¨astner, “Splitting, renaming, re- moving: a study of common cleaning activities in jupyter notebooks,” in 2021 36th IEEE/ACM International Conference on Automated Software Engineering Workshops (ASEW). IEEE, 2021, pp. 114–119

    2021

  32. [32]

    Context-aware execution migration tool for data science jupyter note- books on hybrid clouds,

    R. L. Cunha, L. C. V . Real, R. Souza, B. Silva, and M. A. Netto, “Context-aware execution migration tool for data science jupyter note- books on hybrid clouds,” in2021 IEEE 17th international conference on eScience (eScience). IEEE, 2021, pp. 30–39

    2021

  33. [33]

    Reusing my own code: Preliminary results for competitive coding in jupyter notebooks,

    N. Ritta, T. Settewong, R. G. Kula, C. Ragkhitwetsagul, T. Sunetnanta, and K. Matsumoto, “Reusing my own code: Preliminary results for competitive coding in jupyter notebooks,” in2022 29th Asia-Pacific Software Engineering Conference (APSEC). IEEE, 2022, pp. 457–461

    2022

  34. [34]

    Nalin: learning from runtime behavior to find name-value inconsistencies in jupyter notebooks,

    J. Patra and M. Pradel, “Nalin: learning from runtime behavior to find name-value inconsistencies in jupyter notebooks,” inProceedings of the 44th International Conference on Software Engineering, 2022, pp. 1469– 1481

    2022

  35. [35]

    Assessing and restoring repro- ducibility of jupyter notebooks,

    J. Wang, T.-y. Kuo, L. Li, and A. Zeller, “Assessing and restoring repro- ducibility of jupyter notebooks,” inProceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering, 2020, pp. 138–149

    2020

  36. [36]

    Restoring reproducibility of jupyter notebooks,

    ——, “Restoring reproducibility of jupyter notebooks,” inProceedings of the ACM/IEEE 42nd international conference on software engineer- ing: Companion proceedings, 2020, pp. 288–289

    2020

  37. [37]

    Making the invisible visible in computational notebooks,

    M. V . Merino, L. T. van Binsbergen, and M. Seraj, “Making the invisible visible in computational notebooks,” in2022 IEEE Symposium on Visual Languages and Human-Centric Computing. IEEE, 2022, pp. 1–3

    2022

  38. [38]

    A large- scale comparison of python code in jupyter notebooks and scripts,

    K. Grotov, S. Titov, V . Sotnikov, Y . Golubev, and T. Bryksin, “A large- scale comparison of python code in jupyter notebooks and scripts,” in Proceedings of the 19th international conference on mining software repositories, 2022, pp. 353–364

    2022

  39. [39]

    A comparison of machine learning code quality in python scripts and jupyter notebooks,

    K. Adams, A. Vilkomir, and M. Hills, “A comparison of machine learning code quality in python scripts and jupyter notebooks,”Journal of Computing Sciences in Colleges, vol. 39, no. 5, pp. 96–108, 2023

    2023

  40. [40]

    Eliciting best practices for collaboration with computational notebooks,

    L. Quaranta, F. Calefato, and F. Lanubile, “Eliciting best practices for collaboration with computational notebooks,”Proceedings of the ACM on Human-Computer Interaction, vol. 6, no. CSCW1, pp. 1–41, 2022

    2022

  41. [41]

    Why visualize data when coding? preliminary categories for coding in jupyter notebooks,

    T. Settewong, N. Ritta, R. G. Kula, C. Ragkhitwetsagul, T. Sunetnanta, and K. Matsumoto, “Why visualize data when coding? preliminary categories for coding in jupyter notebooks,” in2022 29th Asia-Pacific Software Engineering Conference (APSEC). IEEE, 2022, pp. 462–466

    2022

  42. [42]

    What’s wrong with computational notebooks? pain points, needs, and design opportunities,

    S. Chattopadhyay, I. Prasad, A. Z. Henley, A. Sarma, and T. Barik, “What’s wrong with computational notebooks? pain points, needs, and design opportunities,” inProceedings of the 2020 CHI conference on human factors in computing systems, 2020, pp. 1–12

    2020

  43. [43]

    Training and evaluating a jupyter notebook data science assistant,

    S. Chandel, C. B. Clement, G. Serrato, and N. Sundaresan, “Training and evaluating a jupyter notebook data science assistant,”arXiv preprint arXiv:2201.12901, 2022

    work page arXiv 2022

  44. [44]

    Natural language to code generation in interactive data science notebooks,

    P. Yin, W.-D. Li, K. Xiao, A. Rao, Y . Wen, K. Shi, J. Howland, P. Bailey, M. Catasta, H. Michalewskiet al., “Natural language to code generation in interactive data science notebooks,” inProceedings of the 61st Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), 2023, pp. 126–173

    2023

  45. [45]

    Using run-time information to enhance static analysis of machine learning code in notebooks,

    Y . Wang, J. A. H. L ´opez, U. Nilsson, and D. Varro, “Using run-time information to enhance static analysis of machine learning code in notebooks,” inCompanion Proceedings of the 32nd ACM International Conference on the Foundations of Software Engineering, 2024, pp. 497– 501

    2024

  46. [46]

    Deep learning for contextual bug detection and automated fixes in software systems,

    K. Gaddamwar, Y . Srivastava, J. Parashar, R. A. Parmar, A. K. Pandey, and V . S. Kushwah, “Deep learning for contextual bug detection and automated fixes in software systems,” in2024 2nd International Con- ference on Advances in Computation, Communication and Information Technology (ICAICCIT), vol. 1. IEEE, 2024, pp. 624–629

    2024

  47. [47]

    Repaircat: Applying large language model to fix bugs in ai-generated programs,

    N. Jiang and Y . Wu, “Repaircat: Applying large language model to fix bugs in ai-generated programs,” inProceedings of the 5th ACM/IEEE International Workshop on Automated Program Repair, 2024, pp. 58– 60

    2024

  48. [48]

    Astrobug: Automatic game bug detection using deep learning,

    E. Azizi and L. Zaman, “Astrobug: Automatic game bug detection using deep learning,”IEEE Transactions on Games, 2024

    2024

  49. [49]

    Vuldeepecker: A deep learning-based system for vulnerability detec- tion,

    Z. Li, D. Zou, S. Xu, X. Ou, H. Jin, S. Wang, Z. Deng, and Y . Zhong, “Vuldeepecker: A deep learning-based system for vulnerability detec- tion,” inProceedings of the Network and Distributed System Security Symposium. The Internet Society, 2018

    2018

  50. [50]

    Chatdbg: Augmenting debugging with large language models,

    K. H. Levin, N. van Kempen, E. D. Berger, and S. N. Freund, “Chatdbg: Augmenting debugging with large language models,”Proceedings of the ACM on Software Engineering, vol. 2, no. FSE, pp. 1892–1913, 2025

    1913

  51. [51]

    Pynblint: a static analyzer for python jupyter notebooks,

    L. Quaranta, F. Calefato, and F. Lanubile, “Pynblint: a static analyzer for python jupyter notebooks,” inProceedings of the 1st International Conference on AI Engineering: Software Engineering for AI, 2022, pp. 48–49

    2022

  52. [52]

    Pylint - static code analyzer for python,

    PyCQA, “Pylint - static code analyzer for python,” https://pylint.pycqa. org, 2025, version 3.1.0, accessed July 2025

    2025

  53. [53]

    Pyflakes - static code analyzer for python,

    P. Frost and contributors, “Pyflakes - static code analyzer for python,” https://github.com/PyCQA/pyflakes, 2025, version 3.2.0, accessed July 2025

    2025

  54. [54]

    Sonarqube,

    SonarSource, “Sonarqube,” https://www.sonarqube.org, 2024, version 10.4, accessed July 2025

    2024

  55. [55]

    A static analysis framework for data science notebooks,

    P. Suboti ´c, L. Miliki ´c, and M. Stoji ´c, “A static analysis framework for data science notebooks,” inProceedings of the 44th International Conference on Software Engineering: Software Engineering in Practice, 2022, pp. 13–22

    2022

  56. [56]

    PyCQA, “Flake8,” https://flake8.pycqa.org/, 2025

    2025

  57. [57]

    Deep semantic feature learning for software defect prediction,

    S. Wang, T. Liu, J. Nam, and L. Tan, “Deep semantic feature learning for software defect prediction,”IEEE Transactions on Software Engineering, vol. 46, no. 12, pp. 1267–1293, 2018

    2018

  58. [58]

    Explain- able software defect prediction: Are we there yet?

    J. Shin, R. Aleithan, J. Nam, J. Wang, and S. Wang, “Explain- able software defect prediction: Are we there yet?”arXiv preprint arXiv:2111.10901, 2021

    work page arXiv 2021

  59. [59]

    Continuous software bug prediction,

    S. Wang, J. Wang, J. Nam, and N. Nagappan, “Continuous software bug prediction,” inProceedings of the 15th ACM/IEEE International Sym- posium on Empirical Software Engineering and Measurement (ESEM), 2021, pp. 1–12

    2021

  60. [60]

    Codet5+: Open code large language models for code understanding and generation,

    Y . Wang, H. Le, A. Gotmare, N. Bui, J. Li, and S. Hoi, “Codet5+: Open code large language models for code understanding and generation,” in Proceedings of the 2023 conference on empirical methods in natural language processing, 2023, pp. 1069–1088

    2023

  61. [61]

    Code Llama: Open Foundation Models for Code

    B. Roziere, J. Gehring, F. Gloeckle, S. Sootla, I. Gat, X. E. Tan, Y . Adi, J. Liu, R. Sauvestre, T. Remezet al., “Code llama: Open foundation models for code,”arXiv preprint arXiv:2308.12950, 2023

    work page internal anchor Pith review Pith/arXiv arXiv 2023

  62. [62]

    Learning and evaluating contextual embedding of source code,

    A. Kanade, P. Maniatis, G. Balakrishnan, and K. Shi, “Learning and evaluating contextual embedding of source code,” inInternational conference on machine learning. PMLR, 2020, pp. 5110–5121

    2020

  63. [63]

    Unified pre- training for program understanding and generation,

    W. Ahmad, S. Chakraborty, B. Ray, and K.-W. Chang, “Unified pre- training for program understanding and generation,” inProceedings of the 2021 conference of the North American chapter of the association for computational linguistics: human language technologies, 2021, pp. 2655–2668

    2021

  64. [64]

    Distilkaggle: A distilled dataset of kaggle jupyter notebooks,

    M. Mostafavi Ghahfarokhi, A. Asgari, M. Abolnejadian, and A. Hey- darnoori, “Distilkaggle: A distilled dataset of kaggle jupyter notebooks,” inProceedings of the 21st International Conference on Mining Software Repositories, 2024, pp. 647–651

    2024

  65. [65]

    Kgtorrent: A dataset of python jupyter notebooks from kaggle,

    L. Quaranta, F. Calefato, and F. Lanubile, “Kgtorrent: A dataset of python jupyter notebooks from kaggle,” in2021 IEEE/ACM 18th Inter- national Conference on Mining Software Repositories (MSR). IEEE, 2021, pp. 550–554

    2021

  66. [66]

    vikp clean notebooks filtered,

    V . Paruchuri, “vikp clean notebooks filtered,” https://huggingface.co/ datasets/vikp/clean notebooks filtered, 2023

    2023