Advertisement
Front, Kernel, Security, Distributions, Development. See your byline here on LWN.net.
Weekly Edition
Return to the Development page
| |||||||||||||
|
| |||||||||||||
Python 2.3 release candidate 1
I am very happy to announce the release of Python 2.3 release candidate 1. The python-dev crew has fixed almost 50 bugs since the beta release last month. You can find the downloads at the usual place: http://www.python.org/2.3/ All major reported bugs have been fixed for this release. If we do not discover any major bugs in the next week, we will re-release this code as Python 2.3 final. We encourage potential users of Python 2.3 to try the release candidate with their programs and report any bugs as soon as possible. To report a new bug, use the SourceForge bug tracker http://sourceforge.net/bugs/?func=addbug&group_id=5470 This release of Python does not have any big changes, but it does have many small changes that improve the libraries, fix bugs, and increase stability. According to some simple benchmarks, Python 2.3 is 25-30% faster than Python 2.2.3. There are about 15 new or significantly revised standard library modules, and a few new builtins. Andrew Kuchling's What's New in Python 2.3 describes the most visible changes since Python 2.2 in more detail: http://www.python.org/doc/2.3c1/whatsnew/ Have fun! -- Jeremy Hylton <http://www.python.org/~jeremy/> -- http://mail.python.org/mailman/listinfo/python-announce-list (Log in to post comments)
Python 2.3 release candidate 1 Posted Jul 19, 2003 19:03 UTC (Sat) by Baylink (guest, #755) [Link] Can I be a bit of a Luddite for a minute?I've been one flavor or another of professional programmer and geek for very close to 2 decades now (ghod, that's painful to admit :-). And C never changed. And COBOL rarely changed. And my 4GL's added a new feature or two here or there, but they didn't change much either. But Perl keeps changing, and Python keeps changing, and Zope (which for *my* purposes is a giant 4GL with a frame around it) changes a *lot*. It's frustrating. Is it just me? Cause, y'know, so many things are just me...
Language changes Posted Jul 19, 2003 21:40 UTC (Sat) by corbet (editor, #1) [Link] "I've been one flavor or another of professional programmer and geek for very close to 2 decades now (ghod, that's painful to admit :-). And C never changed. Gee, when I first started programming in C, it lacked:
...and so on. And that doesn't count all the gcc extensions. You're just too young, Jay! :) All languages go through periods of greater and lesser change; Fortran is still evolving. Just because C is relatively stable now doesn't mean it wasn't always that way, or that other languages shouldn't press forward. I don't like everything that has gone into Python, but quite a bit of it is very nice.
Language changes Posted Jul 19, 2003 23:42 UTC (Sat) by tjc (guest, #137) [Link] Not to mention the stuff we got just a couple years ago (some of which hasn't made it into gcc yet), like language support for complex numbers, restricted pointers, "official" inline functions, "official" variable-size arrays, and a lot more __garbage in the standard library header files.Most of it can be ignored, which is a feature in itself.
Language changes Posted Jul 20, 2003 0:54 UTC (Sun) by Baylink (guest, #755) [Link] > most of it can be ignoredPrecisely. I've sort of gotten the impression that that isn't always true of the changes to, eg Python and when I see things like "try your code out on the new version of the language to make sure it still works" I tend to think "a) huh?! and b) don't these people understand regression testing?" Yeah, I came to C late, but... I dunno... I guess my problem is that I like "release early and often" for everything *except* languages. I can even live with the toolsets revving to a certain extent, but when the syntax and semantics of languages are subject to change... well, maybe it's just because I'm still running RH7.3, and people's careless binary package building habits are putting me in dependency hell and it's spilling over to this. I dunno...
Language changes Posted Jul 20, 2003 1:45 UTC (Sun) by pto (guest, #5753) [Link] Python is really very good at being backwards compatible. I think that if you found aprogram that didn't work with the new version, the developers would like to hear about it. What's the point of a release candidate unless people try out their programs on it and see if it works?
Language changes Posted Jul 21, 2003 12:28 UTC (Mon) by stuart (subscriber, #623) [Link] Isn't offering a release candidate an open source way of doing detailed regression testing?Stu.
Language changes Posted Jul 24, 2003 13:43 UTC (Thu) by zooko (subscriber, #2589) [Link] I think the calls to try out your code with the new release are a plea to search for implementation bugs, not a warning that the language has changed and your code might now be incorrect with respect to the new language. I don't know for sure if there are any changes in Python 2.3 that could cause code to break. I certainly haven't noticed any in my code, and I have a lot of Python code. I think Python 2.3 is one of the most backwards-compatible releases of Python ever. It is also one of the speediest! Finally, it is (probably) going to be shipped with the next version of Mac OS X. These are three reasons why I am excited about Python 2.3.
Language changes Posted Jul 27, 2003 13:39 UTC (Sun) by copsewood (subscriber, #199) [Link] >I don't know for sure if there are any changes in Python 2.3 that could >cause code to break. I certainly haven't noticed any in my code, and I have >a lot of Python code.There are one or 2 which could do this. For example if you use "yield" as a variable, function or method name as it's now a keyword. There are a few other, generally more unlikely things which could just break existing code but seem unlikely to do so.
Python 2.3 release candidate 1 Posted Jul 21, 2003 14:41 UTC (Mon) by in-spec-inc (guest, #4438) [Link] > But Perl keeps changing, and Python keeps changing, and Zope (which for *my* purposes is a giant 4GL with a frame around it) changes a *lot*. It's frustrating. Is it just me?There are at least four different questions here. I'll tackle Python (which doesn't change a *lot*, but this thread is in a Python announcement): 1. It sounds like you may not use Python day-to-day. Some of the changes in Python have been *very* empowering - e.g., generators. Or unification of types and classes. Or the Set datatype. Or support for CSV files. These things save DAYS of a programmer's time. "A programmer" = "me". I'm working in QA, and I write about two dozen Python programs a month. The time savings are mostly in debugging, unquestionably the best place for me to save time. Having the language parse CSV files means I won't write an error into a my next comma-parsing routine. (Because I won't write any more comma-parsing routines.) And I don't even think of writing my own code anymore to do record aggregation, hairy to debug and almost always buggy - generators do that, right the first time. THANK ERIC the days of wasting time debugging that kind of thing are gone forever! These things are real advances. It's hard to see how such new powers can be given to programmers without "change". 2. Other improvements, although seemingly minor (e.g., Booleans) make everyone's understanding easier. I teach beginning programming classes. Unless you teach you've no idea of the relief to not stumble around explaining "zero represents False" etc. when you're trying to introduce logical structures. Things like Booleans make every student's hurdles lower. (And they continue to benefit every Python programmer on the job forever, because clarity does matter). It's hard to see how such improvements can be given to the language's users without "change". 3. Python IS intensely unit-tested before a release candidate is offered. The RC stage is in no way a substitute for testing (and no one is slacking, which seems to be the inference of one post). I've installed every beta, and I've NEVER encountered a bug. No matter how exhaustive your unit testing, you'd offer a release candidate before making formal commitments. (Wouldn't you?) 4. The Python community is very much aware of the cost of change. Read the PEPs (Python Enhancement Proposals, the mechansim they use to evaluate changes) if you'd like to see how much debate goes into a decision whether or not to implement one. (Sick humor: especially recommended is the discussion on the ternary operator. :) 5. Very few changes have ever required a Python user to change already-written code. I have never had to change a single line of code. 6. Finally and in any case, no one forces any Python user to upgrade - you're free to stay with whatever version you like. Python is Free Software. Your programs continue to run, Python continues to work. And you have the sources to guarantee those things. -Bill Sconce
Python 2.3 release candidate 1 Posted Jul 21, 2003 18:36 UTC (Mon) by Baylink (guest, #755) [Link] > > But Perl keeps changing, and Python keeps changing, and Zope (which for *my* purposes is a giant 4GLwith a frame around it) changes a *lot*. It's frustrating. Is it just me? > There are at least four different questions here. I'll tackle Python (which doesn't change a *lot*, but this thread is in a Python announcement): I'm replying to this as much to get usable line wraps into it as anything; what's *up* with that? > 1. It sounds like you may not use Python day-to-day. Some of the changes in Python have been *very* empowering - e.g., generators. Or unification of types and classes. Or the Set datatype. Or support for CSV files. These things save DAYS of a programmer's time. I can understand some of those things... but mostly the ones that are core. CSV belongs in a library, no? > "A programmer" = "me". I'm working in QA, and I write about two dozen Python programs a month. The time savings are mostly in debugging, unquestionably the best place for me to save time. Having the language parse CSV files means I won't write an error into a my next comma-parsing routine. (Because I won't write any more comma-parsing routines.) And I don't even think of writing my own code anymore to do record aggregation, hairy to debug and almost always buggy - generators do that, right the first time. THANK ERIC the days of wasting time debugging that kind of thing are gone forever! Fine, but, again, "library". Not "language definition". > These things are real advances. It's hard to see how such new powers can be given to programmers without "change". Stipulated. But understand that I started getting interested in Python *just* as 2 replaced 1.5, and all the books became semi-obsolete. You can *still* learn C from K&&R. > 2. Other improvements, although seemingly minor (e.g., Booleans) make everyone's understanding easier. I teach beginning programming classes. Unless you teach you've no idea of the relief to not stumble around explaining "zero represents False" etc. when you're trying to introduce logical structures. Things like Booleans make every student's hurdles lower. (And they continue to benefit every Python programmer on the job forever, because clarity does matter). It's hard to see how such improvements can be given to the language's users without "change". Ok, fine here, too. Adding data types, particularly ones that everyone knows, ain't a real stretch either. > 3. Python IS intensely unit-tested before a release candidate is offered. The RC stage is in no way a substitute for testing (and no one is slacking, which seems to be the inference of one post). I've installed every beta, and I've NEVER encountered a bug. Glad to hear that. But "doesn't run my old programs anymore" is not a bug, if it's defined that way. It *does*, however, still fit the definition of my problem. > No matter how exhaustive your unit testing, you'd offer a release candidate before making formal commitments. (Wouldn't you?) Sure. > 4. The Python community is very much aware of the cost of change. Read the PEPs (Python Enhancement Proposals, the mechansim they use to evaluate changes) if you'd like to see how much debate goes into a decision whether or not to implement one. (Sick humor: especially recommended is the discussion on the ternary operator. :) <chuckle> Yeah; I have a vague idea. Maybe I'm just getting stuck in the mud in my old age. > 5. Very few changes have ever required a Python user to change already-written code. I have never had to change a single line of code. Noted. > 6. Finally and in any case, no one forces any Python user to upgrade - you're free to stay with whatever version you like. Python is Free Software. Your programs continue to run, Python continues to work. Well, as someone who's still running RH7.3, I can tell you that that's fine, but your workload curve may skyrocket as you start having to build things yourself that you didn't have to before. That's pertinent too. > And you have the sources to guarantee those things. See immediately above. -- j
Python 2.3 release candidate 1 Posted Jul 25, 2003 18:39 UTC (Fri) by skybrian (subscriber, #365) [Link] > I can understand some of those things... but mostly the ones that are core. CSV belongs in a library, no?It is a new library. Python comes with a large number of standard libraries, similar to Java. Most of the changes are in the libraries.
|
|
||||||||||||