I definitely agree with her on this:

Some ecosystems such as Javascript rely too much on packages, she conceded, but there are others like Rust that have small standard libraries and high-quality package repositories. She thinks that Python should move farther in that direction.

For example, the stdlib datetime module is terrible for dealing with any real-world data, particularly anything timezone-aware (a separate talk at this same summit covered the desire to bring timezones into the stdlib) so the standard advice is to install something like Pendulum. Either the stdlib should have something as high-quality as Pendulum, or datetime handling should be punted entirely from the stdlib.

However, the part that immediately precedes that I completely disagree with:

Brown said her point was to move asyncio to PyPI, along with most new feature development.

async and await are part of the Python language, so the asyncio module needs to be as well. I think her position as a Twisted maintainer is biasing her here. asyncio is the future. Libraries like Twisted and gevent each implementing their own asynchronous I/O and creating a completely fragmented ecosystem is the past.

Although Python 2 is nearly at its end of life, this only holds for the core developers, according to Brown, and for users, Red Hat and other distributors will keep Python 2 alive “until the goddam end of time.”

...

Van Rossum argued instead that if the Twisted team wants the ecosystem to evolve, they should stop supporting older Python versions and force users to upgrade. Brown acknowledged this point, but said half of Twisted users are still on Python 2 and it is difficult to abandon them. The debate at this point became personal for Van Rossum, and he left angrily.

Yes, let Python 2 die. Red Hat is going to keep supporting it for as long as people will pay for it, but that doesn't mean libraries maintained by volunteers should feel obligated to do the same.

Brown’s most controversial opinion, in her own estimation, is that adding modules to the standard library stifles innovation, by discouraging programmers from using or contributing to competing PyPI packages. Ever since asyncio was announced she has had to explain why Twisted is still worthwhile, and now that data classes are in the standard library Hynek Schlawack must defend his attrs package. Even as standard library modules crowd out other projects, they lag behind them. According to Brown, “the standard library is where code sometimes goes to die,” because it is difficult and slow to contribute code there. She acknowledged recent improvements, from Mariatta Wijaya’s efforts in particular, but Python is still harder to contribute to than PyPI packages.

Can't get behind any of that. I'd always be in favour of sacrificing or incorporating libraries for enhancing standard library, because, as the name implies, it sets a standard for everyone, which can be trusted. As a language of preference in the scientific community, Python has proven the usefulness of this multiple times: not only there is a core standard library, but there are other standard libraries that wrap and extend it for more specific purposes: like Scipy, for example. Or Django.

If our code will live on for decades, having a big stdlib to rely on is a good thing. Lagging behind is no problem, a little complexity is no problem, compared to the problems that having to follow an ever-moving libraries with no-one to ensure compatibility---both diachronical and synchronical, i.e. both backwards and among-them---are bigger. And Python's selling point is that this is less of a problem with it than it is with other proglang ecosystems.

Also, if you're talking about stifling innovation, insisting on supporting Python 2, which will die in a few months, is just the opposite of it.

There are some problems pointed out there that seem to be valid, but packing actual problems up with a certain group's or individual's desires for the future of the project is not nice.

Guido van Rossum, sitting at the back of the room, interrupted at this moment, “Can you keep to one topic? I'm sorry but this is just one long winding rant. What is your point?” Brown responded that her point was that there are a multitude of problems in the standard library.

Guido van Rossum stormed from the room during Q & A.

Is this typical behavior from the creator of Python?

Brown also mentioned that some itertools code is shown as examples in the documentation instead of shipped as functions in the itertools module.

This is slightly annoying, but hardly a reason for such drastic change as she is proposing. I can't help but feel a lot of these problems could be fixed by making it easier to contribute to the standard library (as she even acknowledges has been happening).

Some ecosystems such as Javascript rely too much on packages, she conceded, but there are others like Rust that have small standard libraries and high-quality package repositories. She thinks that Python should move farther in that direction.

On the other hand, encouraging use of package indexes can cause fragmentation - try choosing a logging crate for Rust and you'll have to decide which of the 20 or so options is best for you. Python, however, is super simple - import logging and do basicConfig.

That's not to say that she's wrong - she definitely has a point with a lot of standard library modules being clearly inferior to PyPI alternatives, and the standard library often lagging behind.