Any better strategy for escaping commas?

[treykeown]

Is there any better way to do this? Right now, on the command prompt, you have to escape your quotes when trying to escape a comma. A little clunk to type ./script.py cmd first,\"second,also-second\",third.

[skippyr]

Hello, @treykeown.

It seems that you are having trouble escaping a character. Usually, commas do not need to be escaped to be recognized, so I guess that your problem is escaping the double quotes character am I right?

If that is the problem, one easy solution is to wrap your argument around single quotes, like this:

./script.py cmd 'first,"second,also-second",third'

[treykeown]

Hi, thanks for the input! Good point, I'll probably recommend this approach in the docs. Escaping commas is the key here, though. I'm hoping for some inspiration on how other projects do it, but the only example I've found is here in qemu:

This option defines which disk image (see the Disk Images chapter in the System Emulation Users Guide) to use with this drive. If the filename contains comma, you must double it (for instance, “file=my,,file” to use file “my,file”).

This approach is not appropriate for arguably, since it removes the ability to pass in an empty list item. So we're left with quoting as the only way to escape commas, which is a bit tougher to do from the command line - either they must be escaped, or wrapped in another pair of quotes, as you've pointed out.

[skippyr]

After taking a look in some examples in the Qemu manual you linked, I think that I understand now what you want to do: you are having trouble parsing commands like this:

python3 main.py cmd file=my,file,disk=/dev/sda

Where there is, for example, a file property with a value containing a comma, the same character used to separate the values, which make it hard to parse.

I guess one easier solution than quoting it, is to prefer receiving the arguments using flags, so that same command would become:

python3 main.py cmd --file my,file --disk /dev/sda

Considering that both flags, --file and --disk are expecting a str (string) type, your library might consider the argument following them as their value.

[treykeown]

Hey, thanks for taking a look. This isn't about splitting up arguments, it's about escaping a comma.

[chuckwondo]

@treykeown, are you able to provide a bit more context for this? What is the specific use case that you want to support?

From the thread so far, it is not terribly clear as to why this is not about splitting arguments. If it is not about splitting arguments, does that mean that the input first,\"second,also-second\",third is intended to be a single, positional argument?

I'm asking for this clarity because, as far as I can decipher at this point, if it is not about splitting arguments, then it appears that perhaps this in not something that you as the author should be concerned with. In other words, if an arguably user wants to be able to accept a single, positional argument of that form, then perhaps that's a poor design choice on the part of the user, and it is then up to the user to determine how to specify and parse that argument.

However, if that's not the case, then it seems that more context from you would better enable us to provide meaningful input to you.

[chuckwondo]

Ah, I see where this is coming from: https://treykeown.github.io/arguably/tutorial/type-hints/#tuples

That seems to be a rather obscure use case. Do you have a good example of why someone might want to do this? Wouldn't it be easier to simply define separate args/options?

[treykeown]

@chuckwondo Coming back to this with fresh eyes, I believe you're right. I'm not sure there's any reason to put more effort into this. Closing.