NoneType(None) raises exception
We just fixed NoneType() to return None instead of raising an exception. Another use-case for calling NoneType is working with ORMs: result = [] for field in row: type = get_type(field) # returns int, bool, str, NoneType, ... result.append(type(field)) if field is None, the resulting call is NoneType(None), and since NoneType doesn't take any parameters we get an exception. Is it worth filing a bug to have NoneType accept one optional argument, which defaults to None, and must be None, else raise an exception? Or should it be: class NoneType: def __new__(cls, *args, **kws): return None Which is basically what my 2.x none() helper function does... -- ~Ethan~
On 26/04/2013 00:09, Ethan Furman wrote:
On the one hand, NoneType(None) seems a strange thing to do. On the other hand: type(value)(value) == value would return True for the built-in types (will certain exceptions, such as when value is float("NaN")). Let's ask the Zen: Special cases aren't special enough to break the rules. Although practicality beats purity.
On 26/04/13 09:56, MRAB wrote:
On the one hand, NoneType(None) seems a strange thing to do.
Only when you write it out like that as constants. It's no more, or less, strange than str('spam') or int(1) or list([]). Why would you do that? But as soon as you think of it in general terms: some_type(some_instance) that's a pretty normal thing to do. And if it just so happened that some_instance were an instance of some_type, it would be surprising if the call failed. (I initially wrote "astonishing", but then I realised that some types take more than one argument, e.g. FunctionType. So it's merely surprising.)
Not an exception, that works fine in 3.3:
I cannot think of any use-case where I would actively want NoneType(None) to fail. That would be like having bool(True) raise an exception. On the other hand, NoneType(x) for any other x ought to fail. -- Steven
On 26/04/2013 01:27, Steven D'Aprano wrote:
None is a singleton, but instances of str, int, list, etc aren't. Why can it take an argument when there's only ever one of them? That's why it seems strange to me.
But:
That's what I mean by it being an "exception".
OK, so practicality (or pragmatism) wins.
On Thu, Apr 25, 2013 at 9:12 PM, MRAB <python@mrabarnett.plus.com> wrote:
How about bool? False and True are singletons much like None is, and bool(False) == False; bool(True) == True. Sure the distinction is that all of those are useful as conversion functions, whereas NoneType would never be used that way. -- Devin
On Apr 25, 2013, at 04:09 PM, Ethan Furman wrote:
I know this use case came up w.r.t. the enum discussion, but I'm not sure it's relevant in a practical sense. Most of the Python ORMs I've worked with have an extension facility to allow custom types/classes to be stored and retrieved into database columns, and these converters always have intimate knowledge of the types they're dealing with, both on the Python side and on the db side. E.g. datetimes to take a pretty common standard Python data type. So while a generic callable API is nice, I'm not sure you'll ever be able to get full coverage over common Python types. -Barry
On Thu, 25 Apr 2013 16:09:41 -0700 Ethan Furman <ethan@stoneleaf.us> wrote:
I don't understand what the use case is. If you already have a value of None, why do you call NoneType on it again? Perhaps you should write: if not isinstance(type, field): field = type(field) Rehatds Antoine.
On Fri, Apr 26, 2013 at 1:09 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
Having it return NoneType there seems a strange thing to do, as have a None field makes no sense. Why would you have a column that can only contain the value None? What is returning NoneType at that point supposed to signify? If it's supposed to signify that the value is NULL, I think the above code is a very strange way of handling that. get_type(field) should reasonably return the type of the column, not the type of the value you got, as that would be just type(field) and doing type(field)(field) is a bit pointless. :-) //Lennart
On 26/04/2013 00:09, Ethan Furman wrote:
On the one hand, NoneType(None) seems a strange thing to do. On the other hand: type(value)(value) == value would return True for the built-in types (will certain exceptions, such as when value is float("NaN")). Let's ask the Zen: Special cases aren't special enough to break the rules. Although practicality beats purity.
On 26/04/13 09:56, MRAB wrote:
On the one hand, NoneType(None) seems a strange thing to do.
Only when you write it out like that as constants. It's no more, or less, strange than str('spam') or int(1) or list([]). Why would you do that? But as soon as you think of it in general terms: some_type(some_instance) that's a pretty normal thing to do. And if it just so happened that some_instance were an instance of some_type, it would be surprising if the call failed. (I initially wrote "astonishing", but then I realised that some types take more than one argument, e.g. FunctionType. So it's merely surprising.)
Not an exception, that works fine in 3.3:
I cannot think of any use-case where I would actively want NoneType(None) to fail. That would be like having bool(True) raise an exception. On the other hand, NoneType(x) for any other x ought to fail. -- Steven
On 26/04/2013 01:27, Steven D'Aprano wrote:
None is a singleton, but instances of str, int, list, etc aren't. Why can it take an argument when there's only ever one of them? That's why it seems strange to me.
But:
That's what I mean by it being an "exception".
OK, so practicality (or pragmatism) wins.
On Thu, Apr 25, 2013 at 9:12 PM, MRAB <python@mrabarnett.plus.com> wrote:
How about bool? False and True are singletons much like None is, and bool(False) == False; bool(True) == True. Sure the distinction is that all of those are useful as conversion functions, whereas NoneType would never be used that way. -- Devin
On Apr 25, 2013, at 04:09 PM, Ethan Furman wrote:
I know this use case came up w.r.t. the enum discussion, but I'm not sure it's relevant in a practical sense. Most of the Python ORMs I've worked with have an extension facility to allow custom types/classes to be stored and retrieved into database columns, and these converters always have intimate knowledge of the types they're dealing with, both on the Python side and on the db side. E.g. datetimes to take a pretty common standard Python data type. So while a generic callable API is nice, I'm not sure you'll ever be able to get full coverage over common Python types. -Barry
On Thu, 25 Apr 2013 16:09:41 -0700 Ethan Furman <ethan@stoneleaf.us> wrote:
I don't understand what the use case is. If you already have a value of None, why do you call NoneType on it again? Perhaps you should write: if not isinstance(type, field): field = type(field) Rehatds Antoine.
On Fri, Apr 26, 2013 at 1:09 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
Having it return NoneType there seems a strange thing to do, as have a None field makes no sense. Why would you have a column that can only contain the value None? What is returning NoneType at that point supposed to signify? If it's supposed to signify that the value is NULL, I think the above code is a very strange way of handling that. get_type(field) should reasonably return the type of the column, not the type of the value you got, as that would be just type(field) and doing type(field)(field) is a bit pointless. :-) //Lennart
participants (8)
-
Antoine Pitrou -
Barry Warsaw -
Benjamin Peterson -
Devin Jeanpierre -
Ethan Furman -
Lennart Regebro -
MRAB -
Steven D'Aprano