所有人,
总的来说,我对使用python和编码还是个新手。关于工具签名,我有一个非常基本的问题。当我查找一个工具时……我得到了这个:
arcpy.management。CopyFeatures(in_features, out_feature_class, {config_keyword}, {spatial_grid_1}, {spatial_grid_2}, {spatial_grid_3})
然而,关于理解工具语法的示例和文档表明,工具签名应该是抽象的。CopyFeatures_management
我刚刚注意到这一点,并一直在我的代码中使用archy .management. copyfeatures,没有任何明显的问题。
这有关系吗?有人知道为什么他们提供archy .toolboxalias.tool当所有的例子和文档显示archy。tool_toolboxalias吗?我应该回去修改代码吗?
感谢任何可以帮助我走向自动化的人!
解决了!进入解决方案。
不,不要回去修改你的代码,两种方法都是可以接受的。
apache .management. copyfeatures()方法是我所理解的,它是现代更行业标准的方法,您可以深入到函数所在的模块中。在我看来,它符合VB和c# .net的编码风格。
旧的风格(这是我使用和“成长”的)arcpy.CopyFeatures_management()在整个帮助文件中无处不在,仅仅是因为ESRI没有选择标准化他们的代码示例,我猜这导致了困惑和用户的问题,比如你自己。
我不相信如果你使用一种风格而不是另一种,会在性能上有任何损失。我在这里留下的重要信息是,在编码时坚持一种风格,并添加尽可能多的注释,以使您的代码对您和其他人都具有可读性。
不,不要回去修改你的代码,两种方法都是可以接受的。
apache .management. copyfeatures()方法是我所理解的,它是现代更行业标准的方法,您可以深入到函数所在的模块中。在我看来,它符合VB和c# .net的编码风格。
旧的风格(这是我使用和“成长”的)arcpy.CopyFeatures_management()在整个帮助文件中无处不在,仅仅是因为ESRI没有选择标准化他们的代码示例,我猜这导致了困惑和用户的问题,比如你自己。
我不相信如果你使用一种风格而不是另一种,会在性能上有任何损失。我在这里留下的重要信息是,在编码时坚持一种风格,并添加尽可能多的注释,以使您的代码对您和其他人都具有可读性。
@DuncanHornby写道:
我在这里留下的重要信息是,在编码时坚持一种风格,并添加尽可能多的注释,以使您的代码对您和其他人都具有可读性。
我同意。一致性是非常重要的。即使你的代码模式是旧的/低效的/密集的,你直到一半才意识到,要么以同样的方式修复它,要么继续这个模式。