Skip Montanaro <[EMAIL PROTECTED]> writes: > What's your point? That I have to download and perhaps install them to use > them? In that case, how are these two scenarios different: > > * I have to download and build the MySQLdb package to talk to MySQL > servers from Python code > > * I have to ensure that the readline library and include files are > installed on my system before the readline module (which is included > in the core distribution) can be built
The difference is that once Python is installed on your machine and you can get a ">>>" prompt, you have readline available right away but you have to download something to use MySQLdb. Whoever took care of your Python installation, and it may not have been you, also took care of readline. The past several OS distributions I've installed have included Python and readline out of the box, so I never had to think about readline. The last time I used a Python instance that didn't come with the OS (on Windows XP at work), the IT department had installed Python on my desktop before I started using it, so I still didn't have to worry about readline. But any module that doesn't come in the distro, I have to download myself. > I and many other people happily use external packages other people have > written as well as make stuff available. My guess is that you do as well. No, I don't. I do use them sometimes but I'm unhappy about them. If I can write something using a core module instead of an external module, I prefer to use the core module. So I'll generally use dbm instead of MySQL unless I really need MySQL, which I haven't yet in Python (I've used MySQL with Perl dbi, but Perl, you know, shudder). Also, external module installation scripts often don't work properly, so I end up having to wrestle the code to get it installed. And if a geek like me has such trouble installing external modules, what hope does a normal end-user have? Maybe if you're using Windows, that stuff has been debugged better, but I've had poor results under GNU/Linux. I've had this discussion here before, maybe not with you. What I really want is zero installations of anything. I just want to go to the store and buy a new computer and have a complete OS install with full sources and a full set of applications including Python already installed when I first power it up. My practical approximation is to buy a new computer, immediately reformat the HD to remove the icky Redmond virus, and then install a GNU/Linux distro that includes Python (and readline). If Python really aims for world domination, that means it has to shoot for being preinstalled on almost every new computer the way Windows is now. And all the interesting modules should be there, maybe in a "contrib" directory that gets little or no maintenance priority from the core team. > If everyone adopted your position that it wasn't Python unless it > had been added to the core, we'd all be reinventing lots of wheels > or tackling much less challenging tasks, if we programmed in Python > at all. Here's an incomplete list of stuff not in the core I have > used happily over the past several years to do my jobs using Python: That makes no sense at all. That list is a list of programs written in the Python language. They are Python programs, where Python is an adjective. Python, the noun referring to a piece of software, generally means the stuff in the Python distro. That doesn't stop programs outside the distro from being useful. Mediawiki is a PHP program. That doesn't mean Mediawiki is part of PHP. > * MySQLdb, Sqlite, pycopg, sybase-python - all database modules These should all be in the core if Python wants to be a serious competitor to PHP, which comes with interfaces for those db's and several additional ones besides. That these modules are missing are a significant library deficiency. > * CSV, Object Craft's csv, DSV - csv modules predating csv in the core That's fixed now, csv is in the core. > * SpamBayes I have the impression this is an application and not a module, or anyway is written mainly to support one application. Should be separate. Also, it's written in Python(?) rather than C, which means the installation headaches from not being in the core aren't so bad. > * Quixote Don't know what this is. > * Docutils Should be in the core if it's what I think it is. > * MoinMoin Application, should be separate. Also, GPL'd, I think. Can't be distributed under PSF license. > * Pyrex Sort of problematic, would be interesting to have something like this in the core but maybe Pyrex as it currently stands isn't the answer. I have the impression that PyPy is going to depend on Pyrex in a fundamental way, so it will have to be in the core when we dump CPython. > * Psyco I think this isn't ready for prime time yet. Should go into the core once it is. > * PyInline Not sure what this is. > * PyGTK wxPython might be a better choice. wxpython.org quotes Guido as saying "wxPython is the best and most mature cross-platform GUI toolkit, given a number of constraints. The only reason wxPython isn't the standard Python GUI toolkit is that Tkinter was there first". I don't have direct experience with either wxPython or PyGTK, though. If I can get by with Tkinter, I'd rather do that, since Tkinter is in the core. > * xmlrpclib before it was in the core 1. Did you really need this, instead of some more reasonable rpc format? xdrlib has been in the core forever. 2. Isn't xmlrpclib written in Python? > * MAL's mx.DateTime before the core datetime module was available See, as Python improved, those things went into the core. > * timeout_socket before sockets supported timeouts Could you use sigalarm instead? > Many of those things I could never have written myself, either for > lack of time, lack of skill or both. I'm grateful they were > available when I needed them and feel no qualms about using them > even though they are not distributed with Python proper. Sure, it's fine if you have all those modules and you write a Python program that uses, say, five of them. External modules aren't so bad when the developer and the end user are the same person. What happens if you send your Python program to a nonprogrammer friend who has just a vanilla Python installation? Now he has to download and install those five modules too. You send him the url's where you got the modules a year ago. What are the chances that the 5 url's even all still work, much less the chance of him being able to install and run all 5 of the modules without needing help? What if the versions he downloads (from separate developers) have gotten out of sync with each other and can't interoperate any more? If Python's maintainers are going to recommend those modules to people as a substitute for providing those functions in the core, it would be a big help if the modules were mirrored on python.org instead of merely linked, since a lot of links turn into 404's over time. > Notice another interesting feature of several of those items: csv, > xmlrpclib, mx.DateTime, timeout_socket. They were all modules I used that > eventually wound up in the core in some fashion. They didn't go in the core > first, then demonstrate their usefulness. It was the other way around. I'm not sure about timeout_socket and it sounds like it should have just been a patch to the socket module, not a new module. csv is quite a complex module and took a lot of tweaking and PEP editing before standardization. But the need for it was obvious; the only good reason it wasn't in the core ages ago was that no one had done the work of writing it and shaking it out. xmlrpclib, not sure. How long was it in separate distribution? Also, xmlrpc is a pretty new protocol so it took a while before people wanted it. DES has been around since the 1970's and AES has about the same users as DES, so there's a known level of demand. That should be enough to say yes or no to whether there should be a core module or not. Also, your notion of trying to create a "category king" of AES modules doesn't reflect how these things work. There are at least 10 different AES modules that provide the same AES function. If somebody is using one, they have no reason to switch to another. If it takes 20 visible users for including a module to be worthwhile, and those 10 modules have 5 users each, those populations are going to stay stable until one of them goes in the core and becomes the standard. (And actually: mxCrypto is the most capable of these packages and might be the one with the most users, but it's completely unsuitable for the core because of its size). > Not everything that is useful belongs in the core distribution. I > think you are confusing "batteries included" with "everything, > including the kitchen sink". Well, if you compare the Python stdlib with the toolkits that come with competing languages, say PHP or Java, you can see that Python's lib could be enhanced with considerably more stuff without being excessive. -- http://mail.python.org/mailman/listinfo/python-list