[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

[Doug Swarin]

Steven D'Aprano wrote:
> Hello Doug,
> On Thu, Oct 14, 2021 at 03:45:07PM -, Doug Swarin wrote:
> > I believe strong and valid arguments can be made about the use of None 
> > being a fundamental flaw in some types of coding
> > Can you elaborate on that? Obviously it is not always appropriate to use 
> None, but I've never seen it called a *fundamental* flaw.
> I know that the null pointer has been called a billion-dollar mistake,
> but Python's None is not a null pointer.

I apologize that I may have spoken too strongly here. When I emailed Mr. Dower, 
he mentioned that he now believes the implementation of these operators would 
lead people to a style of coding which would lead to the proliferation of None 
as an exception-less error result and also throughout data structures. My 
understanding is that his current preference is to focus on functional 
composition and styles of programming that disallow the use of None.

I certainly don't mean to speak for him and I hope he will weigh in with a more 
detailed explanation of his thoughts and objections, but I personally disagree 
as a matter of pure practicality. It's just plain useful to be able to easily 
take non-values and safely deal with them without having to constantly check 
for None or to catch and inspect exceptions to see if it's a case that can be 
ignored.

I did indeed think about connecting None to the 'billion dollar mistake' but 
decided against it since as you say None is not a null pointer, and I should 
have chosen my words a little more carefully when revising my initial post 
(likely by removing the word 'fundamental').

Doug
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QDUJ6SIZWUMJ6YJDJRYZ4JA2GKSLJJ7I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

[Steven D'Aprano]

Hello Doug,

On Thu, Oct 14, 2021 at 03:45:07PM -, Doug Swarin wrote:

> I believe strong and valid arguments can be made about the use of None 
> being a fundamental flaw in some types of coding

Can you elaborate on that? Obviously it is not always appropriate to use 
None, but I've never seen it called a *fundamental* flaw.

I know that the null pointer has been called a billion-dollar mistake,
but Python's None is not a null pointer.


-- 
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IGA7GYE2M6KQVOGIP3X2EESOXYUOMXMC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

[Jeremiah Vivian]

I tried to implement this in CPython by modifying a downloaded source code, but 
I can't seem to fix the problem of the "maybe" operators segfaulting when being 
used with literal immutables. The maybe-assign/coalesce operators were 
implemented successfully though.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2TGUBJFMNKTCG4IIOE444CYIUT4GZBDI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

[Guido van Rossum]

Thanks -- this is the kind of work that helps a PEP get accepted. I am
personally in favor of accepting PEP 505, and I hope that your work and the
discussion that will undoubtedly follow here will help convince the
Steering Council to accept it.

--Guido

On Thu, Oct 14, 2021 at 10:38 AM Doug Swarin  wrote:

> Hello,
>
> I've been following PEP 505 (https://www.python.org/dev/peps/pep-0505/)
> since it was first proposed for Python 3.8. It's been deferred for some
> time and I'm interested in seeing it in Python 3.11, but I know there were
> also a number of objections which resulted in it being deferred (including
> by one of the original authors, Mr. Dower). I did email both Mr. Dower and
> Mr. Haase and they graciously gave me their permission to bring it up on
> this list for discussion and hopefully final pronouncement one way or the
> other.
>
> I personally believe that the PEP will result in a significant reduction
> in boilerplate code, and it is substantially similar to the same operators
> now found in a number of other languages, especially C# and JavaScript (
> https://wikipedia.org/wiki/Null_coalescing_operator and
> https://wikipedia.org/wiki/Safe_navigation_operator).
>
> I believe strong and valid arguments can be made about the use of None
> being a fundamental flaw in some types of coding (and that adding
> additional support for it to the language will increase the use of None in
> this way), but I also believe there are many use cases in programming where
> it is by far the simplest way to express various semantics, and the fact
> exists that None is already used extensively in large quantities of code,
> and further that there is already a great deal of code written to
> constantly test against None and break out of a statement without throwing
> an error.
>
> I also understand the argument that especially the maybe-dot (?.) and
> maybe-subscript (?[) operators can decrease readability of code and also
> believe these are valid arguments against it. While I believe the existence
> and use of these operators in other languages definitely helps the case
> that these can be used and understood successfully, I think it is entirely
> valid to either consider other syntax (though I prefer the chosen syntax of
> PEP 505), or even to reduce PEP 505 to having only the coalesce operator
> (??) and the maybe-assign operator (??=).
>
> Separately, I have implemented a pure-Python solution for PEP505 (which is
> definitely rather beta) which might help test the waters for a final
> implementation in CPython (though the CPython implementation would of
> course be much more efficient). It can be found at
> https://pypi.org/project/pep505/
>
> Thanks,
> Doug
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/XZZIV42XGG3EIHRBBCCTTCFPWWSOT7MX/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BFL7R3HYXAVEZDW4FNVUM7SVPE373ZAX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] PEP 505 (None-aware operators) for Python 3.11

[Doug Swarin]

Hello,

I've been following PEP 505 (https://www.python.org/dev/peps/pep-0505/) since 
it was first proposed for Python 3.8. It's been deferred for some time and I'm 
interested in seeing it in Python 3.11, but I know there were also a number of 
objections which resulted in it being deferred (including by one of the 
original authors, Mr. Dower). I did email both Mr. Dower and Mr. Haase and they 
graciously gave me their permission to bring it up on this list for discussion 
and hopefully final pronouncement one way or the other.

I personally believe that the PEP will result in a significant reduction in 
boilerplate code, and it is substantially similar to the same operators now 
found in a number of other languages, especially C# and JavaScript 
(https://wikipedia.org/wiki/Null_coalescing_operator and 
https://wikipedia.org/wiki/Safe_navigation_operator).

I believe strong and valid arguments can be made about the use of None being a 
fundamental flaw in some types of coding (and that adding additional support 
for it to the language will increase the use of None in this way), but I also 
believe there are many use cases in programming where it is by far the simplest 
way to express various semantics, and the fact exists that None is already used 
extensively in large quantities of code, and further that there is already a 
great deal of code written to constantly test against None and break out of a 
statement without throwing an error.

I also understand the argument that especially the maybe-dot (?.) and 
maybe-subscript (?[) operators can decrease readability of code and also 
believe these are valid arguments against it. While I believe the existence and 
use of these operators in other languages definitely helps the case that these 
can be used and understood successfully, I think it is entirely valid to either 
consider other syntax (though I prefer the chosen syntax of PEP 505), or even 
to reduce PEP 505 to having only the coalesce operator (??) and the 
maybe-assign operator (??=).

Separately, I have implemented a pure-Python solution for PEP505 (which is 
definitely rather beta) which might help test the waters for a final 
implementation in CPython (though the CPython implementation would of course be 
much more efficient). It can be found at https://pypi.org/project/pep505/

Thanks,
Doug
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XZZIV42XGG3EIHRBBCCTTCFPWWSOT7MX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP-646 question: unpacking into single Generic parameter

[Matthew Rahtz via Python-Dev]

Oops, sorry for the slow reply - I'm not subscribed to this mailing list.

As Mehdi2277 says, this would indeed require the Map operator we'll introduce 
in a future PEP.

But that's a good point about the `*Tuple[int, Ts]` syntax. I think the 
interpretation of it that would be most consistent with the rest of PEP 646 
would actually be something slightly different than you had in mind - instead 
of saying that the Callable took args like

Tuple[int, Ts[0]], Tuple[int, Ts[1]], ...

it would say that the Callable took a variable number of arguments, the first 
of which was `int`, and the rest of which are bound to `Ts`. And this is indeed 
something we haven't talked about explicitly how to specify yet.

Most of the discussion of PEP 646 has taken place on typing-sig, so I'll start 
a new thread there to discuss this.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PZYE2XNNOF3WCU4DXSLYFKOXDZW6WNJA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: What is __int__ still useful for?

[Serhiy Storchaka]

14.10.21 12:24, Eryk Sun пише:
> Maybe an alternate constructor could be added -- such as
> int.from_number() -- which would be restricted to calling __int__(),
> __index__(), and __trunc__().

See thread "More alternate constructors for builtin type" on Python-ideas:
https://mail.python.org/archives/list/python-id...@python.org/thread/5JKQMIC6EUVCD7IBWMRHY7DRTTNSBOWG/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NU3774YDVCIUH44C7RZXCSSVRVYSLCUI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: What is __int__ still useful for?

[Antoine Pitrou]

On Thu, 14 Oct 2021 04:24:30 -0500
Eryk Sun  wrote:
> 
> > Note that PyNumber_Long() is now the only place inside the interpreter
> > calling the `nb_int` slot.  But since it also has those undesirable code
> > paths accepting str and buffer-like objects, it's usable in fewer
> > situations than you'd expect.  
> 
> Maybe an alternate constructor could be added -- such as
> int.from_number() -- which would be restricted to calling __int__(),
> __index__(), and __trunc__().

Perhaps.  And ideally there would be a corresponding C API.

Regards

Antoine.


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GL4XG2OW2ZZ7F45ILP4756WT5ALCVBOE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: What is __int__ still useful for?

[Eryk Sun]

On 10/14/21, Antoine Pitrou  wrote:
> On Wed, 13 Oct 2021 17:00:49 -0700
> Guido van Rossum  wrote:
>>
>> so int() can't call __trunc__ (as was explained earlier in
>> the thread).

I guess this was meant to be "*just* call __trunc__". It's documented
that the int constructor calls the initializing object's __trunc__()
method if the object doesn't implement __int__() or __index__().

> Note that PyNumber_Long() is now the only place inside the interpreter
> calling the `nb_int` slot.  But since it also has those undesirable code
> paths accepting str and buffer-like objects, it's usable in fewer
> situations than you'd expect.

Maybe an alternate constructor could be added -- such as
int.from_number() -- which would be restricted to calling __int__(),
__index__(), and __trunc__().
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/Q77PFIMCHDGB36LZTNMFG6NF7DE2UOSF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: What is __int__ still useful for?

[Antoine Pitrou]

On Wed, 13 Oct 2021 17:00:49 -0700
Guido van Rossum  wrote:
> On Wed, Oct 13, 2021 at 4:56 PM Victor Stinner  wrote:
> 
> > Honestly, I don't understand well the difference between __int__() and
> > __index__().
> >
> > * https://docs.python.org/dev/reference/datamodel.html#object.__int__
> > * https://docs.python.org/dev/reference/datamodel.html#object.__index__
> >  
> 
> If you want to index a list or array 'a' with index 'i', and i is not an
> int already, we try to convert it to int using __index__. This should fail
> for floats, since a[3.14] is a bug. OTOH, int(x) where x is a float should
> And int(s) where s is a string
> should also work, so int() can't call __trunc__ (as was explained earlier
> in the thread).

This seems like a red herring, because str.__int__ is not defined.  The
code to make int(str) work is a separate code path inside
PyNumber_Long().

Note that PyNumber_Long() is now the only place inside the interpreter
calling the `nb_int` slot.  But since it also has those undesirable code
paths accepting str and buffer-like objects, it's usable in fewer
situations than you'd expect.

Regards

Antoine.


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3BLOMBMUBTQMOZW7GBZS7DSP25MNOKUX/
Code of Conduct: http://python.org/psf/codeofconduct/