Improve "Copy Python command" by including parameter names

[PeterKnoop]

The "Copy Python command" capability in the History pane is very helpful. It would be even better if it included the geoprocessing tool's parameter names in the content that it produces.

It is often convenient to experiment with a geoprocessing tool in the Pro GUI, before trying to use the tool in a Notebook or script.  Once one gets the settings right in the GUI, then they can use "Copy Python command" to capture the working version to their Notebook or script. What comes over, however, has no indication of which parameter is which in the tool's argument list. 

It would be very helpful -- especially for those new to Python and ArcGIS -- to have the names included to help one understand which parameter is which. For instance, you might need to tweak a parameter further, and labeling them would help with figuring out which one it is. Or, if you haven't looked at your code in awhile, and don't recall what is what for the tool, then the parameter labels would help you more quickly understand what is going on.

[JoshuaBixby]

Peter Knoop‌, remember to up-vote your own idea.

[PeterWiringa]

Third. I've been adding parameter names into the copied snippets for clarity. Copying a Project (data management) snippet, you might wind up with two long CRS strings. While decipherable, the documentation (? or ?? or web) is necessary in other cases, and we shouldn't have to read them in the first place. Including parameter names in output would help with this.

Parameter names might also prevent right-scrolling. I've run into lengthy raw-string values wider than the notebook window that require me to scroll to the right to see what the value is so that I can understand, or recall, what the parameter is without throwing a ? on the end of the function name and running to learn more.

[MarcSwartz]

Enhanced version of the Geoprocessing History's Copy Python Command

Existing Format  (example return)
arcpy.cartography.AggregatePoints("Multipoint_11", r"C:\00Lidar\LidarProject\LidarProject.gdb\Multipoint_11_AggregatePoint", "10 Feet")

New Parameterized Format (example return)
in_features = "Multipoint_11"
out_feature_class = r"C:\00Lidar\LidarProject\LidarProject.gdb\Multipoint_11_AggregatePoint"
aggregation_distance = "10 Feet"
arcpy.cartography.AggregatePoints(in_features, out_feature_class, aggregation_distance)

This Idea is so obvious.  It enhances usability and adds structure to the Python code.  

[PeterKnoop]

@MarcSwartz take a look at Improve "Copy Python command" by including parameter names . I would suggest adding your helpful example and vote to it.

[MarcSwartz]

As requested.

Enhanced version of the Geoprocessing History's Copy Python Command

Existing Format  (example return)
arcpy.cartography.AggregatePoints("Multipoint_11", r"C:\00Lidar\LidarProject\LidarProject.gdb\Multipoint_11_AggregatePoint", "10 Feet")

New Parameterized Format (example return)
in_features = "Multipoint_11"
out_feature_class = r"C:\00Lidar\LidarProject\LidarProject.gdb\Multipoint_11_AggregatePoint"
aggregation_distance = "10 Feet"
arcpy.cartography.AggregatePoints(in_features, out_feature_class, aggregation_distance)

This Idea is so obvious.  It enhances usability and adds structure to the Python code.  

[DuncanHornby]

I like this idea and thus up voted it but I'm comfortable with what I get from copying a tool to python code. Primarily because I can understand how to read the help file! I don't wish to sound glib about that but being able to decipher parameter order from reading the help file has become second nature (OK it took years for the light bulb above my head to light up but I can now dive in/out of the help file without much effort). This is in no part due to the great efforts of ESRI for maintaining a comprehensive help file (including any of it's frustrating nuances).

What might be a tweak to this idea is that it becomes an option to tick on/off in the ArcPro settings? For the users who would like the parameter names included tick it on, for the rest tick it off. Question then leads to which should be the default option... 😀

[DrewFlater]

This has been developed in ArcGIS Pro 3.1. Here is the new syntax that will copied to the clipboard when using the various Copy Python Command options. 

arcpy.management.CalculateField(
    in_table="main.random",
    field="testfield",
    expression="200",
    expression_type="PYTHON3",
    code_block="",
    enforce_domains="NO_ENFORCE_DOMAINS"
)

As we feel this syntax matches best practices and standards for Python code, as well as having much improved readability, this is the default and only option when copying Python commands from geoprocessing tools.  

[PeterKnoop]

@DrewFlater that is great news! Looking forward to seeing it soon in Pro!

[AmeliaBradshaw]

This Idea has been implemented in ArcGIS Pro 3.1. Please see the What's New documentation for more new features in Pro 3.1.

The Ideas in ArcGIS Pro 3.1 blog will be wrapped up soon, highlighting all Ideas implemented in this release, including this one. Once complete, I will add the link to this comment.