Latest Contributions by DavidSolari

I figured I'd use this as way to not only fix your script tool, but demonstrate some common newbie Python mistakes and a way to fix them. This isn't a condemnation of your skills or anything, I too was a new programmer once! Anyways:   import arcpy from os import path from csv import writer from typing import Iterable, Iterator def get_rows(dataset: str) -> Iterator[tuple[str, str, str, str]]: """ Yield the workspace name, dataset name, feature class name and feature count for every feature class in a dataset. """ workspace, dataset_name = path.split(dataset) # EnvManager doesn't work, save and restore workspace like this old_workspace = arcpy.env.workspace arcpy.env.workspace = workspace for feature_class in arcpy.ListFeatureClasses(feature_dataset=dataset_name): name = feature_class.split(".")[-1] count = arcpy.management.GetCount(feature_class)[0] yield workspace, dataset_name, name, count arcpy.env.workspace = old_workspace def main(datasets: Iterable[str], output: str): """ Write a table of feature counts from the selected datasets. """ with open(output, "w", newline="") as f: csv_writer = writer(f) csv_writer.writerow(("Geodatabase", "DataSet", "FeatureClass", "NumFeatures")) for dataset in datasets: for row in get_rows(dataset): csv_writer.writerow(row) def execute(params: list[arcpy.Parameter]): datasets = params[0].valueAsText.split(";") output = params[1].valueAsText main(datasets, output) if __name__ == "__main__": execute(arcpy.GetParameterInfo())   Now for the notes: I've split this script into roughly 3 parts: main, execute and the "main guard". The main function is where the real work starts, but all parameters are expressed as standard Python data types. The execute function translates a list of Parameter objects into standard Python objects and calls main; this would also set derived outputs using values returned from main if that were useful. This separates "doing the work" from "dealing with parameter objects" which makes it easier to reason about your code. Finally, the "main guard" will check if this script is being executed directly and will pass all parameters as a list of Parameter objects into execute, kickstarting the process. This means I can independently test the main function by, say, replacing that last line with a direct call to main, which lets me use a Python IDE like Visual Studio Code and its debugger without any hassle. The lesson in short: try to apply a separation of concerns to your code and it'll be easier to write, test, rewrite etc. Use type annotations whenever you can! Pro 3.3 has pretty good type hints for arcpy now so applying hints to your own code will let you run type analysis through an IDE. This isn't a big issue for a small script like this, but if your code gets into the thousands of lines range they can save a ton of headaches. In this example I used some imports from the "typing" module to make my types more generic, sticking to the standard types like "list[str]" is perfectly fine if you're just getting into this. Speaking of imports, Python has a massive standard library and Pro comes with dozens of third-party packages to leverage. Here I'm using two standard modules: "os.path" to handle path string manipulation and "csv.writer" to write CSV data without worrying about text formatting, escape codes etc. etc. Thanks to this the multiple file write calls in your original example have been condensed to one foolproof call per feature class. Your original tool had separate parameters for the workspace and the feature datasets. I tried this myself and discovered that it doesn't play well with the parameter's data types. The script above just has one parameter for a list of feature datasets. All the user has to do is use the file picker that comes with the parameter definition and the tool gets a list of full dataset paths which we can easily extract the workspace and dataset name from using "os.path.split". The lesson: try to work with the various parameter types as best you can, you'll discover with practice which ones are helpful and which ones are not. The stuff I'm doing with the environment workspace is very hacky, unfortunately my copy of Pro has a bug with the new EnvManager context manager object so I have to write it this way to temporarily set the workspace. That said, in general you should not overwrite environment variables in your script unless it's 100% necessary, and if you do try to restore the old value. These variables are set by the user and it's expected that all tools will honor their values. My version of the script has exactly three comments: the docstring for the main function, the docstring for get_rows, and an aside for that EnvManager workaround. As counter-intuitive as it may seem, your code should strive to have as few comments as possible. This is an extremely common new programmer mistake that seems to be drilled into people's heads, mostly by teachers and administrators who either write very little code or are applying obsolete doctrine. Comments do not make your code do the correct thing: your code does that. Excess comments can obscure mistakes very easily and make your code difficult to read. If you've written a block of code and feel it needs to be documented, extract that code into a function and write a docstring like I've done here. Save your "#" comments for hacky workarounds, complex chains of logic and other nuances that can't be expressed in the function's docstring. Whoops, wrote a whole essay! Hope this provided some guidance for your future work, if anyone takes umbrage with these tips please reply, I'm sure I'm making some mistakes of my own. ... View more

If you rewrite that list comprehension expression as a standard for loop does it produce a better traceback? ... View more