Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou@free.fr> added the comment:
> 
>> PyUnicode_Decode() et al. are conversion functions and these
>> require valid content to work on. Passing in a NULL pointer
>> does not fit that specification and so allowing for this
>> would hide programming errors.
> 
> "Valid content" doesn't mean a lot when the length is 0.
> What is a valid 0-length string compared to an invalid one?
> What if the pointer is non-NULL but segfaults when trying to dereference
> it? Is it "valid"?
> 
> Moreover, malloc() is allowed by POSIX to return NULL when called with a
> 0 length:
> 
>         If size is 0, either a null pointer or a unique pointer that can
>         be successfully passed to free() shall be returned.
> 
> (http://www.opengroup.org/onlinepubs/007904875/functions/malloc.html)
> 
> ... which means that such a pointer can then, depending on the platform,
> get passed (legitimately) to PyUnicode_Decode().

... and Python has for years made sure that PyMem_Malloc() et al.
return a non-NULL pointer when passed a size 0 value (see pymem.h for
details), since the above was a really poor design choice.

A lot of Python code relies on those functions returning NULL only
in case of an error.

> So, IMO, practicality beats purity here. Especially since it is bound to
> land in a bugfix release (3.2.1), which users don't expect to produce
> regressions in their own code.

Nope. Your suggestion would be a new feature and those are not
allowed in patch level releases.

I'm -1 on the idea for the reasons already stated.