>>>>> "JL" == James Logajan <JamesL at Lugoj.Com> writes: JL> Luke wrote: >> Furthermore, the syntax and features of the language keep >> changing with every release. JL> That is almost tautological; a new release of a language doesn't JL> normally add libraries or modules, it normally means the syntax JL> or semantics have changed somewhere (excepting minor releases JL> intended to fix bugs). A new release could just add libraries or modules. The language and the standard library are not packaged separately. There are lots of modules distributed separately, of course. But if you want to fix the cgi module, you need to get a new Python release out. JL> If your objection is that there are too many releases of the JL> language, then I would agree completely. Guido and the entire JL> Python development team need to take a five year JL> vacation. Releasing new versions more often than about every two JL> years, except for bug fixes, is probably self destructive. You should talk to my employer. I'd love it if they'd give me five years of vacation <wink>. As it is, it's only a few weeks -- not enough to really delay Python releases. I'd agree that releasing new major versions more then every two years would be crazy -- hard on both language developers and language users. I don't think that the changes in the recently released Python 2.1 are all that major. The biggest change, nested scopes, is only available to programmers who specifically opt-in; we decided to delay the mandatory introduction of the feature until the next release (2.2). Otherwise, the new features are mostly small and useful only to people who were looking for them -- weak references, warnings, rich comparisons. People have wanted these features for a while, but they aren't of major significance. If you were trying to do sensible comparisons with your own instances, rich comparisons will make things a lot easier. Most people, though, will never see them. Most of the interesting bug fixes involve introducing new features or removing broken ones, anyway. The cgi module used to keep a copy of all lines read via file uploads. That was a real problem for people using cgi to upload large files. But to fix it required that we remove a feature that other users might have depended on. So a strict bug fix policy for two years would basically prevent any improvements to the language or library. Users probably suffer more because they spend years working around bugs and then have more difficulty porting when the language is finally changed. Jeremy
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