I thought to change to connected ditionary though.

AgitatedDove14 ArgParser argument

And the trains version?

btw: both should work fine

PompousBeetle71 BTW: if you remove the type=str from the argparse, it will do what you want, None will stay None (instead of ''), all other values will be of type str as this is always the default 🙂

PompousBeetle71 If this is argparser and the type is defined, the trains-agent will pass the equivalent in the same type, with str that amounts to '' . make sense ?

AgitatedDove14 When the default is None I expect the default value to be None even if the type is str. But I'll use your recommendation 🙂

thanks

I think if there's a default value it should override the type, otherwise go with the type

i.e. run
pip install --upgrade trains

yes, it was.

AgitatedDove14 v0.14

AgitatedDove14 no, there's no reason in my case to pass an empty string. that's why I removed the type=str part.

I mean , the python package, not the trains-server version

PompousBeetle71 is this ArgParser argument or a connected dictionary ?

PompousBeetle71 Could you check with 0.14.3 that just released?

Hi PompousBeetle71
I remember it was an issue, but it was solved a while ago. Which Trains version are you using?

Hmm, I still wonder what is the "correct" answer for most people, is empty string in argparse redundant anyhow? will someone ever use it?

yes, there's a use for empty strings, for example in text generation you may generate the next word given some prefix, the prefix may be an empty string.

Another question, do you have the argparse with type=str ?

PompousBeetle71 quick question, will you ever want to pass an empty string ? reason for asking is that it is either one or the other, there is no way for Trains to actually differentiate (from the web UI, perspective this is just an empty string field...)

the trains version is still 0.14 it will take time to switch it

Hmm... That's what happens with the exception of None/'' if type is str... There is no way to differentiate in the UI.
This is why we opted for type=str will "cast" everything to str so you always get str, while not specifying a type will leave the variable as is... If you have an idea on how to support both, feel free to suggest 🙂

the version of the agent (the worker that received the job was 0.14.1)
the one that created the template was 0.14.2