This arises out of PEP 505 - None-aware operators. I thought, a page on how None is special would be nice. I've not found such a page on the web. We do have === https://docs.python.org/3/library/constants.html None The sole value of the type NoneType. None is frequently used to represent the absence of a value, as when default arguments are not passed to a function. Assignments to None are illegal and raise a SyntaxError. === So decided to start writing such a page, perhaps to be added to the docs. All code examples in Python3.4. Here's my first attempt. I'm sure I've missed some important examples. Please help, if you can. None is a keyword ==============
None = 0 SyntaxError: can't assign to keyword
The Command Line Interpreter hides None =================================
None
None is false in a boolean context ==========================
bool(None) False
Procedures return None ==================
Dictionary get returns None if not found ==============================
{}.get('dne') is None True
None is default return value =====================
None is used as a sentinel default value ============================== Particularly useful when default value must be determined in body of function. --- def insort_right(a, x, lo=0, hi=None): # ... if hi is None: hi = len(a) --- Thank you for your attention. What have I missed? -- Jonathan
On 23Jul2018 1003, Jonathan Fine wrote:
There's also https://docs.python.org/3/c-api/none.html?highlight=py_none#c.Py_None "The Python None object, denoting lack of value. This object has no methods. It needs to be treated just like any other object with respect to reference counts." I don't know that documenting the behaviours of None are that interesting (e.g. not displaying anything at the interactive prompt), though it'd be perfect for a blog and/or conference talk. But if there appear to be behaviours that are not consistent or cannot be easily inferred from the existing documentation, then we should think about why that is and how we could enhance the documentation to ensure it accurately describes what None is supposed to be. That said, your examples are good :) Cheers, Steve
On 23 July 2018 at 10:16, Steve Dower <steve.dower@python.org> wrote:
The examples are interesting, agreed. One thing they highlight to me is that most uses of None are effectively convention. The only two behaviours that are unique to None and implemented in the interpreter are: 1. Functions that don't return an explicit value return None. 2. The interactive interpreter does not display the value of a typed expression when that value is None. (the fact that None is a keyword is not unique - True and False are also keywords - although it is a distinguishing feature). One of the key points about this proposal is that it adds a number of additional ways in which the interpreter treats None specially (i.e., four dedicated operators). That elevates None from the position of being a commonly used sentinel value to one that has language support for being a sentinel. That's not necessarily a bad thing, but it is a point that should be considered when reviewing this PEP (people who prefer to use object() for their sentinels are probably less happy about making None "special", for example - Pandas uses NaN as the "missing data" sentinel rather than None, although Pandas' focus on bulk processing means that dedicated operators probably wouldn't help anyway). Overall, my personal feeling is that I do use None specially (and a lot of code I see does too), so having None-aware operators has some merit. But I don't find None to be special enough to warrant quite this *many* operators, nor do I find that the patterns that operators like ?. and ?[ support are ones I use a lot. Actually, the ?. and ?[ operators seem like they'd be much more useful if I did more JSON processing - but I don't, so I have little feel for whether language support is needed here or whether better library support (stdlib and/or 3rd party) for optional data is sufficient. Paul
Hi Paul Thank you for your contribution
I broadly agree with what you say, particularly the compliment. You also wrote:
One of the key points about this proposal [PEP 505]
My goal in this thread is to document clearly and develop a clear shared understanding of the ways in which None is special in Python. Please, please, please can we not discuss PEP 505 in this thread. There's already another thread for that. I want this thread to produce a web page that is useful for beginners and intermediate Python programmers (which perhaps some experts might also benefit from reading). -- Jonathan
On 23 July 2018 at 12:24, Jonathan Fine <jfine2358@gmail.com> wrote:
OK, apologies for my confusion between the threads.
My view would be basically "None isn't special, it's just another value. By the time you understand enough to want to treat None specially, you probably already know enough about how the language does". That's very over-simplified, sure, but I really don't see None as *that* special except in the context of non-beginner ideas like "it's similar to SQL NULL", or "it's like a null pointer in C". In my experience, I've found I tend more to be explaining to beginners why None *isn't* special than why it is. Which is why I found your list of examples interesting, because many of them were about convention rather than language support. Paul
On Mon, Jul 23, 2018 at 12:15:14PM +0100, Paul Moore wrote:
That is built into the language.
2. The interactive interpreter does not display the value of a typed expression when that value is None.
But that is not built-in, it is merely the default behaviour. It is controlled by sys.displayhook, which can be customized: https://docs.python.org/3/library/sys.html#sys.displayhook We can have many interactive interpreters, including iPython, bpython, IDLE, etc and they don't necessarily suppress the printing of None.
One of the key points about this proposal
That would be the None-aware PEP, not Jonathon's proposal to add documentation about None.
None is already a special value. It is so special, it is one of only three built-in values given keyword status. All the other built-ins, including such things that are used implicitly by the interpreter (such as NotImplemented) are merely ordinary names.
You make it sound like its a mere aesthetic choice. None is the default, recommended, most convenient sentinel. I use object() as a sentinel, when None is an otherwise ordinary value. I am also happy for None to be special, because it *is* special. -- Steve
Hi Steve In this thread you wrote, replying to Paul Moore's comments on PEP 505
Half an hour earlier, Paul wrote (in reply to me)
Paul has implicitly removed from this thread his comments on PEP 505. If you wish to respond to Paul's comments, please do so elsewhere. There's already a thread for PEP 505. -- Jonathan
This has been mentioned a lot in this discussion— Maybe what we need is a smarter JSON processing package, rather than new operators. Granted, these operators would help the authors of suck a package(s), but if the bulk of users didn’t need them, then no point in adding them to the language. -CHB
On Mon, Jul 23, 2018 at 10:03:10AM +0100, Jonathan Fine wrote:
I thought, a page on how None is special would be nice.
I think your document would be a great blog post. I don't think it is very helpful as part of the standard documention, as it is more a collection of arbitrary facts about None than a coherent "big picture" document. We could come up with such arbitrary lists for many other standard objects too: "Did you know... that operator dunder methods should return NotImplemented to signal to the interpreter that the other operand's method should be called?" "Did you know that Ellipsis is the sole instance of class ellipsis, reversing the usual convention that classes use InitialCaps and instances lowercase?" -- Steve
Hi Steve You wrote
Thank you. That's nice. However, I think there is, or should be, more coherence than you're seeing. Here's something I forgot to say. For standard documentation I was thinking The Python Tutorial. For example, the Brief Tour. https://docs.python.org/3/tutorial/stdlib.html https://docs.python.org/3/tutorial/stdlib2.html That said, a blog post would be useful stepping stone, and the standard documentation later. (Know where your heading, take one step at a time.) Once again, thank you for your comment. -- Jonathan
I think your description of the uses of None is really great. There's definitely no reason it cannot be a blog post immediately, but perhaps at some later point included in The Python Tutorial. On Mon, Jul 23, 2018 at 8:39 AM Jonathan Fine <jfine2358@gmail.com> wrote:
-- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.
On Mon, Jul 23, 2018 at 10:03:10 +0100, Jonathan Fine wrote:
Hi, there's also https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarc... None This type has a single value. There is a single object with this value. This object is accessed through the built-in name None. It is used to signify the absence of a value in many situations, e.g., it is returned from functions that don’t explicitly return anything. Its truth value is false. Cheers Jörn Heissler
Is None a builtin? In [1]: from keyword import kwlist In [3]: 'Ellipsis' in kwlist Out[3]: False In [4]: 'None' in kwlist Out[4]: True Maybe we should change This type has a single value. There is a single object with this value. This object is accessed through the built-in name None. It is used to signify the absence of a value in many situations, e.g., it is returned from functions that don’t explicitly return anything. Its truth value is false. to This type has a single value. There is a single object with this value. This object is accessed through the keyword None. It is used to signify the absence of a value in many situations, e.g., it is returned from functions that don’t explicitly return anything. Its truth value is false. Best, Neil On Monday, July 23, 2018 at 2:31:21 PM UTC-4, Jörn Heissler wrote:
Hi Neil Thank you for your post, regarding https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarc.... You've suggested changing "built-in name None" to "keyword None". I think that's a good change. And similar changes might be welcome elsewhere in the docs, perhaps also for True and False. And I think there's more. The page says
None This type has a single value. There is a single object with this value. [...]
I think it better to write
NoneType This type has a single value, `None`. The keyword `None` always gives the value `None`.
I think the best way forward here is to raise an issue on https://bugs.python.org/. Would you be willing to do this? If you need it, there's help available at https://devguide.python.org/triaging/. Once again, thank you for your close attention to detail. -- Jonathan
Hi Rhodri Thank you for your message. You wrote:
The decision is neither your's nor mine. It is for the Python docs maintainers. I will respect their decision, even if I don't agree with it. I intend, in my page (on why None is special) to continue to quote accurately, and without criticism, the current Python docs. One intention of my post is to move the particular docs discussion from python-ideas and to bugs.python.org. I think that is a better place for it. They're the people who can decide and do (or not do) something about it. -- with best regards Jonathan
On Thu, 16 Aug 2018 at 14:26, Rhodri James <rhodri@kynesim.co.uk> wrote:
I agree that the original is better. I think the important thing (which doesn't come across when quoting text in email) is the typography. ``` None This type has a single value. There is a single object with this value. This object is accessed through the built-in name None. [...] ``` The initial "None" is on a line by itself, and is in "normal text" font, outdented from the following text. As it's in a section called "The standard type hierarchy", this reads to me as referring to a type, informally named as "None". It's not referring to the Python keyword None, which is formatted differently (monospace with a grey background). Conversely, the "None" in the phrase "the built-in name None" *is* formatted to indicate that it's the Python keyword. The typography makes it quite clear (to me) that there are two different *concepts* being discussed here, and furthermore, the wording clearly implies that neither of these concepts is precisely equivalent to the "single value" of the None type. It's easy when discussion wording in a plain-text medium like email to ignore the impact of formatting on how the meaning of a piece of text is conveyed. In this case, I think that the details are subtle enough that the typography is critical to getting the message across. One thing that *isn't* conveyed by the description here is the distinction between `None` and `Ellipsis`. The two relevant sections say This object is accessed through the built-in name None This object is accessed through the literal ... or the built-in name Ellipsis But you can't assign to (the name) None, and yet you can to (the name) Ellipsis. It might be better to say "the keyword None" in the section on None, to make that distinction. But that's the only change I'd make. Paul PS I should say that I would not expect any of the fine distinctions I've drawn in the above to be obvious to non-native speakers of English. That's a very different problem to handle, and one that is orders of magnitude harder than the comparatively simple task of trying to distinguish between None the type, the keyword and the value :-)
Hi Paul Thank you for your comments. I think different people experience things in different ways, based on who they are. What their background, training, experience are. One person's precision is another's pedantry. An aside. Babbage and Tennyson: https://www.uh.edu/engines/epi879.htm You wrote
When I read the same text, I don't see an informal name. I see a false statement. By the way, here's why I see a false statement:
type(int), type(dict), type(str) (<class 'type'>, <class 'type'>, <class 'type'>)
type(None), type(type(None)) (<class 'NoneType'>, <class 'type'>)
My (pure mathematics research) background leads me to dislike precise statements that are not true. That's the way I am. Rhodri James doesn't like sentences that begin with 'But'. An aside. Reading further in https://docs.python.org/3/reference/datamodel.html, I see three times "This type has a single value." The informal names are None, NotImplemented and Ellipsis. And there are only two Booleans. I'd like to take this to bugs.python.org, if only to provide another route to discovering this (very useful) conversation. Perhaps one day, we'll have here harmony between informality and precision. Perhaps every popular computer language has this as a goal. -- with best regards Jonathan
On Thu, 16 Aug 2018 at 15:28, Jonathan Fine <jfine2358@gmail.com> wrote:
I'd like to take this to bugs.python.org, if only to provide another route to discovering this (very useful) conversation.
That's perfectly OK, and entirely your choice. However, if you do so, I'd hope that you present the dissenting views from this list when you raise the question on b.p.o. Otherwise, you're in effect expecting all the participants here to repeat their comments on bpo, if they want their opinions to be heard, which makes this discussion somewhat irrelevant. My understanding was that a discussion here is intended to attempt to reach a broad consensus, which could *then* be presented to bpo as a proposal. But that's just my view, and if you prefer not to take that approach then that's fine. Either way, I'll probably say no more on this topic, as it appears that people have their opinions and there's not much movement towards a shared agreement. I don't have the time or inclination to participate on bpo as well, so if you do move the conversation to that forum, I'll not get involved. Regards, Paul
I agree that some more docs on the specialness of None (and, to a lessor extent, True and False). A few comments:
One of the implications of this is that “None” will always be the Singleton None object — so you can (and should) use: Something is None To test for None.
That’s a good one to highlight!
Maybe this belongs more in a discussion of “Falseyness”
This is less about None than about the convention that mutating methods return None. Maybe that discussion belongs elsewhere.
Belongs with dict docs really, and not really true — dict.get() returns the default value, which is None be default.
Yup.
This is also a convention — and primarily applies to mutable defaults, which you hardly ever want to assign directly. So a good example of None being used as a sentinel, but nog really anything special about None. -CHB
/
On Jul 23, 2018 8:43 PM, "Chris Barker - NOAA Federal via Python-ideas" < python-ideas@python.org> wrote:
This is less about None than about the convention that mutating methods return None. Maybe that discussion belongs elsewhere.
Yup. I believe these two are related and an artifact of how code/function objects always leave *something* on TOS/top-of-stack. IIRC even module objects have a discarded "return value" (in CPython at least). This internal, unseen, and very-much-special-syntax-worthy value, is None other. -- C Anthony
Here's another way that None is special. ===
For more information see https://stackoverflow.com/questions/10061752/which-classes-cannot-be-subclas... Related are https://stackoverflow.com/questions/2172189/why-i-cant-extend-bool-in-python... https://stackoverflow.com/questions/2825364/final-classes-in-python-3-x-some... -- Jonathan
On Mon, Jul 23, 2018 at 2:03 AM Jonathan Fine <jfine2358@gmail.com> wrote:
Thank you for your attention. What have I missed?
None and a few other things are special-cased by CPython. The compiler won't bother to write bytecode instructions when an if-statement obviously evaluates false. That might surprise some folks. In [1]: import dis In [2]: def foo(): ...: if None: ...: print(1) ...: if 0: ...: print(2) ...: if 'a' == 'b': ...: print(3) ...: In [3]: dis.dis(foo) 6 0 LOAD_CONST 1 ('a') 2 LOAD_CONST 2 ('b') 4 COMPARE_OP 2 (==) 6 POP_JUMP_IF_FALSE 16 7 8 LOAD_GLOBAL 0 (print) 10 LOAD_CONST 3 (3) 12 CALL_FUNCTION 1 14 POP_TOP >> 16 LOAD_CONST 0 (None) 18 RETURN_VALUE
Hi I'm pleased to announce that I've completed the first draft of my page. It's viewable on gitub. https://github.com/jfine2358/py-jfine2358/blob/master/docs/none-is-special.m... To quote from that page: This page arose from a thread on the python-ideas list. I thank Steve Dower, Paul Moore, Steve D'Aprano, Chris Barker, David Mertz, Jörn Heissler, Anthony Risinger, Michael Selik, Chris Angelico for their contributions and encouragement. Apologies for anyone I've missed. Comments either on python-ideas, or perhaps better, by raising an issue on github. -- Jonathan
Nice work, very usefull. Is it interesting enough to note that the negation of None is True? (probably just because when it's casted to bool, it becomes False). Also, even if None is seen as the value for the lack of value, it is still hashable and can be used as a key to a dict (I'm not saying it's always good practice!):
Also, I would probably have added an example of how (and why) to use a sentinel value for when None has a meaning other than [not provided] in a function's signature. You'll see if any of these is worth integrating. - Brice Le 14/08/2018 à 12:28, Jonathan Fine a écrit :
Great work! There are a few typos, I'll try to get to a PR on those. I wonder if it's worth noting that None is a singleton, while 42 is just a value. I.e. there might be several distinct objects that happen to be the int 42, but not so with None. Of course, in CPython, small integers are cached as the same object, but larger integers are not necessarily cached. This has varied in details between Python implementations and even versions, it's not a semantic promise like None carries. Maybe that's too far in the weeds for an intro though. On Tue, Aug 14, 2018, 6:29 AM Jonathan Fine <jfine2358@gmail.com> wrote:
On Tue, Aug 14, 2018 at 10:25 AM, David Mertz <mertz@gnosis.cx> wrote:
very much worth nothing -- and I think re-wording that example. The fact that you can't assign to None is orthogonal to the fact that it's immutable. in fact, [42] is a llteral for a list with one element, the integer with the value of 42 in it. It is very much a mutable. and yet: In [7]: [42] = 34 File "<ipython-input-7-b919f2b4d30d>", line 1 [42] = 34 SyntaxError: can't assign to literal whereas: [5].append(3) works -- at least it does not result in an error -- even though it's useless. And the reason this matters is that name binding (and rebinding) is very much a different operation than mutating -- we should not conflate those. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
Hi Thank you all, for the kind words and appreciation, and the comments and suggestions. I have time now to respond to one comment. Please note that is just my opinion, and your opinion may be different. Rhodri James prefers (https://mail.python.org/pipermail/python-ideas/2018-August/052742.html)
The next sentence is
In Python, we can use None to solve this problem.
I chose the punctuation I did, because I wanted to state clearly the problem. Which is, roughly speaking, damned if you do, and damned if you don't. (In the US, between a rock and a hard place.) In other words, a dilemma. https://www.dictionary.com/browse/dilemma a choice between [...] undesirable alternatives. This paragraph
Rhodri says my version, exaggerated for effect, reads like
Yes, Rhodri, you've understood what I'm doing. I do want the reader to pay careful attention. If they only remember one thing, this is what I want them to remember. Rhodri say that his version reads more easily. I agree. And that that is why I prefer my version! Sometimes you have to slow the reader down, so that there's time for understanding to catch up. Short sentences catch attention. Long sentences, with many clauses and a variation of ideas, go by like the scenery on a long and monotonous care journey. And little is remembered. The lesson I take from this is not that I am right and Rhodri is wrong. Or the other way round. That depends on context, taste and house style. And often, there are good reasons on both sides of the decision. So the starting point for persuading someone to change their mind might be this: Understand the forces that led them to the position they hold. Sometime before the end of the month, I'll process the remaining contributions and comments. I hope it doesn't take me more than an hour or two. I'll start by looking at github issues, then pull requests, and then python-ideas. Once again, thank you for all the comments and suggestions. And the kind words and appreciation. -- Jonathan
On 15/08/18 19:55, Jonathan Fine wrote:
I think you've missed your target. What people are going to remember from this construction is that sometimes we aren't able to provide a value. Oh, and you said something afterwards, was it about None? I tend to be prolix and I know it. I appreciate people who can communicate effectively in short sentences. For the most part that's what you do admirably. This one, however, is too short, and the conjunction waves a big red flag to indicate it. -- Rhodri James *-* Kynesim Ltd
On 23Jul2018 1003, Jonathan Fine wrote:
There's also https://docs.python.org/3/c-api/none.html?highlight=py_none#c.Py_None "The Python None object, denoting lack of value. This object has no methods. It needs to be treated just like any other object with respect to reference counts." I don't know that documenting the behaviours of None are that interesting (e.g. not displaying anything at the interactive prompt), though it'd be perfect for a blog and/or conference talk. But if there appear to be behaviours that are not consistent or cannot be easily inferred from the existing documentation, then we should think about why that is and how we could enhance the documentation to ensure it accurately describes what None is supposed to be. That said, your examples are good :) Cheers, Steve
On 23 July 2018 at 10:16, Steve Dower <steve.dower@python.org> wrote:
The examples are interesting, agreed. One thing they highlight to me is that most uses of None are effectively convention. The only two behaviours that are unique to None and implemented in the interpreter are: 1. Functions that don't return an explicit value return None. 2. The interactive interpreter does not display the value of a typed expression when that value is None. (the fact that None is a keyword is not unique - True and False are also keywords - although it is a distinguishing feature). One of the key points about this proposal is that it adds a number of additional ways in which the interpreter treats None specially (i.e., four dedicated operators). That elevates None from the position of being a commonly used sentinel value to one that has language support for being a sentinel. That's not necessarily a bad thing, but it is a point that should be considered when reviewing this PEP (people who prefer to use object() for their sentinels are probably less happy about making None "special", for example - Pandas uses NaN as the "missing data" sentinel rather than None, although Pandas' focus on bulk processing means that dedicated operators probably wouldn't help anyway). Overall, my personal feeling is that I do use None specially (and a lot of code I see does too), so having None-aware operators has some merit. But I don't find None to be special enough to warrant quite this *many* operators, nor do I find that the patterns that operators like ?. and ?[ support are ones I use a lot. Actually, the ?. and ?[ operators seem like they'd be much more useful if I did more JSON processing - but I don't, so I have little feel for whether language support is needed here or whether better library support (stdlib and/or 3rd party) for optional data is sufficient. Paul
Hi Paul Thank you for your contribution
I broadly agree with what you say, particularly the compliment. You also wrote:
One of the key points about this proposal [PEP 505]
My goal in this thread is to document clearly and develop a clear shared understanding of the ways in which None is special in Python. Please, please, please can we not discuss PEP 505 in this thread. There's already another thread for that. I want this thread to produce a web page that is useful for beginners and intermediate Python programmers (which perhaps some experts might also benefit from reading). -- Jonathan
On 23 July 2018 at 12:24, Jonathan Fine <jfine2358@gmail.com> wrote:
OK, apologies for my confusion between the threads.
My view would be basically "None isn't special, it's just another value. By the time you understand enough to want to treat None specially, you probably already know enough about how the language does". That's very over-simplified, sure, but I really don't see None as *that* special except in the context of non-beginner ideas like "it's similar to SQL NULL", or "it's like a null pointer in C". In my experience, I've found I tend more to be explaining to beginners why None *isn't* special than why it is. Which is why I found your list of examples interesting, because many of them were about convention rather than language support. Paul
On Mon, Jul 23, 2018 at 12:15:14PM +0100, Paul Moore wrote:
That is built into the language.
2. The interactive interpreter does not display the value of a typed expression when that value is None.
But that is not built-in, it is merely the default behaviour. It is controlled by sys.displayhook, which can be customized: https://docs.python.org/3/library/sys.html#sys.displayhook We can have many interactive interpreters, including iPython, bpython, IDLE, etc and they don't necessarily suppress the printing of None.
One of the key points about this proposal
That would be the None-aware PEP, not Jonathon's proposal to add documentation about None.
None is already a special value. It is so special, it is one of only three built-in values given keyword status. All the other built-ins, including such things that are used implicitly by the interpreter (such as NotImplemented) are merely ordinary names.
You make it sound like its a mere aesthetic choice. None is the default, recommended, most convenient sentinel. I use object() as a sentinel, when None is an otherwise ordinary value. I am also happy for None to be special, because it *is* special. -- Steve
Hi Steve In this thread you wrote, replying to Paul Moore's comments on PEP 505
Half an hour earlier, Paul wrote (in reply to me)
Paul has implicitly removed from this thread his comments on PEP 505. If you wish to respond to Paul's comments, please do so elsewhere. There's already a thread for PEP 505. -- Jonathan
This has been mentioned a lot in this discussion— Maybe what we need is a smarter JSON processing package, rather than new operators. Granted, these operators would help the authors of suck a package(s), but if the bulk of users didn’t need them, then no point in adding them to the language. -CHB
On Mon, Jul 23, 2018 at 10:03:10AM +0100, Jonathan Fine wrote:
I thought, a page on how None is special would be nice.
I think your document would be a great blog post. I don't think it is very helpful as part of the standard documention, as it is more a collection of arbitrary facts about None than a coherent "big picture" document. We could come up with such arbitrary lists for many other standard objects too: "Did you know... that operator dunder methods should return NotImplemented to signal to the interpreter that the other operand's method should be called?" "Did you know that Ellipsis is the sole instance of class ellipsis, reversing the usual convention that classes use InitialCaps and instances lowercase?" -- Steve
Hi Steve You wrote
Thank you. That's nice. However, I think there is, or should be, more coherence than you're seeing. Here's something I forgot to say. For standard documentation I was thinking The Python Tutorial. For example, the Brief Tour. https://docs.python.org/3/tutorial/stdlib.html https://docs.python.org/3/tutorial/stdlib2.html That said, a blog post would be useful stepping stone, and the standard documentation later. (Know where your heading, take one step at a time.) Once again, thank you for your comment. -- Jonathan
I think your description of the uses of None is really great. There's definitely no reason it cannot be a blog post immediately, but perhaps at some later point included in The Python Tutorial. On Mon, Jul 23, 2018 at 8:39 AM Jonathan Fine <jfine2358@gmail.com> wrote:
-- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.
On Mon, Jul 23, 2018 at 10:03:10 +0100, Jonathan Fine wrote:
Hi, there's also https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarc... None This type has a single value. There is a single object with this value. This object is accessed through the built-in name None. It is used to signify the absence of a value in many situations, e.g., it is returned from functions that don’t explicitly return anything. Its truth value is false. Cheers Jörn Heissler
Is None a builtin? In [1]: from keyword import kwlist In [3]: 'Ellipsis' in kwlist Out[3]: False In [4]: 'None' in kwlist Out[4]: True Maybe we should change This type has a single value. There is a single object with this value. This object is accessed through the built-in name None. It is used to signify the absence of a value in many situations, e.g., it is returned from functions that don’t explicitly return anything. Its truth value is false. to This type has a single value. There is a single object with this value. This object is accessed through the keyword None. It is used to signify the absence of a value in many situations, e.g., it is returned from functions that don’t explicitly return anything. Its truth value is false. Best, Neil On Monday, July 23, 2018 at 2:31:21 PM UTC-4, Jörn Heissler wrote:
Hi Neil Thank you for your post, regarding https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarc.... You've suggested changing "built-in name None" to "keyword None". I think that's a good change. And similar changes might be welcome elsewhere in the docs, perhaps also for True and False. And I think there's more. The page says
None This type has a single value. There is a single object with this value. [...]
I think it better to write
NoneType This type has a single value, `None`. The keyword `None` always gives the value `None`.
I think the best way forward here is to raise an issue on https://bugs.python.org/. Would you be willing to do this? If you need it, there's help available at https://devguide.python.org/triaging/. Once again, thank you for your close attention to detail. -- Jonathan
Hi Rhodri Thank you for your message. You wrote:
The decision is neither your's nor mine. It is for the Python docs maintainers. I will respect their decision, even if I don't agree with it. I intend, in my page (on why None is special) to continue to quote accurately, and without criticism, the current Python docs. One intention of my post is to move the particular docs discussion from python-ideas and to bugs.python.org. I think that is a better place for it. They're the people who can decide and do (or not do) something about it. -- with best regards Jonathan
On Thu, 16 Aug 2018 at 14:26, Rhodri James <rhodri@kynesim.co.uk> wrote:
I agree that the original is better. I think the important thing (which doesn't come across when quoting text in email) is the typography. ``` None This type has a single value. There is a single object with this value. This object is accessed through the built-in name None. [...] ``` The initial "None" is on a line by itself, and is in "normal text" font, outdented from the following text. As it's in a section called "The standard type hierarchy", this reads to me as referring to a type, informally named as "None". It's not referring to the Python keyword None, which is formatted differently (monospace with a grey background). Conversely, the "None" in the phrase "the built-in name None" *is* formatted to indicate that it's the Python keyword. The typography makes it quite clear (to me) that there are two different *concepts* being discussed here, and furthermore, the wording clearly implies that neither of these concepts is precisely equivalent to the "single value" of the None type. It's easy when discussion wording in a plain-text medium like email to ignore the impact of formatting on how the meaning of a piece of text is conveyed. In this case, I think that the details are subtle enough that the typography is critical to getting the message across. One thing that *isn't* conveyed by the description here is the distinction between `None` and `Ellipsis`. The two relevant sections say This object is accessed through the built-in name None This object is accessed through the literal ... or the built-in name Ellipsis But you can't assign to (the name) None, and yet you can to (the name) Ellipsis. It might be better to say "the keyword None" in the section on None, to make that distinction. But that's the only change I'd make. Paul PS I should say that I would not expect any of the fine distinctions I've drawn in the above to be obvious to non-native speakers of English. That's a very different problem to handle, and one that is orders of magnitude harder than the comparatively simple task of trying to distinguish between None the type, the keyword and the value :-)
Hi Paul Thank you for your comments. I think different people experience things in different ways, based on who they are. What their background, training, experience are. One person's precision is another's pedantry. An aside. Babbage and Tennyson: https://www.uh.edu/engines/epi879.htm You wrote
When I read the same text, I don't see an informal name. I see a false statement. By the way, here's why I see a false statement:
type(int), type(dict), type(str) (<class 'type'>, <class 'type'>, <class 'type'>)
type(None), type(type(None)) (<class 'NoneType'>, <class 'type'>)
My (pure mathematics research) background leads me to dislike precise statements that are not true. That's the way I am. Rhodri James doesn't like sentences that begin with 'But'. An aside. Reading further in https://docs.python.org/3/reference/datamodel.html, I see three times "This type has a single value." The informal names are None, NotImplemented and Ellipsis. And there are only two Booleans. I'd like to take this to bugs.python.org, if only to provide another route to discovering this (very useful) conversation. Perhaps one day, we'll have here harmony between informality and precision. Perhaps every popular computer language has this as a goal. -- with best regards Jonathan
On Thu, 16 Aug 2018 at 15:28, Jonathan Fine <jfine2358@gmail.com> wrote:
I'd like to take this to bugs.python.org, if only to provide another route to discovering this (very useful) conversation.
That's perfectly OK, and entirely your choice. However, if you do so, I'd hope that you present the dissenting views from this list when you raise the question on b.p.o. Otherwise, you're in effect expecting all the participants here to repeat their comments on bpo, if they want their opinions to be heard, which makes this discussion somewhat irrelevant. My understanding was that a discussion here is intended to attempt to reach a broad consensus, which could *then* be presented to bpo as a proposal. But that's just my view, and if you prefer not to take that approach then that's fine. Either way, I'll probably say no more on this topic, as it appears that people have their opinions and there's not much movement towards a shared agreement. I don't have the time or inclination to participate on bpo as well, so if you do move the conversation to that forum, I'll not get involved. Regards, Paul
I agree that some more docs on the specialness of None (and, to a lessor extent, True and False). A few comments:
One of the implications of this is that “None” will always be the Singleton None object — so you can (and should) use: Something is None To test for None.
That’s a good one to highlight!
Maybe this belongs more in a discussion of “Falseyness”
This is less about None than about the convention that mutating methods return None. Maybe that discussion belongs elsewhere.
Belongs with dict docs really, and not really true — dict.get() returns the default value, which is None be default.
Yup.
This is also a convention — and primarily applies to mutable defaults, which you hardly ever want to assign directly. So a good example of None being used as a sentinel, but nog really anything special about None. -CHB
/
On Jul 23, 2018 8:43 PM, "Chris Barker - NOAA Federal via Python-ideas" < python-ideas@python.org> wrote:
This is less about None than about the convention that mutating methods return None. Maybe that discussion belongs elsewhere.
Yup. I believe these two are related and an artifact of how code/function objects always leave *something* on TOS/top-of-stack. IIRC even module objects have a discarded "return value" (in CPython at least). This internal, unseen, and very-much-special-syntax-worthy value, is None other. -- C Anthony
Here's another way that None is special. ===
For more information see https://stackoverflow.com/questions/10061752/which-classes-cannot-be-subclas... Related are https://stackoverflow.com/questions/2172189/why-i-cant-extend-bool-in-python... https://stackoverflow.com/questions/2825364/final-classes-in-python-3-x-some... -- Jonathan
On Mon, Jul 23, 2018 at 2:03 AM Jonathan Fine <jfine2358@gmail.com> wrote:
Thank you for your attention. What have I missed?
None and a few other things are special-cased by CPython. The compiler won't bother to write bytecode instructions when an if-statement obviously evaluates false. That might surprise some folks. In [1]: import dis In [2]: def foo(): ...: if None: ...: print(1) ...: if 0: ...: print(2) ...: if 'a' == 'b': ...: print(3) ...: In [3]: dis.dis(foo) 6 0 LOAD_CONST 1 ('a') 2 LOAD_CONST 2 ('b') 4 COMPARE_OP 2 (==) 6 POP_JUMP_IF_FALSE 16 7 8 LOAD_GLOBAL 0 (print) 10 LOAD_CONST 3 (3) 12 CALL_FUNCTION 1 14 POP_TOP >> 16 LOAD_CONST 0 (None) 18 RETURN_VALUE
On Fri, Jul 27, 2018 at 9:20 AM, Michael Selik <mike@selik.org> wrote:
That's true of ANY constant, though. And a future version of Python could well constant-fold the comparison, and thus optimize out the third condition too. There's nothing special about None here. ChrisA
Hi I'm pleased to announce that I've completed the first draft of my page. It's viewable on gitub. https://github.com/jfine2358/py-jfine2358/blob/master/docs/none-is-special.m... To quote from that page: This page arose from a thread on the python-ideas list. I thank Steve Dower, Paul Moore, Steve D'Aprano, Chris Barker, David Mertz, Jörn Heissler, Anthony Risinger, Michael Selik, Chris Angelico for their contributions and encouragement. Apologies for anyone I've missed. Comments either on python-ideas, or perhaps better, by raising an issue on github. -- Jonathan
Nice work, very usefull. Is it interesting enough to note that the negation of None is True? (probably just because when it's casted to bool, it becomes False). Also, even if None is seen as the value for the lack of value, it is still hashable and can be used as a key to a dict (I'm not saying it's always good practice!):
Also, I would probably have added an example of how (and why) to use a sentinel value for when None has a meaning other than [not provided] in a function's signature. You'll see if any of these is worth integrating. - Brice Le 14/08/2018 à 12:28, Jonathan Fine a écrit :
Great work! There are a few typos, I'll try to get to a PR on those. I wonder if it's worth noting that None is a singleton, while 42 is just a value. I.e. there might be several distinct objects that happen to be the int 42, but not so with None. Of course, in CPython, small integers are cached as the same object, but larger integers are not necessarily cached. This has varied in details between Python implementations and even versions, it's not a semantic promise like None carries. Maybe that's too far in the weeds for an intro though. On Tue, Aug 14, 2018, 6:29 AM Jonathan Fine <jfine2358@gmail.com> wrote:
On Tue, Aug 14, 2018 at 10:25 AM, David Mertz <mertz@gnosis.cx> wrote:
very much worth nothing -- and I think re-wording that example. The fact that you can't assign to None is orthogonal to the fact that it's immutable. in fact, [42] is a llteral for a list with one element, the integer with the value of 42 in it. It is very much a mutable. and yet: In [7]: [42] = 34 File "<ipython-input-7-b919f2b4d30d>", line 1 [42] = 34 SyntaxError: can't assign to literal whereas: [5].append(3) works -- at least it does not result in an error -- even though it's useless. And the reason this matters is that name binding (and rebinding) is very much a different operation than mutating -- we should not conflate those. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
Hi Thank you all, for the kind words and appreciation, and the comments and suggestions. I have time now to respond to one comment. Please note that is just my opinion, and your opinion may be different. Rhodri James prefers (https://mail.python.org/pipermail/python-ideas/2018-August/052742.html)
The next sentence is
In Python, we can use None to solve this problem.
I chose the punctuation I did, because I wanted to state clearly the problem. Which is, roughly speaking, damned if you do, and damned if you don't. (In the US, between a rock and a hard place.) In other words, a dilemma. https://www.dictionary.com/browse/dilemma a choice between [...] undesirable alternatives. This paragraph
Rhodri says my version, exaggerated for effect, reads like
Yes, Rhodri, you've understood what I'm doing. I do want the reader to pay careful attention. If they only remember one thing, this is what I want them to remember. Rhodri say that his version reads more easily. I agree. And that that is why I prefer my version! Sometimes you have to slow the reader down, so that there's time for understanding to catch up. Short sentences catch attention. Long sentences, with many clauses and a variation of ideas, go by like the scenery on a long and monotonous care journey. And little is remembered. The lesson I take from this is not that I am right and Rhodri is wrong. Or the other way round. That depends on context, taste and house style. And often, there are good reasons on both sides of the decision. So the starting point for persuading someone to change their mind might be this: Understand the forces that led them to the position they hold. Sometime before the end of the month, I'll process the remaining contributions and comments. I hope it doesn't take me more than an hour or two. I'll start by looking at github issues, then pull requests, and then python-ideas. Once again, thank you for all the comments and suggestions. And the kind words and appreciation. -- Jonathan
On 15/08/18 19:55, Jonathan Fine wrote:
I think you've missed your target. What people are going to remember from this construction is that sometimes we aren't able to provide a value. Oh, and you said something afterwards, was it about None? I tend to be prolix and I know it. I appreciate people who can communicate effectively in short sentences. For the most part that's what you do admirably. This one, however, is too short, and the conjunction waves a big red flag to indicate it. -- Rhodri James *-* Kynesim Ltd
participants (14)
-
Brice Parent -
C Anthony Risinger -
Chris Angelico -
Chris Barker -
Chris Barker - NOAA Federal
-
David Mertz -
Jonathan Fine -
Jörn Heissler -
Michael Selik -
Neil Girdhar -
Paul Moore -
Rhodri James -
Steve Dower -
Steven D'Aprano