Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow boolean flags to work without passing True #1829

Closed
williamFalcon opened this issue May 14, 2020 · 7 comments · Fixed by #1842
Closed

Allow boolean flags to work without passing True #1829

williamFalcon opened this issue May 14, 2020 · 7 comments · Fixed by #1842
Assignees
Labels
bug Something isn't working help wanted Open to be worked on priority: 0 High priority task

Comments

@williamFalcon
Copy link
Contributor

We tried to fix this but it's still broken

This fails when adding args to argparse automatically...

--auto_lr_find

Instead we have to do:

--auto_lr_find True

which is not great

@williamFalcon williamFalcon added bug Something isn't working help wanted Open to be worked on labels May 14, 2020
@SkafteNicki
Copy link
Member

This only seems to be a problem with the auto_lr_find flag, since it is the only argument that is a union between the 4 allowed types (str, float, int, bool) in the add_argparse_args. So either this needs to be handled as a special case in the argparser or remove one of its allowed value (str or bool).

@williamFalcon
Copy link
Contributor Author

it's a problem for many flags haha. The pattern is bool or the callback or string.

So, early stopping, checkpoint, etc... all have this problem.
And for the batch size and lr finder stuff we have a few options

auto_lr_find=True
auto_lr_find='some.path'

But True is getting parsed as a string which breaks everything.

@williamFalcon williamFalcon added the priority: 0 High priority task label May 14, 2020
@williamFalcon
Copy link
Contributor Author

williamFalcon commented May 14, 2020

I think we need to solve this before 0.7.6 release as this is causing a lot of unexpected behaviors @Borda.

Basically i think we need to:

  1. allow the flag to be passed in with set_true --my_flag (this becomes a bool with True)
  2. but if there is something else, then treat that thing as a string --my_flag this_is_a_string

@Borda
Copy link
Member

Borda commented May 14, 2020

I think that the complication comes with
https://github.com/PyTorchLightning/pytorch-lightning/blob/236c1378f94a7f9d2e1e205035d4d76733c8f4c9/pytorch_lightning/trainer/trainer.py#L131
so you cannot in argparse define to be store_true and optional string at the same time

@Borda
Copy link
Member

Borda commented May 14, 2020

well this is the minimal solution

import argparse
p = argparse.ArgumentParser()
p.add_argument("--a", type=str, default=False, nargs="?")
v = vars(p.parse_args())
v = {k: True if v is None else v for k, v in v.items()}
print(v)

gives:

  • python sample.py --a >> {'a': True}
  • python sample.py >> {'a': False}
  • python sample.py --a park >> {'a': 'park'}

@Borda Borda self-assigned this May 14, 2020
@williamFalcon
Copy link
Contributor Author

let's merge this asap for 0.7.6

@Borda
Copy link
Member

Borda commented May 14, 2020

let's merge this asap for 0.7.6

ready to review... ^^ @williamFalcon

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Open to be worked on priority: 0 High priority task
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants