Fix KFP code generation issues for pipeline parameters

[ptitzler]

Code generation produces incorrect results (and in some scenarios fails) for some pipeline parameter scenarios. Examples below, as observed in the generated Python DSL:

• the parameter description contains the " character (YAML parser chokes)

   - {name: a_quote, type: String, description: 'description with a "', default: "string default contains \" anywhere", optional: true}
  

• the parameter value contains the " character for parameter type String
• no default values are specified, e.g.

   i2: int = ,
  

• a default value of zero is defined for numeric parameter types (input spec is missing this value), e.g.

    - {name: i3, type: Integer, description: 'an int with default value of 0', optional: true}
  

• a default value of False for Bool-typed parameters is missing , e.g.

  - {name: b1, type: Boolean, description: 'a boolean with default value False', optional: true}
  

Some of the problems were caused by the fact that 0 and <empty-string> were considered to be equivalent (or not equivalent) to None. To avoid these issues the PipelineParameter class now explicitly assigns None to parameter values and default values that are set to the empty string by the UI.

Signed-off-by: Patrick Titzler ptitzler@us.ibm.com

What changes were proposed in this pull request?

• Fix incorrect implementation

How was this pull request tested?

To test create and export a KFP pipeline that utilizes pipeline parameters, covering the scenarios listed in the problem description. The generated Python DSL code should properly reflect the pipeline parameters, their values, and types.

Developer's Certificate of Origin 1.1

   By making a contribution to this project, I certify that:

   (a) The contribution was created in whole or in part by me and I
       have the right to submit it under the Apache License 2.0; or

   (b) The contribution is based upon previous work that, to the best
       of my knowledge, is covered under an appropriate open source
       license and I have the right under that license to submit that
       work with modifications, whether created in whole or in part
       by me, under the same open source license (unless I am
       permitted to submit under a different license), as indicated
       in the file; or

   (c) The contribution was provided directly to me by some other
       person who certified (a), (b) or (c) and I have not modified
       it.

   (d) I understand and agree that this project and the contribution
       are public and that a record of the contribution (including all
       personal information I submit with it, including my sign-off) is
       maintained indefinitely and may be redistributed consistent with
       this project or the open source license(s) involved.

[ptitzler]

Linting errors and subsequent test failures are unrelated to the changes introduced by this PR. A new major version of black was published yesterday. We currently have no upper version cap in place. #3096

[akchinSTC]

thumbs up LGTM