ros_tutorials
ros_tutorials copied to clipboard
Python nodes ending in .py
Currently, the catkin python install how to explicitly states:
To keep the user API clean, executable script names generally do not include a .py suffix.
However, the tutorials create nodes ending in .py
. Now, the question is: which one applies?
If they indeed should not end in .py
(which I personally would support because as the author of the catkin howto wrote, that's an implementation detail and not really relevant to the user), it would make sense if the Wiki Tutorials would either not create nodes ending in .py
because most people will follow the tutorials when they create their own nodes or at least have a section about how normally you would strip the extension.
Edit: I just noticed that the catkin howto also proposes putting nodes in a nodes subfolder and other python scripts in a scripts subfolder which is also not consistent with the tutorials.
The recommendation from the catkin
documentation makes sense since the user shouldn't need to know if the executable is a binary or a Python script (or something else).
Please consider to update the wiki pages with this recommendation and post the links to changes pages in this ticket.
I just noticed that the catkin howto also proposes putting nodes in a nodes subfolder and other python scripts in a scripts subfolder which is also not consistent with the tutorials.
This statement is much less clear imo. I don't think this is a generally accepted approach. I might be better to remove the recommendation from the catkin
docs since only very few packages follow this.
Please consider to contribute a PR for catkin to update the docs.
I believe users need to preserve the .py files because as they're following a tutorial they might need to change their codes later on. Here you might need to trade customizability with neatness.
The file extension has no influence on whether you can edit it or not.
But how will they know about the file type if there's no extension
The shebang should tell file explorers and you can always open it. The fact that it is in the source package makes it very likely that it's not a binary.