Attachments & Url

[0x2x]

• Attachment python run.
• URL python run.

These edits allow users to drop an attachment file and have the code run also allows users to use URLS and allow them to run.

[scarletcafe]

This PR doesn't meet the necessary quality standards for a number of reasons. Usually I would just mark them in review and request changes, but there's enough here to the point where it would be faster to scrap this version and start again. Some things I picked out just from a skim:

Major issues (showstoppers)

• Don't delete the PR text template. It's there for a reason. One of the boxes you must check is that you tested your changes - since you removed it, there's no such statement, and I can see from your commit signatures that you did these edits via the website, which isn't an environment you could have directly tested from.
• DRY - Don't Repeat Yourself. The original function contains only one copy of the main processing for a reason, your edit duplicates it 5 times.
• You define a usage of the AttachmentConverter and then proceed to not use it
• type(x) = y isn't the way you're supposed to do this kind of instance check (and you shouldn't even be using it here - you should know what type you're dealing with when interacting with an API, and this repo uses strict pylance)
• This is just kind of a weird way to handle this edge case
• You should be using Attachment.save since it's part of the library
• You shouldn't be using the URL to check for the filename since it's part of Attachment
• There shouldn't be an inconsistency between one of the python commands supporting this feature and the other not supporting it.
• Commented out code should only be there if there's a good docs-related reason to keep it

Other comments

• Handling stuff like this should have probably just been done with a new Converter
• The import style is wrong (GHA would catch this if it was enabled on your account).
• The argument annotation style is inconsistent (again would be caught).
• TITLE_CASE is for module globals not function locals, and things in this realm should generally be immutable (i.e. tuple not list)
• I'd like to see both a rationale for this feature in the first place, and at least some form of write-up on what security considerations amongst other things were made in the implementation, executing external code is one of the most security-sensitive functions a library can have and it's important you make sure adjustments to it are water-tight.

This is only the the surface-level problems, so "needs work" would be appropriate here (arguably less of it, most of these issues are because this is over-complicated as a solution, needs more effort put towards design than LOC).