Could ParamValidation be more permissive?

There’s a common pattern in python where you want to provide all parameters as a value or None, and expect that the receiving end treats “None” as a non-value.

The pattern simplifies and shortens code. Unfortunately it doesn’t seem possible to do so with boto3:

ec2 = boto3.resource('ec2', args.region)
volume = ec2.create_volume(
    Size=int(args.size),
    SnapshotId=args.snapshot_id or None,
    AvailabilityZone=instance.placement['AvailabilityZone'],
    VolumeType=args.volume_type,
    Iops=args.iops or None,
    Encrypted=bool(args.encrypted),
    KmsKeyId=args.encrypted or None)

botocore.exceptions.ParamValidationError: Parameter validation failed:
Invalid type for parameter Iops, value: None, type: <type 'NoneType'>, valid types: <type 'int'>, <type 'long'>
Invalid type for parameter KmsKeyId, value: None, type: <type 'NoneType'>, valid types: <type 'basestring'>
Invalid type for parameter SnapshotId, value: None, type: <type 'NoneType'>, valid types: <type 'basestring'>

Instead, one has to carefully build a dict with the arguments using one if per argument:

opt = {}
if args.iops:
    opt['Iops'] = args.iops
if args.kms_key_id:
    opt['KmsKeyId'] = args.kms_key_id
# ...

[rterbush]

Wanted to chime in here and indicate my support of this change as well.

I’m in the process of porting some saltstack states to boto3 and this issue is definitely a huge pain. Would not be a big deal if you only cared about a few of the possible parameters, but adds quite a bit of code to deal with support for None on the optionals.

Would make more sense to me to force the corner cases mentioned by @rayluo in #331 to jump through some hoops rather than every common use case.

[joguSD]

Coming back to this, the logic in the previously linked ticket #331 is correct. We can’t make this change because the absence of a parameter and that parameter being None aren’t always the same. Considering that these parameters get serialized down to an API call (commonly JSON) the following aren’t equal:

{}

{"some_field": null}

Which could potentially be an important distinction for some APIs.