Make type(None) the no-op function
Currently type(None) returns None if you call it with no args:
print(type(None)()) None
it'd be nice if it did the same regardless of args. currently it raises:
print(type(None)(1)) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: NoneType takes no arguments
inspired by PEP 559: https://www.python.org/dev/peps/pep-0559/
NoneType Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'NoneType' is not defined
On Sat, Apr 25, 2020 at 1:20 AM Soni L. <fakedme+py@gmail.com> wrote:
Currently type(None) returns None if you call it with no args:
print(type(None)()) None
it'd be nice if it did the same regardless of args. currently it raises:
print(type(None)(1)) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: NoneType takes no arguments
inspired by PEP 559: https://www.python.org/dev/peps/pep-0559/
NoneType Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'NoneType' is not defined
Why should NoneType be any different from other types? If you want a null function, just create one: def return_none(*_a, **_kw): pass What is your use-case for wanting NoneType to behave in this way? Is this yet another idea that actually has no use-case and is just "wouldn't it be nice if we did weird stuff to the language"? I'm starting to have to read python-ideas by first looking at the poster and only then consider the content of the suggestion, instead of what I usually prefer, which is to evaluate an idea on its merits regardless of who posted it. ChrisA
On 2020-04-24 12:26 p.m., Chris Angelico wrote:
On Sat, Apr 25, 2020 at 1:20 AM Soni L. <fakedme+py@gmail.com> wrote:
Currently type(None) returns None if you call it with no args:
print(type(None)()) None
it'd be nice if it did the same regardless of args. currently it raises:
print(type(None)(1)) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: NoneType takes no arguments
inspired by PEP 559: https://www.python.org/dev/peps/pep-0559/
NoneType Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'NoneType' is not defined
Why should NoneType be any different from other types? If you want a null function, just create one:
def return_none(*_a, **_kw): pass
What is your use-case for wanting NoneType to behave in this way? Is this yet another idea that actually has no use-case and is just "wouldn't it be nice if we did weird stuff to the language"? I'm starting to have to read python-ideas by first looking at the poster and only then consider the content of the suggestion, instead of what I usually prefer, which is to evaluate an idea on its merits regardless of who posted it.
it's not my own use case for once. the PEP clearly lists a use-case. we should support that use-case.
ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KHRYFI... Code of Conduct: http://python.org/psf/codeofconduct/
On Sat, Apr 25, 2020 at 1:44 AM Soni L. <fakedme+py@gmail.com> wrote:
On 2020-04-24 12:26 p.m., Chris Angelico wrote:
On Sat, Apr 25, 2020 at 1:20 AM Soni L. <fakedme+py@gmail.com> wrote:
Currently type(None) returns None if you call it with no args:
print(type(None)()) None
it'd be nice if it did the same regardless of args. currently it raises:
print(type(None)(1)) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: NoneType takes no arguments
inspired by PEP 559: https://www.python.org/dev/peps/pep-0559/
NoneType Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'NoneType' is not defined
Why should NoneType be any different from other types? If you want a null function, just create one:
def return_none(*_a, **_kw): pass
What is your use-case for wanting NoneType to behave in this way? Is this yet another idea that actually has no use-case and is just "wouldn't it be nice if we did weird stuff to the language"? I'm starting to have to read python-ideas by first looking at the poster and only then consider the content of the suggestion, instead of what I usually prefer, which is to evaluate an idea on its merits regardless of who posted it.
it's not my own use case for once. the PEP clearly lists a use-case. we should support that use-case.
1) That PEP is rejected YAGNI. So the use-case isn't strong enough. 2) Why should it be NoneType? That makes no sense. Do you *actually* have a use-case for having NoneType always return None and ignore its arguments? ChrisA
On Apr 24, 2020, at 08:46, Soni L. <fakedme+py@gmail.com> wrote:
it's not my own use case for once. the PEP clearly lists a use-case. we should support that use-case.
So your use case is the rationale from a PEP written because Barry “can’t resist” and rejected as a joke in record time, for which a better solution was already added (use 0 for the environment variable) 3 years ago. And you ended your email with this code snippet:
NoneType Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'NoneType' is not defined
… which demonstrates that even if you had a real need for a PYTHON_BREAKPOINT=noop, your proposal wouldn’t have helped anyway. There is actually a way you could pass it, but if you don’t know that way, and felt the need to show us that you don’t know it, that can’t be your use case. And even after you figure it out, it would hardly be any more obvious to other people who need a noop function where to go digging for it than it was for you.
Soni L. wrote:
it'd be nice if it did the same regardless of args.
Sorry, but "it'd be nice" is not a real world use case.
inspired by PEP 559: https://www.python.org/dev/peps/pep-0559/
That PEP was rejected. It's okay to use previously rejected proposals for inspiration, but your proposal would have to include additional real world use cases and arguments that weren't provided in the original PEP. I'm not seeing that in the post above. Many of your previous proposals have led to some interesting discussions, but this one seems exceptionally under-developed. There's nothing wrong with a well developed proposal that gets rejected (as it can lead to highly constructive discussions), or a newcomer to the list that doesn't realize how high the bar is; however, that does not seem to be the case here. Soni, I hope this doesn't come across as harsh and I really don't want to discourage you from making proposals in general, but it's rather inconsiderate of the time of the subscribers to the list to repeatedly post under-developed proposals that lack any real use cases or strong arguments that weren't previously rejected. Remember, everyone taking the time to read your proposal is doing so entirely voluntarily. If you continue to make these types of proposals, you'll soon find that they will not be seriously considered or given as much attention as they otherwise would; making it even more difficult for the proposal to make it into the language (which I assume is a goal). In order for any major/fundamental change proposal to be accepted, it has be sponsored by a core developer, converted into a formal PEP, and then eventually approved by the SC if there's adequate consensus. So, if your proposals stop receiving attention because of a large volume of recent prior proposals that weren't adequately developed, it will be much more difficult, if not practically impossible to find a willing sponsor. Moving forward, I would highly recommend looking at some of the prior proposals on this list that were accepted, and then try to frame yours based upon them. Before posting it to the list, think: "How would this change improve the experience of users? What specific real-world use cases does it have? Is the potential benefit worth the implementation, review, and indefinite maintenance cost? Has a similar proposal been made before? If so, are my counter arguments for the previous rejection reasons strong enough to justify another proposal?". If those questions can't be answered, the proposal is most likely not worth posting in the first place. On Fri, Apr 24, 2020 at 11:19 AM Soni L. <fakedme+py@gmail.com> wrote:
Currently type(None) returns None if you call it with no args:
print(type(None)()) None
it'd be nice if it did the same regardless of args. currently it raises:
print(type(None)(1)) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: NoneType takes no arguments
inspired by PEP 559: https://www.python.org/dev/peps/pep-0559/
NoneType Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'NoneType' is not defined
Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7NZM6X... Code of Conduct: http://python.org/psf/codeofconduct/
participants (4)
-
Andrew Barnert -
Chris Angelico -
Kyle Stanley -
Soni L.