-
Notifications
You must be signed in to change notification settings - Fork 86
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
Default values and subcast #270
Comments
Am I correct in understanding that the subcast is applied to the default value? If so, does this make sense, since a default value is supposed to be predictable and shouldn't require any transformations? Wouldn't it be better to simply check if the default value is of the correct type or |
The subcast is applied to elements of the list after splitting.
As for the suggestion to check if the default value is of the correct type: That would only work as long as the subcast argument is a type. For (other) callables, that would require either another argument or a mandatory return annotation. IMO, both would make usage of the package unnecessarily complex. Footnotes |
As far as I can tell the default value can either be of the cast type or a string. So
env.bool('FOO', True)
,env.bool('FOO', 'true')
,env.bool('FOO', '1')
andenv.bool('FOO', 'YES')
all are basically the same.The same goes for lists with a subcast to a basic type.
env.list('FOO', '1, 2, 42', subcast=float)
andenv.list('FOO', [1.0, 2.0, 42.0], subcast=float)
both do work.But, using the target type as default only works as long as the subcast type/callable can be called with the cast type itself. It breaks when the callable expects a string and returns something else. For example:
If this is expected behaviour, I’d be happy to provide a pull request with a supplement to the documentation (well, README.md).
The text was updated successfully, but these errors were encountered: