warn when default is None and non-optional converter is used

[RonnyPfannschmidt]

#173 introduced optional converters

i noted that attrs doesnt warm if one uses plain types as converters, but just breaks on use later

aka

@attr.s
class Breaks(object):
  bad = attr.ib(default=None, convert=int)

[wsanchez]

There are cases where the converter callable can handle None just fine, so a warning isn't appropriate, right?

Say… change int to repr in your example.

[RonnyPfannschmidt]

@wsanchez repr is not a type ^^ the warning wouldn't trigger then

[RonnyPfannschmidt]

@wsanchez from my pov even @hynek`s first example is wrong, and its usually wrong for all builtin classes as well as for practically all attrs based classes

[wsanchez]

@RonnyPfannschmidt Which example was that? I only see yours above.

Your use of the word "usually" is what concerns me…

[hynek]

I think he refers to #386 and yeah, the “usually” is the concerning thing here. I’m really afraid to enrage a lot of people who consider this a feature.

[RonnyPfannschmidt]

@wsanchez the central problem i see here is still, that literally none of the stdlib classes and none of the attrs based types have coercing constructors, so basically i see both of you arguing for a hard to use api thats impossible to get right because some people might use it - and all we do here is warn

even the example @hynek made for the behavior was demonstrably something where a user would be at best surprised by the behavior

how much more indication do you need

[hynek]

I think this really depends on the perspective – why do you think is it so uncommon to want to wrap a value?

I’m with you that it smells dangerously, but I’m not convinced that every use should be punished by a warning? I run all my tests with warnings and I’d be livid if someone decided that something I do is not right.

[RonnyPfannschmidt]

@hynek its not uncommon to wrap a value, but having a default of none and a type as converter means you wrap instead of coerce - the simple case i warn about is pretty much always a unwanted behavior, in part because it will unconditionally wrap even a valid value of the target type (which is a massive failure)