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,
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
Batteries Included...
Today's XKCD comic has a nice Python reference! http://xkcd.com/413/ -- http://mail.python.org/mailman/listinfo/python-list
batteries included
Could someone confirm that modules like socket don't use libraries/ dlls on a particular OS, they are completly self contained. Thanks, Marc. -- http://mail.python.org/mailman/listinfo/python-list
Re: batteries included
[EMAIL PROTECTED] wrote: Could someone confirm that modules like socket don't use libraries/ dlls on a particular OS, they are completly self contained. They might need DLLs, but if so they ship with the distribution. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: the whole 'batteries included' idea
John Salerno wrote: Pardon my naivety, you would think maybe I'd understand this by now, but I've always kind of wondered about it. I've been curious why one of the biggest points used to promote Python is that it has batteries included. True, this is a great feature, but the way it's been used seems to suggest that other languages *don't* have this benefit. And maybe they don't, in their own way. So my question is, what is the difference between Python's 'batteries' (standard modules), and C#'s framework? I can't speak for C#'s framework but Python has a lot of modules that other languages may not, such as zip/bzip archive handling, unit testing, database interface modules, pretty much any network protocol you might need, both types of XML handling, etc. For many tasks, it's complete as-is, and that's a point worth selling. I don't think it's as good as some people make out, though. Multimedia support is poor - OpenGL support should have gone in many, many versions ago, and presumably one of the trillion incarnations of libraries for fast mathematics should have gone in too in order to enable that. PyGame could possibly have gone in too (not sure about the license however). -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
the whole 'batteries included' idea
Pardon my naivety, you would think maybe I'd understand this by now, but I've always kind of wondered about it. I've been curious why one of the biggest points used to promote Python is that it has batteries included. True, this is a great feature, but the way it's been used seems to suggest that other languages *don't* have this benefit. And maybe they don't, in their own way. So my question is, what is the difference between Python's 'batteries' (standard modules), and C#'s framework? I know nothing of Java, but I assume it has its own rich (and confusing) set of classes as well. Is there something different about other languages' libraries/frameworks that makes Python's different, and worthy of being touted as 'batteries included'? I hope that question even makes sense! :) -- http://mail.python.org/mailman/listinfo/python-list
Re: the whole 'batteries included' idea
John Salerno wrote: Pardon my naivety, you would think maybe I'd understand this by now, but I've always kind of wondered about it. I've been curious why one of the biggest points used to promote Python is that it has batteries included. True, this is a great feature, but the way it's been used seems to suggest that other languages *don't* have this benefit. And maybe they don't, in their own way. So my question is, what is the difference between Python's 'batteries' (standard modules), and C#'s framework? I know nothing of Java, but I assume it has its own rich (and confusing) set of classes as well. Is there something different about other languages' libraries/frameworks that makes Python's different, and worthy of being touted as 'batteries included'? I hope that question even makes sense! :) I believe Python is unique in the depth of the standard library when compared to most languages. Most require that you purchase or get many of the batteries from somewhere outside the standard distribution. Things like FTP clients, SMTP clients, webservers, etc. aren't normally there by default. -Larry Bates -- http://mail.python.org/mailman/listinfo/python-list
Re: the whole 'batteries included' idea
John Salerno napisał(a): So my question is, what is the difference between Python's 'batteries' (standard modules), and C#'s framework? I know nothing of Java, but I assume it has its own rich (and confusing) set of classes as well. Is there something different about other languages' libraries/frameworks that makes Python's different, and worthy of being touted as 'batteries included'? I can speak only for Java -- its batteries are not included, you have to download jakarta-commons plus (since Python 2.5) JDOM to get the effect similar to Python's stdlib. Java library only seems to be complete (i.e. when looking on included classes), but its support for common programming tasks is just inadequate. -- Jarek Zgoda http://jpa.berlios.de/ -- http://mail.python.org/mailman/listinfo/python-list
Batteries Included?
One of the first things I wanted to do when I start learning Python was to produce a simple standalone application that I could distribute to my users (windows users). Python's moto is Batteries Included, but where are the batteries for making exe files and making an installer file? I had to download, install and use py2exe and Inno Setup in order to accomplish this. I might be wrong expecting that a language whose moto is Batteries Included would be able to produce exe files. Are there plans to do this in the future version of Python? Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Batteries Included?
Alex enlightened us with: Python's moto is Batteries Included, but where are the batteries for making exe files and making an installer file? Those aren't batteries. Those are things you can do with the program, but are outside the programming language. Writing and distributing software is one thing. Converting them to a platform-specific executable is another. I had to download, install and use py2exe and Inno Setup in order to accomplish this. Well done. I might be wrong expecting that a language whose moto is Batteries Included would be able to produce exe files. Indeed, you're wrong. Why would such an ability be included in Python? It's a cross platform language. What need would Mac, Linux, BSD, Solaris etc. users have for such a feature? And why would it have to be included, when there is an easy solution just around the corner? You prooved that it was easy enough to install and use by someone who just learned Python. I really don't see the problem here. Are there plans to do this in the future version of Python? I doubt it. Sybren -- The problem with the world is stupidity. Not saying there should be a capital punishment for stupidity, but why don't we just take the safety labels off of everything and let the problem solve itself? Frank Zappa -- http://mail.python.org/mailman/listinfo/python-list
Re: Batteries Included?
Alex [EMAIL PROTECTED] writes: One of the first things I wanted to do when I start learning Python was to produce a simple standalone application that I could distribute to my users (windows users). Python's moto is Batteries Included, but where are the batteries for making exe files and making an installer file? I had to download, install and use py2exe and Inno Setup in order to accomplish this. I might be wrong expecting that a language whose moto is Batteries Included would be able to produce exe files. Are there plans to do this in the future version of Python? Did you try looking through the distutils docs? After you create a setup.py file for you program, doing python setup.py bdist --formats=wininst should do the trick. Of course, I don't own a Windows box, so I can't check it, but when I ask a setup file for help on formats, it tells me the wininst format is a windows installer. Personally, I think of building a platform-specific bundle for distribution to end users as more along the lines of shipping than batteries. Python comes with lots of tools to help you get your application working - the batteries. Once it's working, you don't need batteries: you need wrapping paper, and a box, and tape, and so on. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Batteries Included?
Sybren Stuvel [EMAIL PROTECTED] writes: I might be wrong expecting that a language whose moto is Batteries Included would be able to produce exe files. Indeed, you're wrong. Why would such an ability be included in Python? distutils.exe, included in Python, in fact does have the ability to produce .exe files, just not completely general ones. It's a cross platform language. What need would Mac, Linux, BSD, Solaris etc. users have for such a feature? The same need that they have for msvcrt, winreg, winsound, or the SGI IRIX specific functions currently in the library. The same need that Windows users have for the Unix specific parts which are in the library. The same need that non-numeric programmers have for the cmath module, which is also in the library. And why would it have to be included, when there is an easy solution just around the corner? You prooved that it was easy enough to install and use by someone who just learned Python. I really don't see the problem here. Um, if the TV ad for some Walkman says batteries included and the batteries aren't included, you have legitimate reason to ask what's going on. That it's easy enough for you to go to the store and buy batteries separately is irrelevant. You didn't get what was advertised. Now a Windows .exe installer wasn't one of the advertised features of Python and maybe there's good reasons to leave it out, but its platform specificness is not one of those reasons. There's already plenty of platform specific stuff in Python. Personally I think including a .exe packager in Python would be a great idea. As a Linux user I can't easily run Windows-specific utilities like Inno Setup. So I don't have a good way to make .exe's from my Python code that Windows users can easily run. Having a cross platform .exe packager included with Python would be useful the same way cross compilers are useful. I'm using an x86 computer but I can easily configure gcc to produce ARM code. Why shouldn't my Linux Python installation be able to produce Windows .exe's? -- http://mail.python.org/mailman/listinfo/python-list
Re: Batteries Included?
Mike Meyer: After you create a setup.py file for you program, doing python setup.py bdist --formats=wininst should do the trick. Of course, I don't own a Windows box, so I can't check it, but when I ask a setup file for help on formats, it tells me the wininst format is a windows installer. I can confirm that it works (for pure Python applications), since I did it. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Batteries Included?
I might be wrong expecting that a language whose moto is Batteries Included would be able to produce exe files. Are there plans to do this in the future version of Python? Yes, you are wrong expecting that. Creating an exe-cutable is windows specific and python _tries_ to be platform neutral. py2exe - a wonderful tool which I use myself - is a battery on the shelves. It can be easily picked from there. Furthermore it is not Python's philosophy to create exe-cutables. But I do understand your wish (being a Windows Developper at work myself) and Python is not a matter of course within Windows. Your best bet is ActiveState which bundles a windows specific version. Ask them, maybe they are willing to include it. Python should refrain from doing so. Before overloading the included batteries an approach as found in Perl (CPAN) should be adapted... eg. http://peak.telecommunity.com/DevCenter/EasyInstall Have a nice day, Marco -- http://mail.python.org/mailman/listinfo/python-list
Re: Batteries Included?
On 11 Oct 2005 00:10:01 -0700 Paul Rubin wrote: Personally I think including a .exe packager in Python would be a great idea. As a Linux user I can't easily run Windows-specific utilities like Inno Setup. So I don't have a good way to make .exe's from my Python code that Windows users can easily run. Having a cross platform .exe packager included with Python would be useful the same way cross compilers are useful. I'm using an x86 computer but I can easily configure gcc to produce ARM code. Why shouldn't my Linux Python installation be able to produce Windows .exe's? Because you can't run it yourself? If you cannot run the freshly-made exe yourself, why would you want to distrubute it, without even trying? But if you can, then you can run the InnoSetup as well. But, for me, I don't care whether such an option will be included or not. I won't object anyway. -- jk -- http://mail.python.org/mailman/listinfo/python-list
Re: Batteries Included?
[EMAIL PROTECTED] writes: Because you can't run it yourself? If you cannot run the freshly-made exe yourself, why would you want to distrubute it, without even trying? But if you can, then you can run the InnoSetup as well. Obviously I'd want someone to test the .exe before putting it in wide distribution. That doesn't solve the problem of how to make the .exe. -- http://mail.python.org/mailman/listinfo/python-list
