Empty strings as None (revisited)

I'd like to revisit this suggestion - allowing empty strings to be interpreted as None:

https://github.com/marshmallow-code/marshmallow/issues/543

I understand the sentiment of the response: "it's a bad idea to support that". However, that's not sufficient for some use cases.

For example, right now I'm trying to use marshmallow to convert an XML format where null values are sent as empty strings. I don't get to control the XML format.

I think it's entirely reasonable for a Field to interpret a null datestring (or a null decimal string) as None, and control via allow_none whether to pass that. I don't think it's reasonable to fall down and say "the NULL value defined by your format is invalid, and we're not going to allow you to express that". This just forces a lot of ugly preprocessing workarounds onto library users, who need to clutter their code with superfluous, bug-prone value = value or None type declarations... thereby mixing format definition code in the middle of application code, which makes it hard to use marshmallow to write good code for these use cases.

I feel that the right place to define a format is, well, in the Schema class definition. A patch to accomplish this is simple:

• add an attribute to fields.Field, e.g. null_values = {None}
• change fields.Field.deserialize() line 263 as follows:
  if getattr(self, 'allow_none', False) is True and value in self.null_values: return None

We can stop there, and allow users to support their nasty unhygienic formats by overriding null_values in a custom subclass... or even take it a step further and allow first-class support for text-only formats by directly setting null_values = {None, ''} for fields.Decimal, fields.DateTime, fields.Date, fields.Time, etc. By Zeus, maybe even fields.Integer could treat empty strings as None!!

I'm happy to submit a PR to that effect, but I'd like to see where the developers' heads are at vis-a-vis using marshmallow for non-JSON formats before wasting anybody's time.

Thanks, and happy new year!

Start by reading the prior discussion in issue #543 and the 32-comment thread here, then inspect fields.Field.deserialize around the referenced line 263 and the Decimal, DateTime, Date, Time, and Integer field classes. Done means the maintainers agree on the null_values design and supported field scope before implementation begins.