Re: Amber Brown: Batteries Included, But They're Leaking
On 5/19/2019 5:34 PM, Christian Heimes wrote: By the way, I'm working on removing some dead battieres since last year, see proto PEP https://github.com/tiran/peps/blob/oldbatteries/pep-.rst and LWN article https://lwn.net/Articles/755229/ Hooray! I believe that there are other modules, other than distutils, that others have proposed for deletion after 2.7 expires. While deleting in 3.9 would be nice, I agree on waiting for 3.10. Track issues to fix/enhance could be deleted before that. For 3.8, I think deprecation in the docs and possibly PendingDeprecationWarning could be added anytime up to the .rc. colorsys, color conversion functions between RGB, YIQ, HLS, and HSV coordinate systems, seems like it should still be useful. Looking for substututes on pypi, I found pyrgb: color conversion functions - RGB, HSV, HSL, CMYK This needs YIQ to be a superset of colorsys. Py version unspecified. colorutils: among other things, conversions between RGB tuples, 6-character HEX strings, 3-character HEX strings, WEB, YIQ, and HSV. WEB is a 'well-known' color name, when available, such as 'SeaGreen'. (Tk names would be helpful for tkinter programming. HEX is used in Tk.) This needs HSL to be a superset. 2.7, last release 5/25/2015 Conclusion: colorsys could be pretty well replaced by an improved version of either package. In the Linux World comments, k8to says "For a silly data point, I still have code that I still run that process amiga data files that I use in an archival project. I'm a little sad about some of the modules I use being removed from python. I'm sure I can work around the problem though, as I only run the code locally." My thought: who better to maintain an atari date file library than someone who still processes such libraries? So publicize the PEP and encourage experts in old protocols to maintain the corresponding code. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Amber Brown: Batteries Included, But They're Leaking
On 5/19/2019 4:48 PM, Chris Angelico wrote: On Mon, May 20, 2019 at 5:41 AM John Ladasky wrote: On Saturday, May 18, 2019 at 2:21:59 PM UTC-7, Paul Rubin wrote: http://pyfound.blogspot.com/2019/05/amber-brown-batteries-included-but.html This was a controversial talk at the Python language summit, giving various criticisms of Python's standard library, I will try to find some time to read through Amber Brown's remarks. I'll make a few comments too. I read them and the read what I concluded is yet another useless, contradictory, rant based partly on ignorance and mis-information. You corrected some of the latter. Brown said her point was to move asyncio to PyPI, along with most new feature development. “We should embrace PyPI,” she exhorted. This is the only "action item" I've found in the entire rant. The disinformation is the implication that core developers have not embraced pypi. But anyone reading this list and python-ideas would know that it is mostly users pushing for new modules and some particular features in the stdlib and core developers saying "Whoo, we are already overloaded. Start something on pypi first and *maybe* we will consider it later." I think her main point is that she, a twisted developer, is mad and thinks it unfair that competitor asyncio was privileged by being allowed to be developed in the stdlib. Hence, "Ever since asyncio was announced she has had to explain why Twisted is still worthwhile". And hence her wish that it, in particular, be relegated to being one competitor among others on pypi. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Amber Brown: Batteries Included, But They're Leaking
On Mon, May 20, 2019 at 7:38 AM Christian Heimes wrote: > > On 19/05/2019 22.48, Chris Angelico wrote: > >> the sslmodule requires a monkeypatch to connect to non-ASCII domain names, > > It's not correct. There were some bugs in IDNA support in the SSL > module. Nathaniel and I worked on the topic and fixed it in 3.7, see > https://bugs.python.org/issue28414 > > Python stdlib in general does not support some non-ASCII domain names > (German, Greek, and some Asian languages), because there is no IDNA 2008 > encoding in the stdlib. The problem is not in the SSL module, but starts > as low as host name encoding for DNS lookups. The solution here is to > *add* more features to the stdlib, see > https://bugs.python.org/issue17305 > Thanks. And I agree; if there are limitations like this in the stdlib, the stdlib needs to be fixed. That's not a leaking battery. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Amber Brown: Batteries Included, But They're Leaking
On 19/05/2019 22.48, Chris Angelico wrote: >> the sslmodule requires a monkeypatch to connect to non-ASCII domain names, It's not correct. There were some bugs in IDNA support in the SSL module. Nathaniel and I worked on the topic and fixed it in 3.7, see https://bugs.python.org/issue28414 Python stdlib in general does not support some non-ASCII domain names (German, Greek, and some Asian languages), because there is no IDNA 2008 encoding in the stdlib. The problem is not in the SSL module, but starts as low as host name encoding for DNS lookups. The solution here is to *add* more features to the stdlib, see https://bugs.python.org/issue17305 By the way, I'm working on removing some dead battieres since last year, see proto PEP https://github.com/tiran/peps/blob/oldbatteries/pep-.rst and LWN article https://lwn.net/Articles/755229/ Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: Amber Brown: Batteries Included, But They're Leaking
On Mon, May 20, 2019 at 5:41 AM John Ladasky wrote: > > On Saturday, May 18, 2019 at 2:21:59 PM UTC-7, Paul Rubin wrote: > > http://pyfound.blogspot.com/2019/05/amber-brown-batteries-included-but.html > > > > This was a controversial talk at the Python language summit, giving > > various criticisms of Python's standard library, > > I will try to find some time to read through Amber Brown's remarks. I'll make a few comments too. > Applications Need More Than The Standard Library > > For example, asyncio requires external libraries to connect to a database or > to speak HTTP. Nothing in Python's standard library connects to a database (with the minor exception of sqlite3, which isn't so much "connecting to a database" as "reading a database file"). This is not a dependency of asyncio any more than psycopg2 (from PyPI) is a dependency of the socket module. HTTP might be a valid point, as many applications could restrict themselves to the stdlib if working synchronously or with threads, but to do so with asyncio would require manually crafting HTTP requests and parsing HTTP responses. Would have to confirm that, though; is it possible to use asyncio's socket services with other modules in the stdlib? > Brown asserted that there were many such dependencies from the standard > library to PyPI: No, that is not a dependency. A dependency is where something cannot run without something else. Nothing in the stdlib depends on anything from PyPI. Claiming that an application needs a library from PyPI is not the same as showing a dependency. > typing works best with mypy, The point of the typing module is to be the baseline that makes annotations legal and executable, without giving them actual meaning. Good use of mypy (or any other type checker - it's intentionally generic) can be by publishing something that depends only on the stdlib, but on your development computer, you install mypy. This is the entire point of the typing module - to be part of the stdlib and allow the code to run unmodified (but unchecked). > the sslmodule requires a monkeypatch to connect to non-ASCII domain names, Is that true? If confirmed, that should just be raised as an issue and dealt with. > datetime needs pytz, You can easily use datetime without timezone support, either just using naive datetimes, or using UTC. The stdlib includes support for fixed UTC offsets too, but not daylight saving time. Considering that the tzdata files get updated about ten times a year, baking that into the stdlib would be a bad idea. > and six is non-optional for writing code for Python 2 and 3. Absolutely false. I have written 2/3 spanning code without six. It's a convenience, and most assuredly not "non-optional". Also, writing Py3-only code is a completely reasonable choice, especially as 2020 approaches. > Other standard library modules are simply inferior to alternatives on PyPI. Honestly, not surprised. If the stdlib modules were superior to the PyPI ones, the latter wouldn't exist. There are plenty of reasons for superior options to be installable, and that's not a problem. The stdlib is there for people who want to be strict about deployment, which makes it easier for people to use a script. > The http.client documentation advises readers to use Requests, And that's a prime example; the requests module changes too frequently to be baked into the stdlib usefully. > and the datetime module is confusing compared to its competitors such as > arrow, dateutil, and moment. I've never even heard of arrow. Not sure what the issue is with datetime; more details needed. > Standard Library Modules Crowd Out Innovation > > 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. This opinion is in direct conflict with the prior complaint that there are stdlib modules inferior to third-party ones. > 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. And this is what happens when you look at statistics to make your decisions. So long as you say "half of Twisted users are on Python 2, we have to support it", those users will say "Twisted still supports Python 2, we don't have to move". Maybe it's not about abandoning people but about drawing them onto a more recent Python. > Brown said her point was to move asyncio to PyPI, along with most new > feature development. “We should embrace PyPI,” she exhorted. This is the only "action item" I've found in the entire rant. Quite aside from the backward incompatibility in the specific example of removing asyncio from the
Re: Amber Brown: Batteries Included, But They're Leaking
On Saturday, May 18, 2019 at 2:21:59 PM UTC-7, Paul Rubin wrote: > http://pyfound.blogspot.com/2019/05/amber-brown-batteries-included-but.html > > This was a controversial talk at the Python language summit, giving > various criticisms of Python's standard library, I will try to find some time to read through Amber Brown's remarks. For now, I just want to remind everyone that we had this exact discussion here, about two years ago. First post in the thread, if you want to see the source: https://groups.google.com/forum/#!original/comp.lang.python/B2ODmhMS-x4/KMpF4yuHBAAJ Here are a few excerpts from the thread: On Saturday, September 16, 2017 at 11:01:03 PM UTC-7, Terry Reedy wrote: > The particular crippler for CLBG [Computer Language Benchmark Game] > problems is the non-use of numpy in numerical calculations, such as the > n-body problem. Numerical python extensions are over two decades old > and give Python code access to optimized, compiled BLAS, LinPack, > FFTPack, and so on. The current one, numpy, is the third of the series. > It is both a historical accident and a continuing administrative > convenience that numpy is not part of the Python stdlib. On Monday, September 18, 2017 at 10:21:55 PM UTC+1, John Ladasky wrote: > OK, I found this statement intriguing. Honestly, I can't function without > Numpy, but I have always assumed that many Python programmers do so. > Meanwhile: most of the time, I have no use for urllib, but that module is > in the standard library. > > I noticed the adoption of the @ operation for matrix multiplication. I > have yet to use it myself. > > So is there a fraction of the Python community that thinks that Numpy > should in fact become part of the Python stdlib? What is the > "administrative convenience" to which you refer? On 2017-09-18 23:08, bream...@gmail.com wrote: > My very opinionated personnal opinion is that many third party libraries > are much better off outside of the stdlib, numpy particulary so as it's > one of the most used, if not the most used, such libraries. > > My rationale is simple, the authors of the libraries are not tied into > the (c)Python release cycle, the PEP process or anything else, they can > just get on with it. > > Consider my approach many blue moons ago when I was asking when the "new" > regex module was going to be incorporated into Python, and getting a bit > miffed in my normal XXXL size hat autistic way when it didn't happen. I > am now convinved that back then I was very firmly wrong, and that staying > out of the stdlib has been the best thing that could have happened to > regex. On Tuesday, September 19, 2017 at 12:11:58 AM UTC-7, Steven D'Aprano wrote: > On Tue, 19 Sep 2017 01:13:23 +0100, MRAB wrote: > > > I even have it on a Raspberry Pi. "pip install regex" is all it took. No > > need for it to be in the stdlib. :-) > > That's fine for those of us who can run pip and install software from the > web without being immediately fired, and for those who have installation > rights on the computers they use. And those with easy, cheap and fast > access to the internet. > > Not everyone is so lucky. I'm not offering an opinion, just some historical context FYI. -- https://mail.python.org/mailman/listinfo/python-list
