Conversation
|
@brighton1101 , won't the leading b cause issues with decoding? |
|
I think this will turn it into a string and we don't have to worry about bytes after that? |
vchiapaikeo
left a comment
There was a problem hiding this comment.
This should resolve but really appreciate the help here!
|
@vchiapaikeo I think that hack is alright, but the leading b means that it is a byte literal. It has nothing to do with encoding/decoding by design, since the contents are only bytes. Python docs. Afaik Calling That operator is expecting bytes. I feel like it is a regression for |
|
Also - for context this likely wasn't in boundary layer before because Python 2.x did not support byte literals. Since we don't support python 2 anymore, we don't have to worry about this. |
|
I think the problem here is that if you call the str function around a bytes type, it will fail to b64 decode later on. Example: Alternatively: |
|
Ah I think your code snippet only works this way in Py2 and not Py3 |
| return '{{ {items} }}'.format(items=','.join(pairs)) | ||
|
|
||
| if isinstance(value, (int, float, type(None))): | ||
| if isinstance(value, (int, float, type(None), bytes)): |
There was a problem hiding this comment.
If we want to support bytes, we should just return the bytes and not pass it through the str function. e.g.,
if isinstance(value, bytes):
return value
There was a problem hiding this comment.
@vchiapaikeo I considered that, however since this function is returning exclusively strs apart from this, I wanted to keep the return type uniform. I understand that now with jinja this is not causing problems. However, what if someone decorated this method call with more logic thinking they were getting a str and instead got bytes? Maybe this is not a problem and i am overthinking
Closes #79
One of our operators has an optional field that requires bytes. If that field is populated, it will error out when it gets formatted. This should fix that.