[Python-Dev] Re: Switching to Discourse

[Cameron Simpson]

On 15Jul2022 11:59, Ethan Furman  wrote:
>On 7/15/22 08:37, Petr Viktorin wrote:
>> And that's exactly why I consume Discourse in mailing list mode, with 
>> client-side
>> filtering in Thunderbird.
>
>How do you handle threading?  I follow each (sub)thread through to 
>it's end, as it keeps a logical flow, but Discourse has everything 
>linear which means that as I read it the conversation keeps jumping 
>around, making it hard to follow.

I use discourse in mailing list mode. It only looks unthreaded :-)

What actually happens is that it has its own message-ids and mangles 
things, and treats some headers differently. Eg if I post to discourse, 
the copy of the message which comes to me from discourse has a discourse 
generated message-id, not my original message-id.

I did a bit of digging here:
https://discuss.python.org/t/why-is-the-result-after-this-function-is-called-like-this/14680/15
but have not got to submitting a bug report.

Cheers,
Cameron Simpson 
___
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/ETQ2X5FDAJ6DHV5LGCB7WG4VR4JXP43U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Barry Warsaw]

To me, that’s the biggest negative of Discourse, and I definitely prefer 
threaded discussions.  Unfortunately though, much like top posting , I 
think that horse is out of the barn, what with other forums like GitHub being 
linear.

-Barry

On Jul 15, 2022, at 11:59, Ethan Furman  wrote:
> 
> How do you handle threading?  I follow each (sub)thread through to it's end, 
> as it keeps a logical flow, but Discourse has everything linear which means 
> that as I read it the conversation keeps jumping around, making it hard to 
> follow.



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

[Python-Dev] Re: Switching to Discourse

[Joannah Nanjekye]

I am -1 for leaving email due to the long history of standardization, for a
platform whose future I don't know about.

When you say core development is busier, does that mean the experiment with
python-dev failed? aka wasn't a success, if so why are we moving python-dev
too if it's not working well? I stand to be corrected obviously.

On Fri., Jul. 15, 2022, 2:22 p.m. Petr Viktorin,  wrote:

> Hello,
> Currently development discussions are split between multiple
> communication channels, for example:
> - python-dev and discuss.python.org for design discussions,
> - GitHub Issues and Pull Requests for specific changes,
> - IRC, Discord and private chats for real-time discussions,
> - Topic-specific channels like typing-sig.
>
> While most of these serve different needs, there is too much overlap
> between python-dev and discuss.python.org. It seems that for most
> people, this situation is worse than sticking to either one platform –
> even if we don't go with that person's favorite.
>
> The discuss.python.org experiment has been going on for quite a while,
> and while the platform is not without its issues, we consider it a
> success. The Core Development category is busier than python-dev.
> According to staff, discuss.python.org is much easier to moderate.. If
> you're following python-dev but not discuss.python.org, you're missing
> out.
>
> The Steering Council would like to switch from python-dev to
> discuss.python.org.
> Practically, this means:
> - Moving the required PEP announcements to discuss.python.org
> - Moving discuss.python.org up in the devguide communications page
> (https://devguide.python.org/communication/)
> - And that's it?
>
> I imagine that the mailing list will stay around for continuing past
> discussion threads and for announcements, eventually switching to
> auto-reject incoming messages with a pointer to discuss.python.org.
>
> To be clear, discuss.python.org allows editing posts, which is frankly
> handy for typos and clarifications. Editing alone should not be used for
> adding new info -- we should cultivate a culture of being friendly to
> mail users & notification watchers. This probably bears repeating in a
> few places.
>
> We're aware not everyone wants to use the discuss.python.org website,
> but there are some ways to avoid it:
>
> - For new PEPs, you can point your RSS client to
> https://www.python.org/dev/peps/peps.rss – it's not e-mail, but many
> email clients have RSS support. You can also watch the Steering Council
> issues on GitHub (https://github.com/python/steering-council/issues/)
> for important questions and discussions.
>
> - You can use discuss.python.org's “mailing list mode” (which subscribes
> you to all new posts), possibly with filtering and/or categorizing
> messages locally.
>
> However, we would like to know if this will pose an undue burden to
> anyone, if there are workflows or usage problems that we are not aware
> of. As mentioned, this is something the Steering Council thinks is a
> good idea, but we want to make sure we're aware of all the impact when
> we make the final decision.
>
>
>
> – 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/VHFLDK43DSSLHACT67X4QA3UZU73WYYJ/
> 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/XVZRX2ZNJUSERSJGLBAKAGYZNQC2P7X3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Ethan Furman]

On 7/15/22 08:37, Petr Viktorin wrote:

> And that's exactly why I consume Discourse in mailing list mode, with 
client-side
> filtering in Thunderbird.

How do you handle threading?  I follow each (sub)thread through to it's end, as it keeps a logical flow, but Discourse 
has everything linear which means that as I read it the conversation keeps jumping around, making it hard to follow.


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

[Python-Dev] Re: Switching to Discourse

[Erlend Egeberg Aasland]

I support the move to Discourse. For me, the combination of GitHub,
Discourse, and Discord work very well.

Looking forward to one less mailing list subscription in my life ;)


Erlend

On Fri, 15 Jul 2022 at 13:27, Petr Viktorin  wrote:

> Hello,
> Currently development discussions are split between multiple
> communication channels, for example:
> - python-dev and discuss.python.org for design discussions,
> - GitHub Issues and Pull Requests for specific changes,
> - IRC, Discord and private chats for real-time discussions,
> - Topic-specific channels like typing-sig.
>
> While most of these serve different needs, there is too much overlap
> between python-dev and discuss.python.org. It seems that for most
> people, this situation is worse than sticking to either one platform –
> even if we don't go with that person's favorite.
>
> The discuss.python.org experiment has been going on for quite a while,
> and while the platform is not without its issues, we consider it a
> success. The Core Development category is busier than python-dev.
> According to staff, discuss.python.org is much easier to moderate.. If
> you're following python-dev but not discuss.python.org, you're missing
> out.
>
> The Steering Council would like to switch from python-dev to
> discuss.python.org.
> Practically, this means:
> - Moving the required PEP announcements to discuss.python.org
> - Moving discuss.python.org up in the devguide communications page
> (https://devguide.python.org/communication/)
> - And that's it?
>
> I imagine that the mailing list will stay around for continuing past
> discussion threads and for announcements, eventually switching to
> auto-reject incoming messages with a pointer to discuss.python.org.
>
> To be clear, discuss.python.org allows editing posts, which is frankly
> handy for typos and clarifications. Editing alone should not be used for
> adding new info -- we should cultivate a culture of being friendly to
> mail users & notification watchers. This probably bears repeating in a
> few places.
>
> We're aware not everyone wants to use the discuss.python.org website,
> but there are some ways to avoid it:
>
> - For new PEPs, you can point your RSS client to
> https://www.python.org/dev/peps/peps.rss – it's not e-mail, but many
> email clients have RSS support. You can also watch the Steering Council
> issues on GitHub (https://github.com/python/steering-council/issues/)
> for important questions and discussions.
>
> - You can use discuss.python.org's “mailing list mode” (which subscribes
> you to all new posts), possibly with filtering and/or categorizing
> messages locally.
>
> However, we would like to know if this will pose an undue burden to
> anyone, if there are workflows or usage problems that we are not aware
> of. As mentioned, this is something the Steering Council thinks is a
> good idea, but we want to make sure we're aware of all the impact when
> we make the final decision.
>
>
>
> – 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/VHFLDK43DSSLHACT67X4QA3UZU73WYYJ/
> 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/IAUXSNYAVHI5AGOVOM4RY72GJKVXHKU2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: New `python` Organization Repository Policy

[Brett Cannon]

On Fri, Jul 15, 2022 at 4:54 AM Joannah Nanjekye 
wrote:

> I understand that the steering council decides new repositories that can
> be added to the Python organization but as a committer, it is good courtesy
> that public decisions are discussed first on committer channels because
> this impacts allow us to a degree I.e you are some how responsible for that
> code too.
>

I think that's fair. I opened
https://github.com/python/steering-council/issues/132 to discuss it.
Obviously if people have opinions on this, please share them here.

-Brett


> At least I get notifications for all repositories.
>
> On Fri., Jul. 15, 2022, 2:32 p.m. Petr Viktorin, 
> wrote:
>
>> (Cross-posted from
>>
>> https://discuss.python.org/t/new-python-organization-repository-policy/17376
>> – please perfer commenting there.)
>>
>> Hello,
>>
>> When asked about adding the typing_extensions repository to the Python
>> organization (https://github.com/python/steering-council/issues/126),
>> the Steering Council discussed a general policy for the organization, as
>> the current one
>> (https://devguide.python.org/devcycle/#organization-repository-policy)
>> seems outdated.
>>
>> We decided on the guidelines below.
>>
>> Note that existing repositories can stay under python. However, we will
>> ask that:
>> – PSF infrastructure be moved under the psf organization, and
>> – all repositories under python will need to require the CLA and have
>> two-factor authentication for all committers, otherwise move elsewhere
>> or be archived.
>>
>> – Petr, on behalf of the Steering Council
>>
>>
>>
>>
>> New Organization Repository Policy
>>
>> Within the GitHub Python organization, repositories are expected to
>> relate to the Python language, the CPython reference implementation,
>> their documentation and their development workflow. This includes, for
>> example:
>> - The reference implementation of Python and related repositories (i.e.
>> CPython)
>> - Tooling and support around CPython development (e.g. pyperformance,
>> Bedevere)
>> - Helpers and backports for Python/CPython features (e.g.
>> typing-extensions,  typeshed, tzdata, pythoncapi-compat)
>> - Organization-related repositories (e.g. the Code of Conduct, .github)
>> - Documentation and websites for all the above (e.g. python.org
>> repository, PEPs, Devguide, docs translations)
>> - Infrastructure for all the above (e.g. docsbuild-scripts,
>> buildmaster-config)
>> - Discussions and notes around official development-related processes
>> and events (e.g. steering-council, core-sprint)
>>
>> Before adding a new repository, permission should be sought from the
>> Python steering council. Note that several repositories remain in the
>> organization for historic reasons, and would probably not be appropriate
>> today.
>>
>> All non-archived repositories must require contributors to sign the PSF
>> Contributor Agreement.
>>
>> Generally, new repositories should start their life under personal
>> GitHub accounts or other GitHub orgs. It is relatively easy to move a
>> repository to the organization once it is mature. For example, this
>> would now apply to experimental features like asyncio, exceptiongroups
>> or typed_ast and drafts of new guides and other documentation (e.g.
>> redistributor-guide).
>>
>> General-use tools and libraries (e.g. mypy or black) should also be
>> developed outside the python organization, unless core devs (as
>> represented by the SC) specifically want to “bless” one implementation
>> (as with e.g. typeshed, tzdata, or pythoncapi-compat).
>> ___
>> 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/JP4T26I5HLO5SB3DKELDPQJPOR4JHLAN/
>> 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/FAASOMUNQZDJBCOTZK6I2KH55SDOONF6/
> 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/5ABWATH2YMMBTTGHZAWN6AK23V6UQOOG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Mariatta]

I think this is a great change, one I've been looking forward to myself.

For authors of PEPs and discussion topics, Discourse provides better
authoring experience, allowing for typo fixes and small edits.
For moderators, Discourse also provides the toolings to make their jobs
easier, which is definitely lacking in mailing list.
For the readers, we get the choice of receiving emails via mailing list
mode, or via rss, or by actually going to the site.

I think it's great that you've considered what's best for the different
types of users here.  So thank you Petr and SC for this decision.

On Fri, Jul 15, 2022 at 4:26 AM Petr Viktorin  wrote:

> Hello,
> Currently development discussions are split between multiple
> communication channels, for example:
> - python-dev and discuss.python.org for design discussions,
> - GitHub Issues and Pull Requests for specific changes,
> - IRC, Discord and private chats for real-time discussions,
> - Topic-specific channels like typing-sig.
>
> While most of these serve different needs, there is too much overlap
> between python-dev and discuss.python.org. It seems that for most
> people, this situation is worse than sticking to either one platform –
> even if we don't go with that person's favorite.
>
> The discuss.python.org experiment has been going on for quite a while,
> and while the platform is not without its issues, we consider it a
> success. The Core Development category is busier than python-dev.
> According to staff, discuss.python.org is much easier to moderate.. If
> you're following python-dev but not discuss.python.org, you're missing
> out.
>
> The Steering Council would like to switch from python-dev to
> discuss.python.org.
> Practically, this means:
> - Moving the required PEP announcements to discuss.python.org
> - Moving discuss.python.org up in the devguide communications page
> (https://devguide.python.org/communication/)
> - And that's it?
>
> I imagine that the mailing list will stay around for continuing past
> discussion threads and for announcements, eventually switching to
> auto-reject incoming messages with a pointer to discuss.python.org.
>
> To be clear, discuss.python.org allows editing posts, which is frankly
> handy for typos and clarifications. Editing alone should not be used for
> adding new info -- we should cultivate a culture of being friendly to
> mail users & notification watchers. This probably bears repeating in a
> few places.
>
> We're aware not everyone wants to use the discuss.python.org website,
> but there are some ways to avoid it:
>
> - For new PEPs, you can point your RSS client to
> https://www.python.org/dev/peps/peps.rss – it's not e-mail, but many
> email clients have RSS support. You can also watch the Steering Council
> issues on GitHub (https://github.com/python/steering-council/issues/)
> for important questions and discussions.
>
> - You can use discuss.python.org's “mailing list mode” (which subscribes
> you to all new posts), possibly with filtering and/or categorizing
> messages locally.
>
> However, we would like to know if this will pose an undue burden to
> anyone, if there are workflows or usage problems that we are not aware
> of. As mentioned, this is something the Steering Council thinks is a
> good idea, but we want to make sure we're aware of all the impact when
> we make the final decision.
>
>
>
> – 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/VHFLDK43DSSLHACT67X4QA3UZU73WYYJ/
> 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/RFH25FOFAVYN6WB7RYW3APCVCLAVDHK5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Barry Warsaw]

This might seem odd coming from me, but I’ve come around to supporting this 
move.  Discourse is not without its issues, but then again, the same can be 
said about email.  Without going into too much of my own personal preferences, 
I agree that the experiment has proven successful enough that there’s more 
value at this point in consolidating discussions.

Thank you for reaching out to see if there are any usability or workflow issues 
that might impact this decision.  There aren’t too much for me, but I wonder if 
there are accessibility or native language concerns that might unduly affect 
other users.

One thing I didn’t see mentioned is the question of identity.  There’s one side 
which is how folks self identify themselves on the mailing list or forum.  We 
don’t have any prohibitions against alias or nicknames, which IMHO is totally 
fine.  The flip side is more important, ensuring that folks identities can’t be 
spoofed or hijacked.  In email at least, I can digitally sign my messages (such 
as this one), and while it’s probably true that fewer and fewer folks use any 
kind of email digital signature verification, at least *I* can prove whether or 
not I wrote something.  What similar kinds of protections do we have on 
Discourse?

-Barry

> On Jul 15, 2022, at 04:18, Petr Viktorin  wrote:
> 
> The discuss.python.org experiment has been going on for quite a while, and 
> while the platform is not without its issues, we consider it a success. The 
> Core Development category is busier than python-dev. According to staff, 
> discuss.python.org is much easier to moderate.. If you're following 
> python-dev but not discuss.python.org, you're missing out.
> 
> The Steering Council would like to switch from python-dev to 
> discuss.python.org.
> Practically, this means:
> - Moving the required PEP announcements to discuss.python.org
> - Moving discuss.python.org up in the devguide communications page 
> (https://devguide.python.org/communication/)
> - And that's it?



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

[Python-Dev] Re: [RELEASE] The cursed fourth Python 3.11 beta (3.11.0b4) is available

[Samuel Colvin]

Since a few people have reacted to my PS comment:

I suffered (committed) a very confusing typo; the github bot refers to
"07/13/2022" (e.g. MM/DD/) which drew my ire, I then confusingly
referenced a different format in my comment.

Overall, I agree we should be using ISO8601 for exactly this reason (at
least for dates, for datetimes ISO8601 gets pretty wacky
)

Samuel

--

Samuel Colvin
07801160713


On Fri, 15 Jul 2022 at 05:39, Stephen J. Turnbull <
stephenjturnb...@gmail.com> wrote:

> Alan G. Isaac writes:
>
>  > 4. It implements ISO 8601 (which exists for a reason):
>  > https://en.wikipedia.org/wiki/ISO_8601#Calendar_dates
>
> Yes!!!  "Standardization is my Valentine!" :-D
>
> --
> RIP WotR Bombshell
> ___
> 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/O7EKVHRG3GGAHYGQEPCUMPPYU5S67FGO/
> 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/PQ2DVETX6TWQF4SVWLPGPU5VUL26MU5N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Presenting PEP 695: Type Parameter Syntax

[Patrick Reader]

On 13/07/2022 14:14, o.jacob.nils...@gmail.com wrote:

Hi, I like this PEP but I couldn't find the motivation for using angle brackets 
over square braces (brackets?). The survey in Appendix A is great but lacks any 
conclusions. From that survey alone I would assume that angle brackets would 
have been chosen over square braces, given that they are the most common option 
and appear in (afaik) the more popular languages in that list. I think the PEP 
should add a section about the choice of syntax in the rejected section, which 
can be expanded upon in Appendix A.

If you can't tell I'm in favor of angle brackets, I think the examples given in 
the PEP look a bit messy with so many parentheses and square braces in close 
proximity. Using angle brackets would make the distinction between typevars and 
function parameters clearer.


Another reason that square brackets should be preferred over angle 
brackets is the difficulty in parsing:


list>

is tokenised as list < list < int >> where the last token is a right 
shift operator, so the parser has to know that sometimes >> is used when 
two "angle bracket" groups are closed, instead of > >


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

[Python-Dev] Re: [RELEASE] The cursed fourth Python 3.11 beta (3.11.0b4) is available

[h . vetinari]

Agreed on all 4 counts! :)
___
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/ERRID6WTR2RMXIUT4MN2JRAGOW6IDAHT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [SPAM] Re: Switching to Discourse

[Petr Viktorin]

On 15. 07. 22 17:34, Phil Thompson via Python-Dev wrote:

On 15/07/2022 16:09, Rob Boehne via Python-Dev wrote:

100% agree – dealing with 5 or more platforms for discussion groups is
a nightmare, and I tend not to follow any of them as closely for that
reason.


I agree. I don't mind having to use Discourse if I want to take part in 
a discussion but 99% of the time I just want to keep up to date with 
what is going on. In that case I want the information to come to me - I 
don't want to have to hunt for it. Can there be an RSS feed for 
everything, not just PEPs?


For everything on Discourse, the RSS feed is at 
https://discuss.python.org/latest.rss

For a specific categoriy/topic, append .rss to the Web URL.
___
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/IZ62SRTO6QBNQUWE2CEGWRA66DRXEAHM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Petr Viktorin]

On 15. 07. 22 16:24, Skip Montanaro wrote:

The discuss.python.org  experiment has
been going on for quite a while,
and while the platform is not without its issues, we consider it a
success. The Core Development category is busier than python-dev.
According to staff, discuss.python.org 
is much easier to moderate.. If
you're following python-dev but not discuss.python.org
, you're missing out.

Personally, I think you are focused too narrowly and aren't seeing the 
forest for the trees. Email protocols were long ago standardized. As a 
result, people can use any of a large number of applications to read and 
organize their email. To my knowledge, there is no standardization 
amongst the various forum tools out there. I'm not suggesting discuss is 
necessarily better or worse than other (often not open source) forum 
tools, but each one implements its own walled garden. I'm referring more 
broadly than just Python, or even Python development, though even within 
the Python community it's now difficult to manage/monitor all the 
various discussion sources (email, discuss, GitHub, Stack Overflow, ...)


Get off my lawn! ;-)

Skip, kinda glad he's retired now...



And that's exactly why I consume Discourse in mailing list mode, with 
client-side filtering in Thunderbird.
I do go to the site to post though. Tthat's possible by e-mail, but the 
lack of standardization in reply/quoting styles and  makes it hard for 
Discourse to format e-mail replies nicely. (Traditional clients aren't 
perfect at that either, TBH.)



– Petr (not on behalf of any group)


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

[Python-Dev] Re: [SPAM] Re: Switching to Discourse

[Phil Thompson via Python-Dev]

On 15/07/2022 16:09, Rob Boehne via Python-Dev wrote:

100% agree – dealing with 5 or more platforms for discussion groups is
a nightmare, and I tend not to follow any of them as closely for that
reason.


I agree. I don't mind having to use Discourse if I want to take part in 
a discussion but 99% of the time I just want to keep up to date with 
what is going on. In that case I want the information to come to me - I 
don't want to have to hunt for it. Can there be an RSS feed for 
everything, not just PEPs?


Phil


From: Skip Montanaro 
Date: Friday, July 15, 2022 at 9:26 AM
To: Petr Viktorin 
Cc: python-dev@python.org 
Subject: [SPAM] [Python-Dev] Re: Switching to Discourse
The
discuss.python.org
experiment has been going on for quite a while,
and while the platform is not without its issues, we consider it a
success. The Core Development category is busier than python-dev.
According to staff,
discuss.python.org
is much easier to moderate.. If
you're following python-dev but not
discuss.python.org,
you're missing out.

Personally, I think you are focused too narrowly and aren't seeing the
forest for the trees. Email protocols were long ago standardized. As a
result, people can use any of a large number of applications to read
and organize their email. To my knowledge, there is no standardization
amongst the various forum tools out there. I'm not suggesting discuss
is necessarily better or worse than other (often not open source)
forum tools, but each one implements its own walled garden. I'm
referring more broadly than just Python, or even Python development,
though even within the Python community it's now difficult to
manage/monitor all the various discussion sources (email, discuss,
GitHub, Stack Overflow, ...)

Get off my lawn! ;-)

Skip, kinda glad he's retired now...


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

[Python-Dev] Re: Switching to Discourse

[Peter Wang via Python-Dev]

On Fri, Jul 15, 2022 at 9:33 AM Skip Montanaro 
wrote:

> Email protocols were long ago standardized. As a result, people can use
> any of a large number of applications to read and organize their email. To
> my knowledge, there is no standardization amongst the various forum tools
> out there.
>

While I understand and somewhat agree with you, Skip, there is a "hidden"
feature of Discourse that does make it a little easier to track many
different forums:  You can add ".rss" to various URLs and get an RSS feed
for that topic/channel/etc.

e.g. the WebAssembly group is: https://discuss.python.org/c/webassembly/28
And its corresponding RSS feed is:
https://discuss.python.org/c/webassembly/28.rss

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

[Python-Dev] Re: [SPAM] Re: Switching to Discourse

[Rob Boehne via Python-Dev]

100% agree – dealing with 5 or more platforms for discussion groups is a 
nightmare, and I tend not to follow any of them as closely for that reason.

From: Skip Montanaro 
Date: Friday, July 15, 2022 at 9:26 AM
To: Petr Viktorin 
Cc: python-dev@python.org 
Subject: [SPAM] [Python-Dev] Re: Switching to Discourse
The 
discuss.python.org
 experiment has been going on for quite a while,
and while the platform is not without its issues, we consider it a
success. The Core Development category is busier than python-dev.
According to staff, 
discuss.python.org
 is much easier to moderate.. If
you're following python-dev but not 
discuss.python.org,
 you're missing out.

Personally, I think you are focused too narrowly and aren't seeing the forest 
for the trees. Email protocols were long ago standardized. As a result, people 
can use any of a large number of applications to read and organize their email. 
To my knowledge, there is no standardization amongst the various forum tools 
out there. I'm not suggesting discuss is necessarily better or worse than other 
(often not open source) forum tools, but each one implements its own walled 
garden. I'm referring more broadly than just Python, or even Python 
development, though even within the Python community it's now difficult to 
manage/monitor all the various discussion sources (email, discuss, GitHub, 
Stack Overflow, ...)

Get off my lawn! ;-)

Skip, kinda glad he's retired now...

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

[Python-Dev] Re: Switching to Discourse

[Skip Montanaro]

>
> The discuss.python.org experiment has been going on for quite a while,
> and while the platform is not without its issues, we consider it a
> success. The Core Development category is busier than python-dev.
> According to staff, discuss.python.org is much easier to moderate.. If
> you're following python-dev but not discuss.python.org, you're missing
> out.
>

Personally, I think you are focused too narrowly and aren't seeing the
forest for the trees. Email protocols were long ago standardized. As a
result, people can use any of a large number of applications to read and
organize their email. To my knowledge, there is no standardization amongst
the various forum tools out there. I'm not suggesting discuss is
necessarily better or worse than other (often not open source) forum tools,
but each one implements its own walled garden. I'm referring more broadly
than just Python, or even Python development, though even within the Python
community it's now difficult to manage/monitor all the various discussion
sources (email, discuss, GitHub, Stack Overflow, ...)

Get off my lawn! ;-)

Skip, kinda glad he's retired now...
___
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/2V5T44LUN73ONCBI7F5GKGDDXNOVIDZN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Presenting PEP 695: Type Parameter Syntax

[Paul Ganssle]

I actually really like some variation on `@with type S`, or some other 
variation that has a keyword, because that makes it much easier for 
someone newly encountering one of these syntax constructs to search to 
figure out what it does. If you didn't already know what the square 
brackets did, how would you try and find out? "what do square brackets 
mean in Python" would probably turn up a bunch of stuff about element 
access, and maybe something about type generic parameters.


By contrast, `@with type S` is kinda self-explanatory, and even if it's 
not, 'What does "with type" mean in Python' will almost certainly turn 
up meaningful results.


An additional benefit is that I find some of these examples to be a bit 
visually cluttered with all the syntax:


def  func1[T](a:  T)  ->  T:  ...   # OK
class ClassA[S, T](Protocol): ... # OK

Which would look less cluttered with a prefix clause:

@with type T def  func1(a:  T)  ->  T:  ...   # OK
@with type S @with type T class ClassA(Protocol): ... # OK

Of the objections to this concept in the PEP 
, the most obvious one 
to me was that the scoping rules were less clear, but it is not entirely 
clear to me why the scope of the prefix clause couldn't be extended to 
include class / function decorators that follow the prefix clause; the 
choice of scoping seems like it was a defensible but mostly arbitrary 
one. I think as long as the new prefix clause is something that was 
syntactically forbidden prior to the introduction of PEP 695 (e.g. 
`@with type` or `[typevar: S]` or whatever), it will be relatively clear 
that this is not a normal decorator, and so "the scoping and time of 
execution doesn't match decorators" doesn't seem like a major concern to 
me relative to the benefits of using a more searchable syntax.


On 7/12/22 18:09, Jelle Zijlstra wrote:


The Rejected ideas mention “various syntactic options for specifying
type parameters that preceded def and class statements” rejected
because
scoping is less clear and doesn't work well with decorators. I
wonder if
decorator-like syntax itself was considered, e.g. something like:
```
@with type S
@with type T
@dec(Foo[S])
class ClassA: ...
```

We did consider variations of that. Pure decorator syntax (like your 
"@dec" line) wouldn't allow us to get the scoping right, since 
decorators can't define new names. (Unless you use a walrus operator, 
but that wouldn't meet the goal of providing cleaner syntax.)


We also considered some ideas similar to your "@with type". It can 
work, but it feels more verbose than the current proposal, and it's 
not in line with what most other languages do.___
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/OB7TJYLEFYV6MGF5VB3FYVLH3QEIRKNT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: New `python` Organization Repository Policy

[Joannah Nanjekye]

I understand that the steering council decides new repositories that can be
added to the Python organization but as a committer, it is good courtesy
that public decisions are discussed first on committer channels because
this impacts allow us to a degree I.e you are some how responsible for that
code too. Atleast I get notifications for all repositories.

On Fri., Jul. 15, 2022, 2:32 p.m. Petr Viktorin,  wrote:

> (Cross-posted from
>
> https://discuss.python.org/t/new-python-organization-repository-policy/17376
> – please perfer commenting there.)
>
> Hello,
>
> When asked about adding the typing_extensions repository to the Python
> organization (https://github.com/python/steering-council/issues/126),
> the Steering Council discussed a general policy for the organization, as
> the current one
> (https://devguide.python.org/devcycle/#organization-repository-policy)
> seems outdated.
>
> We decided on the guidelines below.
>
> Note that existing repositories can stay under python. However, we will
> ask that:
> – PSF infrastructure be moved under the psf organization, and
> – all repositories under python will need to require the CLA and have
> two-factor authentication for all committers, otherwise move elsewhere
> or be archived.
>
> – Petr, on behalf of the Steering Council
>
>
>
>
> New Organization Repository Policy
>
> Within the GitHub Python organization, repositories are expected to
> relate to the Python language, the CPython reference implementation,
> their documentation and their development workflow. This includes, for
> example:
> - The reference implementation of Python and related repositories (i.e.
> CPython)
> - Tooling and support around CPython development (e.g. pyperformance,
> Bedevere)
> - Helpers and backports for Python/CPython features (e.g.
> typing-extensions,  typeshed, tzdata, pythoncapi-compat)
> - Organization-related repositories (e.g. the Code of Conduct, .github)
> - Documentation and websites for all the above (e.g. python.org
> repository, PEPs, Devguide, docs translations)
> - Infrastructure for all the above (e.g. docsbuild-scripts,
> buildmaster-config)
> - Discussions and notes around official development-related processes
> and events (e.g. steering-council, core-sprint)
>
> Before adding a new repository, permission should be sought from the
> Python steering council. Note that several repositories remain in the
> organization for historic reasons, and would probably not be appropriate
> today.
>
> All non-archived repositories must require contributors to sign the PSF
> Contributor Agreement.
>
> Generally, new repositories should start their life under personal
> GitHub accounts or other GitHub orgs. It is relatively easy to move a
> repository to the organization once it is mature. For example, this
> would now apply to experimental features like asyncio, exceptiongroups
> or typed_ast and drafts of new guides and other documentation (e.g.
> redistributor-guide).
>
> General-use tools and libraries (e.g. mypy or black) should also be
> developed outside the python organization, unless core devs (as
> represented by the SC) specifically want to “bless” one implementation
> (as with e.g. typeshed, tzdata, or pythoncapi-compat).
> ___
> 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/JP4T26I5HLO5SB3DKELDPQJPOR4JHLAN/
> 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/FAASOMUNQZDJBCOTZK6I2KH55SDOONF6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] New `python` Organization Repository Policy

[Petr Viktorin]

(Cross-posted from 
https://discuss.python.org/t/new-python-organization-repository-policy/17376 
– please perfer commenting there.)


Hello,

When asked about adding the typing_extensions repository to the Python 
organization (https://github.com/python/steering-council/issues/126), 
the Steering Council discussed a general policy for the organization, as 
the current one 
(https://devguide.python.org/devcycle/#organization-repository-policy) 
seems outdated.


We decided on the guidelines below.

Note that existing repositories can stay under python. However, we will 
ask that:

– PSF infrastructure be moved under the psf organization, and
– all repositories under python will need to require the CLA and have 
two-factor authentication for all committers, otherwise move elsewhere 
or be archived.


– Petr, on behalf of the Steering Council




New Organization Repository Policy

Within the GitHub Python organization, repositories are expected to 
relate to the Python language, the CPython reference implementation, 
their documentation and their development workflow. This includes, for 
example:
- The reference implementation of Python and related repositories (i.e. 
CPython)
- Tooling and support around CPython development (e.g. pyperformance, 
Bedevere)
- Helpers and backports for Python/CPython features (e.g. 
typing-extensions,  typeshed, tzdata, pythoncapi-compat)

- Organization-related repositories (e.g. the Code of Conduct, .github)
- Documentation and websites for all the above (e.g. python.org 
repository, PEPs, Devguide, docs translations)
- Infrastructure for all the above (e.g. docsbuild-scripts, 
buildmaster-config)
- Discussions and notes around official development-related processes 
and events (e.g. steering-council, core-sprint)


Before adding a new repository, permission should be sought from the 
Python steering council. Note that several repositories remain in the 
organization for historic reasons, and would probably not be appropriate 
today.


All non-archived repositories must require contributors to sign the PSF 
Contributor Agreement.


Generally, new repositories should start their life under personal 
GitHub accounts or other GitHub orgs. It is relatively easy to move a 
repository to the organization once it is mature. For example, this 
would now apply to experimental features like asyncio, exceptiongroups 
or typed_ast and drafts of new guides and other documentation (e.g. 
redistributor-guide).


General-use tools and libraries (e.g. mypy or black) should also be 
developed outside the python organization, unless core devs (as 
represented by the SC) specifically want to “bless” one implementation 
(as with e.g. typeshed, tzdata, or pythoncapi-compat).

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

[Python-Dev] Switching to Discourse

[Petr Viktorin]

Hello,
Currently development discussions are split between multiple 
communication channels, for example:

- python-dev and discuss.python.org for design discussions,
- GitHub Issues and Pull Requests for specific changes,
- IRC, Discord and private chats for real-time discussions,
- Topic-specific channels like typing-sig.

While most of these serve different needs, there is too much overlap 
between python-dev and discuss.python.org. It seems that for most 
people, this situation is worse than sticking to either one platform – 
even if we don't go with that person's favorite.


The discuss.python.org experiment has been going on for quite a while, 
and while the platform is not without its issues, we consider it a 
success. The Core Development category is busier than python-dev. 
According to staff, discuss.python.org is much easier to moderate.. If 
you're following python-dev but not discuss.python.org, you're missing out.


The Steering Council would like to switch from python-dev to 
discuss.python.org.

Practically, this means:
- Moving the required PEP announcements to discuss.python.org
- Moving discuss.python.org up in the devguide communications page 
(https://devguide.python.org/communication/)

- And that's it?

I imagine that the mailing list will stay around for continuing past 
discussion threads and for announcements, eventually switching to 
auto-reject incoming messages with a pointer to discuss.python.org.


To be clear, discuss.python.org allows editing posts, which is frankly 
handy for typos and clarifications. Editing alone should not be used for 
adding new info -- we should cultivate a culture of being friendly to 
mail users & notification watchers. This probably bears repeating in a 
few places.


We're aware not everyone wants to use the discuss.python.org website, 
but there are some ways to avoid it:


- For new PEPs, you can point your RSS client to 
https://www.python.org/dev/peps/peps.rss – it's not e-mail, but many 
email clients have RSS support. You can also watch the Steering Council 
issues on GitHub (https://github.com/python/steering-council/issues/) 
for important questions and discussions.


- You can use discuss.python.org's “mailing list mode” (which subscribes 
you to all new posts), possibly with filtering and/or categorizing 
messages locally.


However, we would like to know if this will pose an undue burden to 
anyone, if there are workflows or usage problems that we are not aware 
of. As mentioned, this is something the Steering Council thinks is a 
good idea, but we want to make sure we're aware of all the impact when 
we make the final decision.




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