<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 19.09.2015 07:14, Stephen J. Turnbull wrote:<br>
<blockquote cite="mid:87d1xfyoqn.fsf@uwakimon.sk.tsukuba.ac.jp"
type="cite">
<pre wrap="">A true SQL NULL type. It's always bothered me that most ORMs map NULL
to None but there are plenty of other ways to inject None into a
Python computation. (This probably isn't a practical suggestion
either unless Random832's suggestion of ?() establishing a lexical
context were adopted.)
</pre>
</blockquote>
<br>
I definitely agree here. Internally, we have a guideline telling us
to avoid None or NULL whenever possible. Andrew's remark about 'code
smell' is definitely appropriate.<br>
<br>
<br>
There was a great discussion some years ago on one of the RDF
semantics mailing list about the semantics of NULL (in RDF). It
turned out to have 6 or 7 semantics WITHOUT any domain-specific
focus (don't know, don't exists, is missing, etc. -- can't remember
all of them). I feel that is one reason why Python programs should
avoid None: we don't guess.<br>
<br>
<blockquote cite="mid:87d1xfyoqn.fsf@uwakimon.sk.tsukuba.ac.jp"
type="cite">
<pre wrap="">The point is that Maybe behavior is at least theoretically useful in
subcategories, with special objects other than None.
Sven's suggestion of calling this the "monad" operator triggers a
worry in me, however. In Haskell, the Monad type doesn't enforce the
monad laws, only the property of being an endofunctor. That
apparently turns out to be enough in practice to make the Monad type
very useful. However, in Python we have no way to enforce that
property. I don't have the imagination to come up with a truly
attractive nuisance here, and this operator doesn't enable general
functorial behavior, so maybe it's not a problem.
</pre>
</blockquote>
<br>
Sleeping one night over it, I now tend to change my mind regarding
this. Maybe, it's <b>better to DEAL with None as in remove</b> <b>them</b>
from the code, from the database, from the YAML files and so forth <b>instead</b><b>
of </b>making it easier to work with them. Restricting oneself,
would eventually lead to more predictable designs.<br>
<br>
Does this makes sense somehow?<br>
<br>
<br>
Issue is, None is so convenient to work with. You only find out the
code smell when you discover a "NoneType object does not have
attribute X" exception some months later and start looking where the
heck the None could come from. What can we do here?<br>
</body>
</html>