[Python-Dev] Re: Moving to Discourse
Hello, good to see that someone in the Steering Council still reads here, as some of the actions necessary to make either mailing-list mode or RSS a viable alternative [1] need an official "hat": * mailing-list mode: there needs to be a *standardized* set of filters to access Core-Dev + PEPs (and only that). That's the only way to make sure all people using mailing-list mode get the same set of posts. Giving this set of filters an official status would allow external mirroring and archiving (relying solely on discourse.org for archiving is imprudent). * RSS: the shortcomings I described in my august post [2] are still there. At the very least, the PSF needs to make sure that the age / length limits of the RSS files (both core-dev.rss and posts.rss) are *much* increased. Cheers, Baptiste [1] hopefully "we don't see anything that would block Python development" doesn't mean alternatives to the (slow and annoying) web interface are abandoned. [2] https://mail.python.org/archives/list/[email protected]/message/UZJ27G57F7QJJ2LYBDGZQ5BIXLH7OXWJ/ Viktorin a écrit : > 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/[email protected]/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 -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/NS5C6EPMNEUH7X64SSBAUKUDCWYHZGUT/ > > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/6GQDLGC7NYBLIQWAX2GJ5L32TPIUVCOV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Moving to Discourse
On 21. 09. 22 10:17, Baptiste Carvello wrote: Hello, good to see that someone in the Steering Council still reads here, as some of the actions necessary to make either mailing-list mode or RSS a viable alternative [1] need an official "hat": * mailing-list mode: there needs to be a *standardized* set of filters to access Core-Dev + PEPs (and only that). That's the only way to make sure all people using mailing-list mode get the same set of posts. Giving this set of filters an official status would allow external mirroring and archiving (relying solely on discourse.org for archiving is imprudent). Do you have a proposal we could standardize? Open a PR on the devguide. You shouldn't need an official hat-wearer around, unless there's a disagreement. But I don't think the goal is to make sure all people using the mailing list get the same set of posts. Different people have different interests. Only mirroring/archiving Core-Dev + PEPs also seems pretty arbitrary. * RSS: the shortcomings I described in my august post [2] are still there. At the very least, the PSF needs to make sure that the age / length limits of the RSS files (both core-dev.rss and posts.rss) are *much* increased. I'm not sure what the PSF can do here -- this sounds like it should be a feature request to Discourse. I guess the mailing list mode is a better option if you don't want to miss anything. Is it lacking something that RSS provides, besides easier filtering? Cheers, Baptiste [1] hopefully "we don't see anything that would block Python development" doesn't mean alternatives to the (slow and annoying) web interface are abandoned. [2] https://mail.python.org/archives/list/[email protected]/message/UZJ27G57F7QJJ2LYBDGZQ5BIXLH7OXWJ/ Viktorin a écrit : 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/[email protected]/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 -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/CNKIIZM2GWF3YKI5RXMMCZXAPDDHZHD5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
On Sun, Sep 18, 2022 at 09:43:26PM +0200, Philipp Burch wrote: > 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. I don't think that `SomeType|None` is necessarily a lazy or bad API. Whether it is "optimal" or not will depend on the specific SomeType involved, not to mention other tradeoffs and constraints such as time and money available. (Oh, to have the luxury of spending two months to "Do It Right" for a project needed in a week on a budget...) But what's not "optimal" is expecting everyone who writes a class and needs to represent the lack of an instance to duplicate those None-like semantics within the class. The distinction you make between user-defined and non-user-defined classes doesn't hold water. If you allow that (say) `int|None` **might** be acceptable, then why would `Integer|None` **necessarily** be lazy and bad just because int is written in C and built into the intepreter while Integer is written in Python by a user? The laziness/badness of `SomeType|None` must depend on the semantics of SomeType, not the implementation language or who wrote it. "Our API was lazy and bad because it uses None, but then it got accepted into Python as a builtin, so now it is no longer lazy or bad." /s Of course people can write None-like instances of their SomeType classes, if it makes sense for their application. But the idea that any and every use (or even a majority) of Optional types is a "lazy/bad API" is, I think, unrealistic puritism, not to mention unfairly disparaging towards the programmers who write those APIs. > The problem is, that I never actually thought about his suggested way. Some people have, and found that it doesn't always simplify the API that much, or at all. If you end up replacing `obj is None` with `obj == NULL` or `obj.isnull()` then you haven't really gained much. -- Steven ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/C4GJX5O7FX2WBZMJ6DU5PVI5LUV5NCT5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
Hi Steven! On 21.09.22 13:17, Steven D'Aprano wrote: The distinction you make between user-defined and non-user-defined classes doesn't hold water. If you allow that (say) `int|None` **might** be acceptable, then why would `Integer|None` **necessarily** be lazy and bad just because int is written in C and built into the intepreter while Integer is written in Python by a user? The laziness/badness of `SomeType|None` must depend on the semantics of SomeType, not the implementation language or who wrote it. "Our API was lazy and bad because it uses None, but then it got accepted into Python as a builtin, so now it is no longer lazy or bad." /s I considered a while if "user-defined types/classes" is the right wording, but didn't find a better alternative. The point I'm making is that `X|None` could especially then hide bugs if X defines attributes that will often be accessed in a chain. For int or float, there are only a few methods, which are arguably rarely used and chaining is probably not used at all. Plus, providing nulltypes for primitives would feel very awkward. Consider ``` x: int | None = 5 # ... if x is not None: y = 1 << x.bit_cont() ``` The typo with bit_cont() is hidden whenever x is None, so it might be missed by unit tests with limited coverage. However, using a nullable variant of it would probably make it look like this: ``` class Int(int): # ... class NoneInt(Int): # ... x = Int(5) # With the option for NoneInt() # ... x_bit_count = x.bit_cont() if x_bit_count == NoneInt: y = 1 << x_bit_count ``` This is certainly not pretty for something basic as an int, plus there will most likely be a performance hit when replacing every int by Int(), not to mention compatibility issues with APIs/libraries expecting plain int. On the other hand, more complex classes like in the mentioned publisher API could indeed profit from such null-types, since a chain like ``` book?.publisher?.owner?.namme ``` will hide the typo with namme whenever any of book, publisher or owner is None, so there is much more potential here to miss it in a unit test. This is actually the distinction that I wanted to make, not in the technical sense if a class is defined in the standard library or not. The problem is, that I never actually thought about his suggested way. Some people have, and found that it doesn't always simplify the API that much, or at all. If you end up replacing `obj is None` with `obj == NULL` or `obj.isnull()` then you haven't really gained much. Certainly. But without None-aware operators, the gain in readability can be large, if you can just write ``` name = book.publisher.owner.name if name is not None: # No NoneStr here, see above # ... ``` versus ``` if (book is not None) and (book.publisher is not None) and ...: # ... ``` Just to be clear: I've been thankful for the comment and explanation of Steve Dower, because I've never thought about it that way and now see constructs in my code, where such a concept really would have simplified things and improved robustness. For others to profit as well, I would be glad to see this mentioned in the docs, so that it can be found even when not actually looking for it. But I certainly don't want to say that this concept must be followed everywhere or that "X|None" is necessarily a bad thing. After all, I'd still love to see Python supporting such None-aware operators. Best regards, Philipp ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/ZZ7VO54KYRJY3SATL6XBZZ4AHE54PG6B/ Code of Conduct: http://python.org/psf/codeofconduct/
