I am glad to see this work. That’s surely valuable. TopoToolbox has already been widely used in a wide variety of fields including but not limited to tectonic geomorphology, geology, hydrology, glaciology and even ecology. The previous versions are based on Matlab platform, which may lack the extension with GIS software and landscape evolution modelling packages. This new version developed by Kearney et al. is available for Python, an open-source platform that is supported by e.g. QGIS, landlab … . There is no doubt that the development is at the state of art and will meet the evolving needs of the geoscience community.

I only propose two minor suggestions. 1) What is and how to calculate chi, because this software is widely used and not every reader is familiar with this metric. 2) A shematic showing the function and work flow of TopoToolbox, may be I missed this part. 

This manuscript is well written and no grammar errors.

Over the last 15 years, TopoToolbox has become a valuable and widely used open-source package for topographic analysis. This paper presents a major new release, which adds a Python interface and includes a major restructuring of the software to allow it to support multiple languages. To my mind, this is a very nice contribution. The new capabilities substantially broaden the scope of TopoToolbox and its interoperability with other packages and across languages. The development of a Python interface is especially significant because it allows users to do combined analyses with TopoToolbox and an expanding collection of other Python-language scientific packages, without having to switch between languages or needing a Matlab license. At the same time, retaining the original Matlab interface provides backward compatibility and serves the large Matlab user base in geoscience. Coding the core routines in a shared C library seems like an effective strategy for enabling cross-language capability.

The examples presented in the manuscript nicely illustrate its capabilities. I especially appreciate the thoughtful and comprehensive approach to software testing and quality control. The manuscript is well written, and the figures clearly designed. Pointers to supporting code allow readers to try out the examples for themselves. The authors might also consider saying more about what community involvement looks like in practice, how the software is managed and governed, and how contribution is encouraged and supported (beyond the technical practices of continuous integration and pull requests). I realize, however, that this may go beyond the scope of this paper.

One potential area for improvement would be to explain how code reviews are handled. The manuscript notes that community contributions are encouraged, and that they are done via pull requests. But apart from a passing mention around line 422, nothing further is said about code reviews: who does them, what criteria are used, etc. Adding a few sentences about this would help give readers a sense of what might be involved in making contributions.

Overall, in my view this manuscript is a great example of how geoscience research software should be presented in journal articles. I recommend publication after minor revisions.

Comments keyed to text:

37-49 I appreciate this list of examples of use of TT combined with other software.

115-119 use of contiguous arrays rather than objects is an interesting strategy, and one that is similar to the approach used by the Basic Model Interface, where data handling is kept simple in order to accommodate languages like C and Fortran.

149-155 I'm not totally clear on the platform compatibility issue here. Any compiled library will need to be compiled specifically for a given hardware, so it is only portable in the sense that compilation is possible across different architectures. Is there something special about data-tiling that restricts it to only certain platforms and not others? And why would this not also be an issue for the hardware acceleration frameworks, mentioned? For example, if a particular acceleration requires an NVIDIA GPU, how is that portable? Obviously, this isn't a big deal here, since the point of the discussion is just to note possible future solutions to this problem, but I'm guessing that a little editing in this paragraph could help make the issue clearer for readers.

158-164 Is the automated test suite run on multiple platforms and OS versions?

170 Is snapshot testing the same as what is sometimes called regression testing?

198 metamorphic testing is new to me, and the example helps make it understandable. The authors might consider adding a second example.

214 I tested the chi-map Jupyter notebook, and was able to run it without much difficulty. The only obstacles were (1) I had to install GDAL separately using conda (after trying a pip install and then getting problems related to a missing config file) before successfully pip-installing topotoolbox, and (2) I didn't see an obvious way to download the notebook from the gallery, so I used view source, which works for the notebook but then the auxiliary data file is missing. Consider providing a link to the full set of notebooks and data files for the paper in the Figure 2 caption.

216 missing 'from'

219 missing comma

226 Why the reprojection? Do some algorithms require projected horizontal ground units?

254 This bug is a nice example of the value of metamorphic testing - bravo to the authors for their openness in showing it.

270 This is great example of interoperability!

315 a little more explanation would be helpful here. Is the idea that one package projects the data while the other uses geographic coordinates? Or they both project but with different projections?

322-324 Although I think I understand the gist here, it's not totally clear to me what 'complementary' means in this context, or why the lack of overlap implies signals beyond 1D. Consider re-wording.

362 Not clear what 'original Landlab example' refers to here.

404 Great point - needs to happen!

419 The sentence's subject should really be the developers, not the software itself.

427-9 This sentence confused me at first because it suggests that the hardware and/or OS differences are to blame. But then the next paragraph suggests that it's not this at all but rather seems to be different behavior of rasterio and the MappingToolbox.

449 This reads as if apologizing for a limitation, but I would argue that this is absolutely appropriate. Understanding when/how/where models do or do not approximate the real world is the domain of science, not software development. The key point is that the software enables the science. Further, creating and exploring new models (whether models of processes or of terrain or whatever) is itself a key part of the scientific method. So I don't see the 'unvalidated' nature of software like this as a problem, as long as the scientific status of various algorithms and models (demonstrably accurate vs. provisional best-guess vs. rough approximation with big uncertainties vs. untested speculation, etc.) is clear in the literature and documentation.

Summary:

This manuscript introduces readers to TopoToolbox3, which is a significant advance over the previous version of the open-source software, in that the fundamental architecture has changed, allowing a new Python-based interface and easier integration with other software. The manuscript is exceptionally well-written with only a few typos. Despite the complexity of the topic, particularly for those not familiar with the software, the platforms, or with coding in general, it is still accessible and clear. I have a few suggestions for inclusions and clarifications, but overall, this is an important manuscript and should be published with minor revisions. I offer a few general comments for the authors to consider below, followed by a few line-by-line and figure comments.

General comments:

1. I find manuscripts like this necessarily awkward – a new tool or database clearly requires a formal, peer-reviewed introduction to the community, along with an establishment of the framework and testing protocols and provision a few useful examples, as is done nicely here. But the authors aren’t presenting and interpretating new results, so the traditional background-methods-results-discussion format doesn’t work. To that end, the authors might consider reorganizing the methods and results sections and removing these headings. The format could be 2. Architecture and design decisions, 3. Testing and quality assurance, 4. Practical evaluation of TopoToolbox3 (including both methods and results for the X maps, GraphFlood, metamorphic testing, and integration with Landlab), then 5. Discussion.
2. More on organization, I found that the X maps and metamorphic testing where more clearly assessments, whereas the integration with Landlab and GraphFlood were more about showcasing new capabilities. I would reorder the presentation to follow this progression.
3. More on the awkwardness of trying to cover all angles in a paper like this – I think that the manuscript serves existing TopoToolbox users well. However, I suspect that many potential new users will start with reading this manuscript but will find it overwhelming and not end up finding their way to the how-to-guides and tutorials, or older publications. I would suggest adding a subheading to the introduction on scope, perhaps starting around and including the material at line 67, adding text to that section on what is NOT in scope, including that this manuscript is not intended as a how-to-guide or starting point, but rather an update on an existing tool. The authors can then include appropriate links for where people SHOULD start. Yes, this appears later in the manuscript, but highlighting it in the introduction will, I think, be useful.
4. One pretty significant omission in the manuscript is a consideration of AI. It will be used, that’s just the new reality – by new users trying to figure out how to get started, or for coding or trouble shooting. I would like to see the author’s perspective on how to realistically and productively use AI in conjunction with TopoToolbox. It would also be helpful to have the authors including tips for working with AI and test which AI platforms (Claude, CoPilot, ChatGPT) work best.
5. One aspect I think many users are looking for is better integration between TopoToolbox and ArcGIS or QGIS. This gets teased in lines 35-36, and briefly addressed in line 62, but it does not appear later in the manuscript. The authors make it clear that a QGIS integration is in the works, and obviously this manuscript doesn’t need to wait for that to get finished. What I would suggest is that the authors add a future work section to the end of the discussion that summarizes ongoing work, including GIS integrations, so that readers who might have missed these brief mentions early in the manuscript won’t be left hanging. This is a good opportunity in general for the authors to summarize what other work is planned or already underway, and what is yet to be started but would be good someday. Get people excited about TopoToolbox4, or making their own contributions down the line.
6. Finally, that community contributions piece felt quite unclear to me. This is addressed in lines 416-423, but there it feels like the process is vague and no responsibility is assigned. Which tests serves as a shared repository? The tests are automated? Who integrates them (continuously)? How do contributors make changes? How do they test their changes? How exactly to the tests coevolve with the code? What happens when it is unclear how code should be tested or what properties need to be preserved? Who does the careful code review? A clearer workflow would be helpful and might be more encouraging to community members who are keen to contribute. Perhaps an example could be given.

Specific comments:

• Figure 1: This figure could be cleaned up a little and the color coding could be made more intuitive. For example, perhaps blue for the libtopotoolbox box, and green for pybind11 and MEX, indicating visually that they communicate between the library and MATLAB/Python (by blending blue and green, get it?). I’d love to see different colors for TopoToolbox3 (and a darker shade for the MATLAB related packages) compared to the Python side of the figure (and associated packages). Would it be possible to add workflow arrows or more annotations directly on the figure?
• Line 153: I caught this example here, but there are likely others. Not all users will automatically know which functions or packages go with MATLAB vs. Python. Is the Parallel Computing Toolbox a MATLAB thing? If so, add “in MATLAB” after “Toolbox.” I also found line 145 a difficult to read for similar reasons.
• Line 216: There’s something not quite right here. Add “from” between “computed” and “the”?
• Figure 5: The mismatch between Python- and MATLAB-based X results goes away completely if the raster is reprojected outside of TopoToolbox, right? I didn’t get that from the figure and figure capture alone. This information could be added to the caption, or a second figure with the X analysis run on the externally reprojected raster could be added. I guess I just was looking for more advice on how to deal with problems and the authors do seems to have advice here, but it gets lost if one isn’t paying enough attention. So, add it to the figure.
• Line 337: I think there should be a comma between “ties” and “the”
• Figure 7: The authors could add counterclockwise and clockwise (right?) arrows to c and d respectively to illustrate more clearly how tie-breaking is done differently.
• Line 470: Add a comma after “C”.

In this manuscript Kearney et al. present a new version of TopoToolbox, TopoToolbox 3. TopoToolbox has been widely used in quantitative geomorphology for over a decade, and this latest version extends the toolbox into Python, alongside the original MATLAB, and the development of other programming languages. The manuscript provides an overview of the architecture of the software, followed by some examples comparing outputs from Matlab and Python, and some examples of the enhanced interoperability with other Python software such as Landlab. I somewhat agree with Reviewer 3 that the manuscript is awkward, in that it does not present any new findings or interpretations, but requires peer review. I wonder whether the manuscript may have been better suited to a short communication, as the previous version was, or to a more software specific journal (GMD). Having said that, at this stage I don’t think it would be appropriate to either significantly modify, or move the manuscript elsewhere. Overall, the manuscript is well written and organised and could be published with some minor revisions.

I just have one general comment and a couple of line comments.

General Comment

I appreciate that Python has the advantage of not requiring the MATLAB licence, as described on lines 30-35, and has the advantage of being able to be integrated more easily with other programming languages compared to MATLAB. However, is there a sustainability issue with the Python version, in that it is dependent on a number of libraries for which versions of the library may update or become deprecated over time. Do the authors foresee this being an issue down the line, in a way that it is less of an issue for MATLAB users? A small comment on this trade-off between Python and MATLAB might make a welcome addition to the discussion.

Line Comments:

Line 216-217: Sentence missing a word - Chi is computed using/ with?

Line 237: I didn’t realise you could use plotdz to plot a chi plot, but I realise now it is very simple using the ‘distance’, chi, parameter name/value pair for plotdz (at least in matlab). Maybe this was already said in a blog post, but this could be added to the github documentation of plotdz to make it obvious it can be used for chi plots? Very very minor detail and not necessary to this manuscript, but could be useful!

Figure 4. There is a straight river at around 4280 East and 2720 west that appears to have different chi values. I think this may be an optical illusion to do with the different coloured basemaps – the matlab has a darker hillshade? Could the basemaps be made identical? Or is this difficult/not possible to achieve due to discrepancies in plotting between python and matlab?

Section 3.4 and Figure 8 – The chi plots don’t collapse perfectly in chi space, which they should do on a perfectly simulated landscape. Do you know whether this is caused by the pixel size, numerical diffusion, or the inclusion of a hillslope term?