date:20220920

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

2022-09-20 Thread Petr Viktorin

On 19. 09. 22 17:58, Guido van Rossum wrote:
Personally I think returning None is a fine API design, and IMO the
concerns about this pattern are overblown. Note that X|None is no
different than the "Maybe X" pattern that functional programmers are so
fond of.

I must disagree here. With `X|None` there is no way to do
`Maybe[Maybe[X]]`, and FP is all about proper composition.

One practical consequence is that "Maybe X" doesn't have the problem
that PEP 661 (Sentinel Values) tries to solve.

On Mon, Sep 19, 2022 at 8:02 AM Philipp Burch > wrote:

Hi all,

I've only here found out that there is a discussion going on about
those
none-aware operators and my first thought was "great, finally!". FWIW,
I'd be happy with the syntax suggestion in the PEP, since '?' looks
rather intuitive to me to mean something like "maybe".

However, I then read the mentioned post of Steve Dower, with the final
summary:

> So to summarise my core concern - allowing an API designer to "just
use None" is a cop out, and it lets people write lazy/bad APIs rather
than coming up with good ones.

This is a very good point. In fact, I've never really thought about it
that way and of course he's totally right that "SomeType | None" (or
Optional[SomeType], which also somehow made me feel that this usage is
fairly intended) is not optimal, at least for user defined
types/classes. The problem is, that I never actually thought about his
suggested way. And I wouldn't be surprised if this holds for many other
people as well.

Maybe it would be great to boldly mention these thoughts in the
documentation at an appropriate place. In my opinion, there are at
least
the following good places where this would fit nicely:

- The documentation of the dataclasses
(https://docs.python.org/3/library/dataclasses.html
), since this is
probably the most common use case for the "| None" pattern. Going
further, the dataclasses functionality might even be extended to
make it
simpler to generate such null-types (or however they are called), so
that it is no longer "a tonne more work".

- Linters like pylint could emit a note when seeing the "| None"
pattern, linking to the explanation about why it is possibly not the
best way to do it.

- The documentation of the discussed None-aware operators. Since these
new operators are closely coupled to the arguably suboptimal "| None"
pattern, it is probably good to tell folks right there why they should
consider better alternatives.

As mentioned, I absolutely see Steve's point. However, there are many
Python scripts/programs working without a complex API, where this "|
None" pattern may still have its legitimate uses and the none-aware
operators can make code easier to read (and write).

Best regards,
Philipp
___
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/Q2MOF5CJ7LSSZMEMB43YVEXD6PFATYTA/

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/7HEZXSLT2A63RDLXTJAOQWGBHNU3WDCR/
Code of Conduct: http://python.org/psf/codeofconduct/

___
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/MB6DFTH3CEDKP45YELP4GZ7R7LZSPTZ2/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2022-09-20 Thread Petr Viktorin

On 20. 09. 22 10:59, Petr Viktorin wrote:

I must disagree here. With `X|None` there is no way to do
`Maybe[Maybe[X]]`, and FP is all about proper composition.

One practical consequence is that "Maybe X" doesn't have the problem
that PEP 661 (Sentinel Values) tries to solve.

Sorry, hit Send too soon: I'm not arguing against returning None being
good design. Just the note that compares it to FP's Maybe.

On Mon, Sep 19, 2022 at 8:02 AM Philipp Burch > wrote:

Hi all,

I've only here found out that there is a discussion going on about
those
none-aware operators and my first thought was "great, finally!".
FWIW,

I'd be happy with the syntax suggestion in the PEP, since '?' looks
rather intuitive to me to mean something like "maybe".

However, I then read the mentioned post of Steve Dower, with the
final

summary:

> So to summarise my core concern - allowing an API designer to
"just

use None" is a cop out, and it lets people write lazy/bad APIs rather
than coming up with good ones.

This is a very good point. In fact, I've never really thought
about it

that way and of course he's totally right that "SomeType | None" (or
Optional[SomeType], which also somehow made me feel that this
usage is

fairly intended) is not optimal, at least for user defined
types/classes. The problem is, that I never actually thought about
his
suggested way. And I wouldn't be surprised if this holds for many
other

people as well.

Maybe it would be great to boldly mention these thoughts in the
documentation at an appropriate place. In my opinion, there are at
least
the following good places where this would fit nicely:

- Linters like pylint could emit a note when seeing the "| None"
pattern, linking to the explanation about why it is possibly not the
best way to do it.

- The documentation of the discussed None-aware operators. Since
these

new operators are closely coupled to the arguably suboptimal "| None"
pattern, it is probably good to tell folks right there why they
should

consider better alternatives.

Best regards,
Philipp
___
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/Q2MOF5CJ7LSSZMEMB43YVEXD6PFATYTA/

Code of Conduct: http://python.org/psf/codeofconduct/

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

Code of Conduct: http://python.org/psf/codeofconduct/

___
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/2SLIUFU5YZJVBSVKYNKWE5ATESAZWYD6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Moving to Discourse

2022-09-20 Thread Petr Viktorin

As mentioned previously [0], the Steering Council decided to switch from
python-dev to Discourse (discuss.python.org).
We're aware that Discourse is not perfect. The previous mail thread [0]
lists various shortcomings, as well as some workarounds. However, we
don't see anything that would block Python development.

Practically, the switch means that:
- New PEPs should be announced in the PEPs category on Discourse (rather
than on this list), and
- The Devguide will list Discourse, rather than mailing lists, as the
primary communication channel.

Note that you can have development-related discussions anywhere, as long
as you (eventually) include all relevant people. You're welcome to
continue using python-dev and other mailing lists, IRC, in-person
sprints, etc. But for PEP-level changes, we believe python-dev no longer
reaches the proper audience.

For the related docs changes, see [peps-2775] and [devguide-945]. Note
that this is documentation, not law – if something is unclear or doesn't
make sense, please ask for clarification or propose edits.

[0]:
https://mail.python.org/archives/list/python-dev@python.org/thread/VHFLDK43DSSLHACT67X4QA3UZU73WYYJ/

[peps-2775]: https://github.com/python/peps/pull/2775
[devguide-945]: https://github.com/python/devguide/pull/945

— Petr, on behalf of the Steering Council
___
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/NS5C6EPMNEUH7X64SSBAUKUDCWYHZGUT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Moving to Discourse

2022-09-20 Thread Barry Warsaw

On Sep 20, 2022, at 02:47, Petr Viktorin  wrote:
> 
> Note that you can have development-related discussions anywhere, as long as 
> you (eventually) include all relevant people. You're welcome to continue 
> using python-dev and other mailing lists, IRC, in-person sprints, etc. But 
> for PEP-level changes, we believe python-dev no longer reaches the proper 
> audience.

Please also make sure your PEP’s Discussions-To header points to the right 
forum.

https://peps.python.org/pep-0001/#discussing-a-pep

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/SGB4AEGOMBER53BPFL2Y3GGU5626N4ON/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2022-09-20 Thread Piotr Waszkiewicz

Hi Philipp,
That's a really good idea, and I'd really want to see it being implemented.

Having said that, I wonder how many people would actually use this concept
of "none-representing" objects. In my 10+ years of programming experience
I've never seen anybody eager to use more complex structures or object
representations of such concepts outside of an academic environment (and
even there usually when dealing with personal or proof-of-concept projects).

Nowadays I write mostly more business-oriented code, and I haven't been
successful in finding a workplace where "business" wants to pay for
preparing "good looking" code - they want a functioning one. That's where
this whole concept of using none values is used the most (at least from my
experience).

So to reiterate: I think that the idea presented by Steve is very
appealing, and I'd really like to work with such projects, but the reality
is that it's really hard to stumble upon such. And I would really much *prefer
to have none-aware operators that would make my life easier working with
"real world" projects that rely too heavily on none values*, even if it's
academically not correct.


On Mon, Sep 19, 2022, 17:06 Philipp Burch  wrote:

> Hi all,
>
> I've only here found out that there is a discussion going on about those
> none-aware operators and my first thought was "great, finally!". FWIW,
> I'd be happy with the syntax suggestion in the PEP, since '?' looks
> rather intuitive to me to mean something like "maybe".
>
> However, I then read the mentioned post of Steve Dower, with the final
> summary:
>
>  > So to summarise my core concern - allowing an API designer to "just
> use None" is a cop out, and it lets people write lazy/bad APIs rather
> than coming up with good ones.
>
> This is a very good point. In fact, I've never really thought about it
> that way and of course he's totally right that "SomeType | None" (or
> Optional[SomeType], which also somehow made me feel that this usage is
> fairly intended) is not optimal, at least for user defined
> types/classes. The problem is, that I never actually thought about his
> suggested way. And I wouldn't be surprised if this holds for many other
> people as well.
>
> Maybe it would be great to boldly mention these thoughts in the
> documentation at an appropriate place. In my opinion, there are at least
> the following good places where this would fit nicely:
>
> - The documentation of the dataclasses
> (https://docs.python.org/3/library/dataclasses.html), since this is
> probably the most common use case for the "| None" pattern. Going
> further, the dataclasses functionality might even be extended to make it
> simpler to generate such null-types (or however they are called), so
> that it is no longer "a tonne more work".
>
> - Linters like pylint could emit a note when seeing the "| None"
> pattern, linking to the explanation about why it is possibly not the
> best way to do it.
>
> - The documentation of the discussed None-aware operators. Since these
> new operators are closely coupled to the arguably suboptimal "| None"
> pattern, it is probably good to tell folks right there why they should
> consider better alternatives.
>
> As mentioned, I absolutely see Steve's point. However, there are many
> Python scripts/programs working without a complex API, where this "|
> None" pattern may still have its legitimate uses and the none-aware
> operators can make code easier to read (and write).
>
> Best regards,
> Philipp
> ___
> 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/Q2MOF5CJ7LSSZMEMB43YVEXD6PFATYTA/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/YFY2LKA4YE7U7FRSTSWDUXYSN6XGOWQZ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

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

[Python-Dev] Moving to Discourse

[Python-Dev] Re: Moving to Discourse

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

5 matches

Site Navigation

Mail list logo

Footer information