Slashdot Mirror

The changes seem to be an incremental evolution of the language, not a groundbreaking new language. But if you are a language / tools junkie like me, you owe it to yourself to take a look, even if you're turned off by the rumors of mandated indenting.

Python r2.0 is on its way, coming soon to a [BeOpen] site near you.

Among its other features, as listed in a [What's New] doc, are:

Unicode.
List comprehensions (automagic list looping).
Augmented assignment (+= syntactic sugar).
New string methods.
Improved GC.
Several new functions.
Comprehensive XML libraries.
HTTP1.1 support.
Improved curses support.
SSL support.
A new regular expression parser (Unicode-compatible).
Improved IDE.

And other things you can go [read for yourself].


--

Python r2.0 is on its way, coming soon to a [BeOpen] site near you.

Among its other features, as listed in a [What's New] doc, are:

Unicode.
List comprehensions (automagic list looping).
Augmented assignment (+= syntactic sugar).
New string methods.
Improved GC.
Several new functions.
Comprehensive XML libraries.
HTTP1.1 support.
Improved curses support.
SSL support.
A new regular expression parser (Unicode-compatible).
Improved IDE.

And other things you can go [read for yourself].


--

Python 2.0 (coming soon) has augmented assignment. See here.

For my account, see July 20-22 in my online diary. I agree with Emmett; it was a superb techie conference, though I'd like to see more userspace-related topics.

Zope is usually run as a long-running process that's accessed through either Persistent CGI or FastCGI (though the FastCGI was still unstable when I tried it). A FastCGI module is also available if you just want to run regular CGI scripts a bit faster, and mod_python is available as an Apache module.

Supporting Unicode shouldn't be that big a deal, though there are still things to argue over, and it's slated for 1.6. The current interface is documented in this Unicode proposal; what's described there is mostly already implemented in the 1.6 alpha releases and CVS tree. Outstanding issues still remain: 1) the default encoding to use, 2) a Unicode-aware regex engine (partially there in 1.6a2, with a new version about to hit the CVS tree) and 3) declaring an encoding for Python source files (probably going to be left to 1.7). If you want to see good Unicode support in 1.6, I'd recommend compiling the CVS tree, trying it out on your application, and complaining loudly if you find shortcomings. Experience with an actual application is worth dozens of vague speculations.

The design stage for Python 3000 isn't exactly started at this point :-). Given that uncertainity, I do not expect that any changes introduced by Python 3000 will be so radical that you will need to re-learn Python programming. If you learn Python, you should not have any trouble adjusting to Python 3000.

There are good books and tutorials available for Python. The Python tutorial that comes with the documentation and books like Learning Python and The Quick Python Book are good places to start. They were written before Python 1.6, but there aren't too many changes; certainly not many that will affect teaching materials.

I don't know what will change in Python 3000, but I can tell you a little about what we hope to achieve. We would like to take the opportunity to fix some of the language's warts without being hamstrung by backwards compatibility. I think the language has few warts, though, so there should be few changes. Andrew Kuchling put together a list of language warts that captures the sort of thing we'd like to fix.

The internals of Python 3000 will change a lot, and the C API will surely be different. The internal changes are not going to cause a lot of monkey with the language definition.

The problem with all these wonderful solutions is that they are overkill for the simple problem of putting content in a consistent presentation.

Yup, that's for sure. Here are a few lighter-weight (positively-speaking) python html generating utilities. Maybe they will have some useful ideas/components for you:

1. makepage 0.1.x

   This one sounds the most like what you want/already have (?)

   Abstract:

   Generate HTML files from a formatted input template description files.

   Details:

   makepage.py takes a specially formatted input file and a HTML format file and generates a HTML file from them. It also generates labels and a contents line for all sections of a file at the top of each page to jump directly to a section without scrolling through the file. The default layout file (html_format.py) can be ``overwritten'' partially or completely by a layout file supplied by you.

2. Poor Man's Zope (PMZ)

   This one is probably too lightweight for your purposes, but I don't really know...

   Abstract:

   Is very similar to Active Server Pages or PHP3/4 and allows you to include Python code into your HTML pages.

   Details:

   If you don't need an application server like ZOPE than PMZ should be your choice. In general this is a technology preview. For performance issues it might be necessary to rewrite the code into an Apache web server module for best performance. This piece of software is not thought to be used on a high performance web server with much traffic. However it might be useful in some situations when you need some Python functionalities in your environment.

3. HTMLgen 2.2.2

   This one is probably the heaviest-duty of the ones listed here. May be too much for what you need?...

   WHAT'S IT FOR?

   HTMLgen is a class library for the generation of HTML documents with Python scripts. It's used when you want to create HTML pages containing information which changes from time to time. For example, you might want to have a page which provides an overall system summary of data collected nightly. Or maybe you have a catalog of data and images that you would like formed into a spiffy set of web pages for the world to browse. Python is a great scripting language for these tasks and with HTMLgen it's very straightforward to construct objects which are rendered out into consistently structured web pages. Of course, CGI scripts written in Python can take advantage of these classes as well.

A couple of free or semi-free efforts have been started, but they seem to have lost momentum. I'm still building up the gumption to start a project, but if anyone else is working on it, please drop me a line...

Hmm... time to check on the turkey.

Correct

Sure, we'll have no more Odd Days after today, but we've had so many of them over the course of our lives, I say, so what? I've had my fill. Now the first Even Day in over 1000 years! now that's cool! I bet no-one remembers the last time we had one of those. But I tell you, I feel sorry for our Great Grandchildren born 1 January 2100. They may never experience either an Even or an Odd Day. So sad.

OTOH, in the Coptic Calendar, they won't have another Even Day until 15 October 2283, but there will be another Odd Day on 11 September 2000.
If you are Ethiopic however, you need to wait only until 13 October 2007 for your next Even Day, the next Odd Day being the same as in the Coptic Calendar.
Alas, though if you follow the Islamic Calendar, the next Even Day will not be until 8 February 2562, though there should be a new Odd Day as soon as 1 August 2087.
Persians have it even worse. The next Even Day for them won't be until 22 April 2621, though 20 March 2000 will be another Odd Day for you.
The Bah'a'i will have their next Even Day 10 April 2225, but 21 March 2000 is also an Odd Day.
For those of us following along on the Hebrew Calendar, our next Odd Day will be 5 April 2011, but we will have to wait until 24 April 2240 for our next Even Day.
Ni Hao, because if you are Chinese and follow the cyclical system of 60 years, then Even and Odd days are quite common for any lifetime. Take for instance the next Odd Cycle Day, which will be Chinese New Year next year, 5 February 2000; the next Even Cycle Day will be 24 February 2001. But, if you consider the 60 year cycle has repeated 78 times since the Chinese calendar was established, then the next time the cycle count will be Even is 17 March 2105, and the next time it will be Odd is Chinese New Year 2044, on 30 January. Every other Chinese New Year is an Odd Day, actually.
[You're probably getting pretty sick of this at this point but I shall continue... :) ]
If you are Hindu, your Even and Odd days depend on whether you're using the Old or New Lunar or Solar Calendars. In the modern Lunar Calendar, 27 November 1999 will be an Even Day, but the next Odd Day will not be until 30 April 3054. However in the Old Lunar Calendar, the next Even Day will not be until 3 April 2899, but the next Odd Day will be 14 April 2010. For the Solar Calendar, the next Modern Even Day will be 17 May 2078, but the next Modern Odd Day will occur as soon as 14 April 2009. For the Old Solar Calendar, things are just as bleak as for the Old Lunar One: we will have to wait until 1 June 2899 for another Even Day, but the next Old Odd Day will be 16 April 2010.
Mes amis, je continue en français à célébrer la Révolution. Puis, dans le calendrier de la Révolution, je raconte que nous avons ensuite un Jour Pair le 2nd janvier 2000, mais dois attendre jusqu' à le 23e septembre 2102 à notre Jour Impair prochain. Mais si nous regardons le Calendrier Révolutionnaire Moderne, alors le 1er janvier 2000 sera le Jour Pair suivant, et le 22nd septembre 2102 sera Impair.
[Please consult Babelfish Liberally and for more information about the French Revolution, I suggest consulting the most respected historical source at the next NoVaDWVS meeting, 22 November 1999... <-- Plug.]
Anyway, where would a list of Calendar Dates be without our good friends, the Mayans. Yes, thanks to Reingold and Dershowitz who provided the resources for all this information, I can tell you that the next Long Count Odd Day by one calculation of the Mayan Epoch will be 23 September 2033, and the next Even Day won't be until 13 October 4772!! That's going to be a long wait, but take solice, because if you only regard the Haab and Tzolkin Calendars, then you get many Even and Odd days each year. For instance, then next Haab Even Day will be 27 April 2000, and the next Odd Day will be 3 December 1999. The next Tzolkin Even Day will be Tomorrow, because today is an Odd Day. :)
Of course, if you missed today's Odd Day, not only is Tomorrow another Odd Day but might I recommend getting Rustic and celebrating it on 2 December 1999, when it occurs its last time for 1000 years in the Old Julian Calendar, or wait until 15 February 2000 for the next Julan Even Day. Of course, if you're an Astronomer, then you're only concerned about the Julian Day Number. Fortunately, the next Julian Even Day Number will be 24 February 2023, but the next Odd Julian Day Number won't be until 31 October 3805!
But none of this is ISO Standard, so therefore, I suggest that the next ISO Even Day will be Tuesday 4 January 2000, and the next ISO Odd Day will be Monday 20 December 1999. Alas, the last one for the next 1000 years will none the less be 26 December 1999.
Of course, since most of us are programmers, let me suggest that ANSI C dictates the next Even Moment will be 10 January 2004 at 13:37:04 GMT in Hexidecimal and 4 May 2000 at 06:56:33 GMT will be our next Odd Moment. Finally, this one is for those suckers that still use the OS of a certain company that may be about to be split in half: The next OLE Even Day will be 6 July 2009 at midnight GMT and the next Odd Day will be 8 August 2001 at 2:40:00 GMT.

And now you know the rest of the story...

Be Seeing You,

Jeffrey.

There is an online Python/Perl phrasebook if you want to compare the two languages in action. A lot of the information is based on Tom Christiansen's Perl Data Structures Cookbook, as well as help from the two languages' respective creators, Larry Wall and Guido van Rossum. It shows how you'd accomplish a wide array of pretty common tasks in each languages. It's ample fodder for clear-headed analysis of all-out flameage...it's your pick.

I'll have to agree with the site's author: Python wins for readability, approach to OOP, the blessed absence of $, @ and % characters in front of variables (never liked 'em in Basic) and the homage to a great comedy act (and the convention of using "eggs" and "spam" instead of "foo" and "bar" in code examples). Perl wins for its better handling of regular expressions, quoting and having lots of people who know it. They're quite similar and becoming more so, especially since the re module in Python has been changed to be quite similar to Perl's regular expression functions. Performance is pretty close.

It may boil down to the language the alpha geek prefers or the project already uses, if you drain religion from the argument...but what fun would that be?

Well, there was also exactly one Python/C++ entry (mine :-), and it didn't do too bad. Don't forget that developpement speed matter, as much as speed, and this is where Python, Perl, Lisp, Smalltalk shine, and Caml, and functional languages shine a bit less. For instance I coded the core move generation in C++, and interfaced painlessly it with Python: I had a huge performance penalty, but on the other hand I was able to implement alpha-beta and iterative deepening with move pre-sorting, which I wouldn't have time to write (and debug!) en C++. The result is that my slow but somewhat clever entry has beaten brute force C entries.

im sure ill be using c, but if i get to the last 2 hours and dont have anythign to submit yet, then ill just write a simple little perl script to get the job done.

But the problem probably won't be solved by a perl script written in two hours. More, in the pousse contest it would have been very useful, to have a first prototype to play with, to understand how the game should be played. If the problem has something fuzzy what requires good heuristics, then speed isn't important alone.