On Wed, 23 Jun 2021 at 01:21, Brett Cannon wrote:
> Regardless, there are no plans to halt what was decided when we accepted PEP
> 581. Most of the concerns which have been brought up in this thread were
> already expressed back then (the account merge one I didn't remember, hence
> why I repli
On Tue, 22 Jun 2021 19:49:12 -0400
Ned Deily wrote:
>
> I think this points out a problem with our current bug system and one that it
> would be good to try to resolve in migrating to a new system: that is, the
> ambiguity of the "version" metadata in an issue. Today, that list of versions
> i
On Jun 22, 2021, at 15:52, Brett Cannon wrote:
>
> One thing I will remind people is I personally have led the work to move this
> project from:
> • SourceForge to our own infrastructure
> • Mercurial to git
> • Our own infrastructure to GitHub for code management
> So if GitHu
On Jun 23, 2021, at 03:21, Paul Moore wrote:
> PEP 588 has not been accepted, so it's not necessarily relevant to the
> actual migration plan here, but I do think it's reasonable to ask for
> some clarification. Either PEP 588 should be rejectected, noting that
> the actual implementation plan is
My understanding is that Ezio is/will be working on updating PEP 588.
Last I heard from Ezio is that he would be co-author of PEP 588 and he
would be updating it/rewrite it to better match the current migration plan.
I will check with Ezio and the gh-migration group on the status.
Thanks.
On Wed
FWIW, GitHub announced new powerful Issues today.
https://github.com/features/issues
It may fill some gap between GitHub Issues and Roundup.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to
The asynchat [1] and asyncore [2] libraries have been deprecated since 3.6
in favor of asyncio [3]. In addition, smtpd [4], which depends on asynchat
and asyncore, is deprecated in favor of aiosmtpd [5].
The documentation for each of these libraries mentions that it is
deprecated and refers to t
On 23. 06. 21 23:49, Irit Katriel via Python-Dev wrote:
Barry and I are working on a patch to add deprecation warnings in 3.10 when one
of these are imported [6]. Let us know if you have any comments on this plan.
With my Fedora Python maintainer hat on, I am not particularly happy about this
On Wed, Jun 23, 2021 at 10:49:04PM +0100, Irit Katriel via Python-Dev wrote:
> The next step is to add deprecation warnings, so that we can eventually delete
> them. There is also the issue that some of the stdlib tests are still using
> these libraries, but this does not need to block removing th
Miro, what tests (outside of Python itself) do you think may break, and do you
have a way to check that?
-Barry
On Wed, Jun 23, 2021, at 17:15, Miro Hrončok wrote:
> On 23. 06. 21 23:49, Irit Katriel via Python-Dev wrote:
> >
> > Barry and I are working on a patch to add deprecation warnings in
On 24. 06. 21 0:35, Barry Warsaw wrote:
Miro, what tests (outside of Python itself) do you think may break, and do you
have a way to check that?
Any tests that import from asynchat, asyncore or smtpd (in the tests or in the
tested code, even transitively trough other projects) if DeprecationWa
On 6/23/2021 4:28 PM, Inada Naoki wrote:
FWIW, GitHub announced new powerful Issues today.
https://github.com/features/issues
It may fill some gap between GitHub Issues and Roundup.
I signed up for the beta waiting list so I could experiment with it.
Someone else would have to sign up 'Python
FWIW, GitHub announced new powerful Issues today.
> https://github.com/features/issues
>
I have asked GitHub to enable it for the Python org.
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to python-dev-le...@pytho
TL;DR I am considering changing IntEnum and IntFlag's `__str__` to be
`int.__str__`
IntEnum and IntFlag are becoming more common in the stdlib. They currently
show up in
* http
* re
* signal
* ssl
* socket
to name just a few.
3.10 already has some changes to the str() and repr() of enums i
El mié, 23 jun 2021 a las 19:54, Ethan Furman ()
escribió:
> TL;DR I am considering changing IntEnum and IntFlag's `__str__` to be
> `int.__str__`
>
> IntEnum and IntFlag are becoming more common in the stdlib. They
> currently show up in
>
> * http
> * re
> * signal
> * ssl
> * socket
>
> to na
Oh, it's definitely too late for 3.10.
On Wed, Jun 23, 2021 at 8:16 PM Jelle Zijlstra
wrote:
>
>
> El mié, 23 jun 2021 a las 19:54, Ethan Furman ()
> escribió:
>
>> TL;DR I am considering changing IntEnum and IntFlag's `__str__` to be
>> `int.__str__`
>>
>> IntEnum and IntFlag are becoming more
16 matches
Mail list logo
