FWIW, GitHub announced new powerful Issues today.
> https://github.com/features/issues
>
I have asked GitHub to enable it for the Python org.
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to
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
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-committers mailing list -- python-committers@python.org
To unsubscribe
On Jun 23, 2021, at 09:46, Marc-Andre Lemburg wrote:
>
> Since it's rather likely that we'll always find someone who still
> uses a module, I think we should find a better strategy on how to
> deal with such removals, e.g. create a separate attic repo where
> participation is easier than for
FWIW: PEP 594 doesn't seem to have been updated with all the
discussions we had around it, e.g. the nntplib is still marked
for removal, even though the only reason is related to servers
used in the test suite sometimes causing delays, which I will
be fixing with Ee by setting up our own test
On 23. 06. 21 15:21, Irit Katriel via python-committers wrote:
On Wed, Jun 23, 2021 at 1:58 PM Joannah Nanjekye
mailto:nanjekyejoan...@gmail.com>> wrote:
Am not against removing dead batteries but Am still very skeptical
and disturbed about how the
decision to remove modules is
On Wed, Jun 23, 2021 at 1:58 PM Joannah Nanjekye
wrote:
> Am not against removing dead batteries but Am still very skeptical and
> disturbed about how the
> decision to remove modules is made.i.e what goes and what remains?
>
> For example, in the discussion section of PEP 594 , individuals kept
Also, it seems this discussion should happen on python-dev so that more
people are aware of it.
Regards
Antoine.
Le 23/06/2021 à 14:58, Joannah Nanjekye a écrit :
Am not against removing dead batteries but Am still very skeptical and
disturbed about how the
decision to remove modules is
Am not against removing dead batteries but Am still very skeptical and
disturbed about how the
decision to remove modules is made.i.e what goes and what remains?
For example, in the discussion section of PEP 594 , individuals kept asking
for some modules to remain and IIUC,
it's in the decision
I've created https://bugs.python.org/issue44498, so we can continue the
discussion there.
Once we remove the libraries, we could create a list of all open issues,
put this list in another issue, link to it from what's new and then close
all issues (including the one with the list). This way the
Hi,
If someone sees a random issue on a CI, I suggest to open an issue at
bugs.python.org to track it. Otherwise, slowly, the number of random
failures becomes so high that it takes several "re-run all jobs"
steps, and so merging a basic typo fix takes 1 hour if not longer.
Victor
On Tue, Jun
Hi Irit,
Since it's documented as deprecated, asyncore and asynchat are
deprecated as well since Python 3.6 (smtpd uses asynchat), I suggest
to remove these 3 modules right now. I would prefer to make such
incompatible change early in the development cycle, to give more time
to users to adapt
Hi Andrew,
If someone ones smtpd, I would suggest to copy it from Python 3.10
(with asyncore and asynchat) and continue the maintenance outside the
CPython Git repository.
Create a project on PyPI if you expect contributions.
Victor
On Wed, Jun 23, 2021 at 9:13 AM Andrew McNamara
wrote:
>
>
>I would hope we'd remove it. It's a toy implementation, unmaintained,
>probably doesn't support a lot of newer protocol features, and is probably
>full of bugs. Hopefully nobody uses it!
I use it and it works well for my specific use case - a Postfix spam
filter. During incoming SMTP
14 matches
Mail list logo
