Thomas Wouters <thomas@xs4all.net>: > > 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. I understand. We can't, for example, guarantee to duplicate the Windows- specific stuff in the Unix port (nor would we want to in most cases :-)). However, I think "we build in curses/Tkinter everywhere the corresponding libraries exist" is a guarantee we can and should make. Similarly for other modules presently in class 3. > 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). Yes. We have three categories here: 1. People who use python for applications (what I've been calling users) 2. People who configure Python binary packages for distribution (what you call a "compiler/assembler" and I think of as a "builder"). 3. People who hack Python itself. Problem is that "developer" is very ambiguous in this context... > 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'd like to see both things happen (HOWTO and autoconfing) and am willing to work on both. > I apologize for the tone of my previous post, and the above snippet. No offense taken at all, I assure you. > 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. I admit I'm not very clear on the scope of what distutils is supposed to handle, and how. Perhaps amk can enlighten us? > So, Eric, let's split the work. I'll do Tkinter if you do curses. :) You've got a deal. I'll start looking at the autoconf code. I've already got a fair idea how to do this. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> No one who's seen it in action can say the phrase "government help" without either laughing or crying.
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