On 9/4/2020 6:00 PM, Stefan Krah wrote:
> It is not hyperbolic at all. You can get permissions for a certain set
> of modules (the stdlib), but not for PyPI packages.
>
> Of course the upgrade is not via the network, that is beside the point.
Besides upgrades of existing systems, there are also new
It is not hyperbolic at all. You can get permissions for a certain set
of modules (the stdlib), but not for PyPI packages.
Of course the upgrade is not via the network, that is beside the point.
On Fri, Sep 04, 2020 at 02:56:07PM -0700, Emily Bowman wrote:
> On Fri, Sep 4, 2020 at 10:31 AM St
On Fri, Sep 4, 2020 at 10:31 AM Stefan Krah wrote:
>
> All the time, especially when I'm writing them. I imagine that there's
> a huge amount of internal company code that discourages use of pip
> installed packages as well. Or has an air-gapped network in the first
> place.
>
That's wildly hyp
ACTIVITY SUMMARY (2020-08-28 - 2020-09-04)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7692 (+20)
closed 45764 (+44)
total 53456 (+64)
Open issues w
On Fri, Sep 04, 2020 at 01:10:37PM -0400, Paul Ganssle wrote:
> On 9/4/20 12:45 PM, Stefan Krah wrote:
> > Since distutils does not change, why remove it? It is a lot of work
> > for people with little gain.
>
> If we don't remove it, we should at least freeze the bug component so
> that people c
On 9/4/20 12:45 PM, Stefan Krah wrote:
> Since distutils does not change, why remove it? It is a lot of work
> for people with little gain.
If we don't remove it, we should at least freeze the bug component so
that people cannot report bugs in distutils. Triaging these bugs alone
is a decent amou
Thanks Victor and the rest of the Night’s Watch for all the work in
our buildbots!
El jue., 3 de sep. de 2020 a la(s) 12:08, Victor Stinner
(vstin...@python.org) escribió:
>
> Hi,
>
> tl; dr Buildbots were unstable for 3 weeks but the issue is mostly resolved.
>
>
> Since last January, the disk of
On 9/4/20 12:22 PM, Paul Moore wrote:
> I believe that's correct. My main concern here is that removing
> distutils from the stdlib won't have made that problem any better, it
> will simply have transferred the responsibility onto the setuptools
> maintainers. While I assume that they are comforta
I have been using standard distutils for large C extensions without
any issues.
Since distutils does not change, why remove it? It is a lot of work
for people with little gain.
I'd really like to build C extensions without downloading an external
package.
Features like C++ support have not be
On Fri, 4 Sep 2020 at 16:53, Fred Drake wrote:
>
> On Fri, Sep 4, 2020 at 11:02 AM Antoine Pitrou wrote:
> > While I agree with the general suggestion of deprecating distutils as a
> > publicly-visible module (in favour of encouraging users to rely on
> > setuptools), it seems to me that the argu
On Fri, Sep 4, 2020 at 11:02 AM Antoine Pitrou wrote:
> While I agree with the general suggestion of deprecating distutils as a
> publicly-visible module (in favour of encouraging users to rely on
> setuptools), it seems to me that the argument of facilitating the
> development of third-party buil
On Fri, 4 Sep 2020 12:28:30 +0100
Steve Dower wrote:
>
> It will also help
> promote the development of alternative build backends, which can now
> be supported more easily thanks to PEP 517.
While I agree with the general suggestion of deprecating distutils as a
publicly-visible module (in favo
Hi,
Aha, someone proposed the idea :-) I know that Debian removed
distutils from Python stdlib (it is a separate package) for a long
time.
You may mention https://github.com/pypa/distutils/ somewhere in the
PEP: "Python Module Distribution Utilities extracted from the Python
Standard Library". I
Hi all.
setuptools has recently adopted the entire codebase of the distutils
module, so that they will be able to make improvements directly without
having to rely on patching the standard library. As a result, we can now
move forward with official deprecation (in 3.10) and removal (in 3.12)
On Thu, 03 Sep 2020 18:17:12 -
"Brandt Bucher" wrote:
> Tim Peters wrote:
> > `zip` then creates `n` 2-tuple objects, each of which lives only long
> > enough to be unpacked into `x` and `y`... With "immediate" reclamation of
> > garbage via refcounting, memory use is trival regardless of ho
15 matches
Mail list logo
