On Thu, Dec 28, 2000 at 12:20:48PM -0500, Eric S. Raymond wrote: > My more general point is that right now Pyjthon has three classes of > modules: > 1. Documented as being in the core and built in by default. > 2. Not documented as being in the core and not built in by default. > 3. Documented as being in the core but not built in by default. > My more general claim is that the existence of class 3 is a problem, > because it compromises the "batteries are included" effect -- it means > Python users don't have a bright-line test for what will be present in > every Python (or at least every Python on an operating system > theoretically feature-compatible with theirs). It depends on your definition of 'being in the core'. Some of the things that are 'in the core' are simply not possible on all platforms. So if you want really portable code, you don't want to use them. Other features are available on all systems that matter [to you], so you don't really care about it, just use them, and at best document that they need feature X. There is also the subtle difference between a Python user and a Python compiler/assembler (excuse my overloading of the terms, but you know what I mean). People who choose to compile their own Python should realize that they might disable or misconfigure some parts of it. I personally trust most people that assemble OS distributions to compile a proper Python binary + modules, but I think a HOWTO isn't a bad idea -- unless we autoconf everything. > I think we ought to be migrating stuff out > of class 3 into class 1 where possible and to class 2 only where > unavoidable. [ and ] > I'm willing to put my effort where my mouth is on this. I have a lot > of experience with autoconf; I'm willing to write some of these nasty > config tests. [ and ] > As I said to Guido, I think it is exactly our job to deal with this sort > of grottiness. One of Python's major selling points is supposed to be > cross-platform consistency of the API. If we fail to do what you're > describing, we're failing to meet Python users' reasonable expectations > for the language. [ and ] > Please note that I am specifically *not* advocating making the build defaults > Linux-centric. That's not my point at all. I apologize for the tone of my previous post, and the above snippet. I'm not trying to block progress here ;) I'm actually all for autodetecting as much as possible, and more than willing to put effort into it as well (as long as it's deemed useful, and isn't supplanted by a distutils variant weeks later.) And I personally have my doubts about the distutils variant, too, but that's partly because I have little experience with distutils. If we can work out a deal where both autoconf and distutils are an option, I'm happy to write a few, if not all, autoconf tests for the currently disabled modules. So, Eric, let's split the work. I'll do Tkinter if you do curses. :) However, I'm also keeping those oddball platforms that just don't support some features in mind. If you want truly portable code, you have to work at it. I think it's perfectly okay to say "your Python needs to have the curses module or the tkinter module compiled in -- contact your administrator if it has neither". There will still be platforms that don't have curses, or syslog, or crypt(), though hopefully none of them will be Linux. Oh, and I also apologize for possibly duplicating what has already been said by others. I haven't seen anything but this post (which was CC'd to me directly) since I posted my reply to Eric, due to the ululating bouts of delay on mail.python.org. Maybe DC should hire some *real* sysadmins, instead of those silly programmer-kniggits ? >:-> -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4