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
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
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
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
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
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
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
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
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
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
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
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
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
On 30/07/2020 00:34, Nick Coghlan wrote:
the proposed name binding syntax inherently conflicts with the
existing assignment statement lvalue syntax in two areas:
* dotted names (binds an attribute in assignment, looks up a
constraint value in a match case)
* underscore targets (binds in
16 matches
Mail list logo
