Slashdot Mirror

My kids use Linux. But sadly, even under Linux, there's no dead-easy kid-friendly way for them to learn programming the way I learned BASIC on my TRS-80 CoCo.

http://docs.python.org/library/turtle.html :-)

..., and Python recommends the use of tabs.

PEP 8 (the Python style guide) disagrees...

For new projects, spaces-only are strongly recommended over tabs. Most editors have features that make this easy to do.

Python is a very good suggestion. Be sure to check out the turtle module (included in the Python standard library), it's quite nice and inspired by Logo.

Also, Python 3.1 is slightly simpler and easier to understand for a beginner that the old Python 2.x.

Python is multiplatform and is free. There are quite a few free tools and libraries available. It is a 'real' language that is at the same time suitable for youngsters to learn on. With the huge Python ecosystem that exists you can have them cranking out code in a text editor, an interpreter or a full blown IDE. (A wide number of them in fact). Python also makes for a nice bridge to C as it pretty easy to integrate the two. If you feel competent, you could probably just hit the Python docs and work your way through them. If you'd like a little help and have material already prepared for teaching younger people how to program with Python, there are resources out there.
 
I recommend Hello World! which uses Python. (You can read my full review of it here.)
 
If you don't want to buy a book, then you may want to look at Invent Your Own Computer Games with Python 2nd ed. I haven't read it myself yet, and a quick glance showed it to have some rough edges, but one can't be too picky at that price. It is available to download or read online.

The floating point representation issue could be resolved the same way it is handled in Python 3.1 by using the shortest decimal representation that is rounded to the exact same binary floating fraction.

With this solution 1.1 + 2.2 will show as 3.3 (it doesn't now) but it will not test as equal to 3.3. It's not as complete a solution as using IEEE 754r but it handles the most commonly reported problem - the display of floating point numbers.

See What's New In Python 3.1 and search for "shortest".

Global variables, lack of namespaces and block scopes are nuances that can be worked around with proper coding practices and a good understanding of the language.

Why would you go through all this work when there are languages that provide all of this and much more and are as flexible a JavaScript?

You know, F/OSS is more than GNOME. There is a lot of innovation going on in the F/OSS universe. It has always been this way and I'm willing to bet it will always be that way. That you don't see it says more about you than about the F/OSS universe.

And yes, F/OSS projects copy things from proprietary software, too. And this is a Good Thing. After all, one of the most heard complaints about F/OSS is that it doesn't have whatever it is the complainer wants to have that they do have with their proprietary software of choice. Well, the likes of OpenOffice.org, KDE, GNOME, and many others cater to those wishes.

If you want something original and open source, there are numerous examples. Many features of modern Unix were pioneered in the open-source BSD, many others are pioneered in Linux (e.g. several filesystems), the TeX typesetting system was a real innovation, the open source Apache is the world's leading web server, the Python programming language is open source and certainly innovative; and that's just a few examples.

I'm guessing the exception handling in python is more expensive than finding the length of your ArrayList-like object and responding accordingly.

In Python, exceptions are cheap enough that programmers find it easier to ask forgiveness than permission in many cases. Even iterators end by throwing Python's equivalent of a j.u.NoSuchElementException within next() instead of returning False on some sort of hasNext(). Besides, exceptions reduce time of check to time of use to zero, unlike branching based on length and finding that another thread holding a reference to the same list has removed elements from the list behind your back.

You don't even get a Perl or Python interpreter preinstalled in Windows; how backward can you get?

What place does Perl and Python have in the default install of an OS?

Python comes pre-installed on Mac OS X, but due to Apple's release cycle, it's often one or even two years old. The overwhelming recommendation of the "MacPython" community is to upgrade your Python by downloading and installing a newer version from the Python standard release page. Python on the Mac

If you are running a Linux system (or most UNIX systems, including Mac OS X), you probably already have an installation of perl. Type perl -v at the command line to find out which version. Get Perl

A 100% Open Source Perl for Windows that is exactly the same
as Perl everywhere else. And now it's rebuilt from scratch! We've partnered with Microsoft to improve CPAN on Win32. Our new WiX-based MSI installer enables Active Directory Group Policy installation across your entire organisation. New bundled support for the world's most popular Open Source database MySQL, plus SQLite and ODBC clients. And some little things, like installer clash detection logic, a cleaner uninstall, and Perl upgrade support. Strawberry Perl For Windows

Maybe the way it was written is why FOSS is where it's at? Might not be such a bad idea to keep it around?

Then again, maybe the GPL is not responsible for great free software and open source software being written.

Don't get me wrong, I think developers should be allowed to pick their license of choice, including GPL. But there are plenty of examples of free software and open source software being highly successful and widely used that are not GPL'd.

The assumption that the GPL is responsible for the success of FOSS reminds me of a Simpsons episode where Homer is carrying a rock around that supposedly repels lions (or something). Lisa says, "That's ridiculous! What makes you think that repels lions?" and Homer replies, "You don't see any lions around, do you?"

I believe that the publicity surrounding GPL and the way it forces developers who use code licensed under it was a major factor in the expansion and acceptance of open source software. That doesn't mean that those other licenses aren't just as valuable to the ongoing health of and expansion of open source software. It just means that GPL created the mindspace to allow non-geeks to view open source as something more than a fringe element.

Maybe the way it was written is why FOSS is where it's at? Might not be such a bad idea to keep it around?

Then again, maybe the GPL is not responsible for great free software and open source software being written.

Don't get me wrong, I think developers should be allowed to pick their license of choice, including GPL. But there are plenty of examples of free software and open source software being highly successful and widely used that are not GPL'd.

The assumption that the GPL is responsible for the success of FOSS reminds me of a Simpsons episode where Homer is carrying a rock around that supposedly repels lions (or something). Lisa says, "That's ridiculous! What makes you think that repels lions?" and Homer replies, "You don't see any lions around, do you?"

• Under Windows: Install Python from Python.org; IDLE comes inside.
• Under Ubuntu: sudo apt-get install idle
• Under Xandros, the Linux distro that comes on some Eee PC notebooks, you might want to do what I did a week after I bought mine: Wipe the drive, install Ubuntu, and follow the Ubuntu instructions.

my @months = qw( January February March April May June July August September October November December );

How about:

months = "January February March April May June July August September October November December".split()

Python's full grammar specification fits on two pages of A4.

Here's a great rule of thumb I use. Let's say you're writing a function to do some bit of functionality. Typically you're going to write that code, and then put together some code to check it out real quick before you proceed with the rest of your application. Usually, the cheesy little try-it-out code gets thrown away. Whenever you catch yourself starting to write a little piece of outside code to just check sanity check your method, instead write a unit test for it, and stick that unit test into the comments. I love to use doctest for this in Python, and I imagine there is some analog to it in Ruby.

A lot of people go through the trouble of writing simple little testy code to make sure stuff works, without going through the trouble of saving that code. It takes a little effort to set yourself up so that code can be saved for posterity. But if you do it early, it really doesn't add much to the effort at all. And it makes it much easier to make changes later to the code and to do so with confidence.

I realize you're joking, but here's a list of organizations that make serious use of Python:

http://wiki.python.org/moin/OrganizationsUsingPython

I don't know if a list like this is being maintained for Ruby, but where I work, most of our internal business web apps, and some of our external apps, are done in ruby. Metasploit, a major app I and many others rely on for security testing, is written entirely in ruby. The folks at Engine Yard (http://www.engineyard.com/) also do serious web app hosting entirely in jruby.

One of the founding principles of Python is 'There should be one-- and preferably only one --obvious way to do it.'

http://www.python.org/dev/peps/pep-0020/

The python language (circa 2.4) wasn't *flexable*, it was rigid while still being easy to use. As a result, python code written by your average script monkey is more readable.

This seems outdated: map is a method as of 2.6, and you wouldn't use map anyway since comprehensions are preferred.

No, it's not "outdated". Using the keyword is the "officially" recommended way of using map.

http://docs.python.org/tutorial/datastructures.html#functional-programming-tools

As nice as list comprehensions are, they're a bad method of chaining functions, because it is achieved by nesting, at the syntactic level. Something like:

[ (lambda x: x) for x in [ (lambda y: y) for y in list] ]

If I want to apply another function, I get to move that whole list construct into a new one. Or rewrite, but that defeats the purpose of using powerful and expressive tools. We already saw what that would look like if Python was awesome:

list.map(lambda x: x).map(lambda y: y)

Functor composition is expressed by simple concatenation. That's much easier to read, write, and maintain.

The last complaint could be mitigated by writing a regular function, too.

Brilliant. Let's break encapsulation for every single utility function a model might use.

Google is doing "Unladen Swallow", which is an attempt to bolt CPython to a just-in-time compiler to a virtual machine.

It's cute that Python to JavaScript translation is possible, but it's not going to help much on the performance front.

thanks for posting this - it's interesting to see peoples' insights.

i'm aware of the unladen/swallow effort: they're replacing the FORTH-based bytecode engine with LLVM JIT compilation.

on their roadmap is "unboxing" of the http://python.org/ c code types (Object/longobject.c, Object/intobject.c, Object/stringobject.c etc.)

basically the plan is (i believe!) to provide reimplementations of intobject.c's __add__, __mul__ etc. to call LLVM routines instead of straight c code. in this way, they intend to keep python "c code" module interoperability, as long as you replace the libpython2.6.so with an unladen/swallow one.

_as long as_ the speed was still there, i would like, at some point to do the same trick - but with Google V8 javascript engine, instead (and, for fits and giggles, throw in spidermonkey as an option as well). basically, the implementation of intobject.c's __int__ would have a pointer to a javascript object, in which there would be an __int__ function; a call in python from a standard python c-based module to create an int would result in the creation of a javascript object representing the integer, and the intobject.c code would simply "look after it". in this way, you would have interoperability between python that was converted to javascript, and python c-based modules.

the thing is: the performance of the pyjamas LoopTest was a bit lower than i was expecting, so i double-checked things, especially that the original experiment showed conversion of python to javascript executed under V8 having a whopping 10x performance increase (over standard python).

pyv8run running the fibonacci algorithm, it's confirmed: when you set -O (optimisation mode in pyjamas) we have a 2.5x performance INCREASE over standard python, WITHOUT having made any special effort or analysed what is going on and without having profiled things to find out if it can be done any better.

also confirmed: when you switch on "--strict", the object-accessing test comes down to 10% the performance of python, which is truly dreadful, but hey, it's "safe", what do you expect? :)

also confirmed: a simple object-accessing test is 50% (HALF) the performance of python - again, with no investigation as to why that is.

there are a ton of different ways, now: i've been maintaining a list on the python wiki, WebBrowserProgramming page. pypy used to have a -to-javascript back-end (now abandoned); there's titanium appcelerator (which supports IronRuby and IronPython); there's PyXPCOMExt and a few more besides.

This is a reflection of the fact that TeX is now very stable, and only minor updates are anticipated.

The Python team should follow this philosophy, what I have seen of Python 3 fill me with WTF.

Get rid of the string formatting standard that everyone uses? WTF? What good is that, it only makes it harder to migrate from C. Get rid of functions like system and popen, replaced by a Popen function which needs six or seven arguments? Get rid of tuple arguments in functions? Get rid of functions that return lists? WTF? Where has the simplicity and ease of use gone?

Why get rid of so many useful features, just for the sake of some computer "scientists" who, very obviously, have never done any professional programming? "The net result of the 3.0 generalizations is that Python 3.0 runs the pystone benchmark around 10% slower than Python 2.5." .

I wish Guido van Rossum took a hint from Donald Ervin Knuth (a guy whose name is an anagram for "hunt, drink, and love" cannot be all bad...) and TeX and would create a traditional Python with all the excellent features the language had until version 2.5. My suggestion: call it version 2.718281828459045...

I can't code is my excuse! Don't go messing that up for me! I have a good thing going.

Muahahaha....we have ways of teaching you to code!

in Python, http://docs.python.org/library/turtle.html, which is a much nicer first language than basic, .... or java

the GP should be noted funny, not insightful

A major fault that I've seen in numerous sub-threads is the idea that a Java user interface equals Swing. It most certainly does not. Swing is merely Java's complete pure-Java (i.e. cross-platform) user interface geared towards providing a unified look-and-feel. In this respect, it does a good job. While there's nothing inherently wrong with it from a toolkit perspective, it is absolutely not appropriate for usage on the Linux desktop.

Programming for the Linux desktop means more than producing a windowed application; one must integrate their application, both in terms of user interface consistency and application interoperabililty, with a major desktop distribution. Specifically, I'm talking about Linux's "big two" desktop environments, KDE + Qt and GNOME + GTK+. While each of these environments have their preferred languages (C++ and C respectively), many other languages have no issues whatsoever being tightly integrated into them via bindings.

Java is no exception! In Java, I can program a wonderful GNOME/GTK+ application just fine with java-gnome. Similarly, I can program a Qt4 application with Qt Jambi (although I can't seem to find an equivalent KDE4 bindings library) in Java. An application written in either will appear and operate on par with any application written in other languages, either natively (via C or C++) or via another bindings library (Python has a ton of bindings).

Furthermore, just like GTK+ and Qt have cross-platform capability, so do the bindings, and if the appropriate binding library for a given platform is installed on that platform, the Java application, too, will be able to be cross-platform without modification. This is, of course, the job of the distribution and/or installer software, but operates similar to the Deluge (Python) installer for Windows, installing the client port of the toolkit (GTK+, in this case) and the language bindings (PyGTK) alongside the application.

That's exactly how the Mono desktop applications work: they write their logic in native C# and use GTK+ bindings (GTK#, in most cases) to integrate with the Linux desktop environment.

Any Java application written for the Linux desktop that uses Swing over native desktop bindings is foolish. Each has their place, for sure, but on the desktop integration is everything.

A major fault that I've seen in numerous sub-threads is the idea that a Java user interface equals Swing. It most certainly does not. Swing is merely Java's complete pure-Java (i.e. cross-platform) user interface geared towards providing a unified look-and-feel. In this respect, it does a good job. While there's nothing inherently wrong with it from a toolkit perspective, it is absolutely not appropriate for usage on the Linux desktop.

Programming for the Linux desktop means more than producing a windowed application; one must integrate their application, both in terms of user interface consistency and application interoperabililty, with a major desktop distribution. Specifically, I'm talking about Linux's "big two" desktop environments, KDE + Qt and GNOME + GTK+. While each of these environments have their preferred languages (C++ and C respectively), many other languages have no issues whatsoever being tightly integrated into them via bindings.

Java is no exception! In Java, I can program a wonderful GNOME/GTK+ application just fine with java-gnome. Similarly, I can program a Qt4 application with Qt Jambi (although I can't seem to find an equivalent KDE4 bindings library) in Java. An application written in either will appear and operate on par with any application written in other languages, either natively (via C or C++) or via another bindings library (Python has a ton of bindings).

Furthermore, just like GTK+ and Qt have cross-platform capability, so do the bindings, and if the appropriate binding library for a given platform is installed on that platform, the Java application, too, will be able to be cross-platform without modification. This is, of course, the job of the distribution and/or installer software, but operates similar to the Deluge (Python) installer for Windows, installing the client port of the toolkit (GTK+, in this case) and the language bindings (PyGTK) alongside the application.

That's exactly how the Mono desktop applications work: they write their logic in native C# and use GTK+ bindings (GTK#, in most cases) to integrate with the Linux desktop environment.

Any Java application written for the Linux desktop that uses Swing over native desktop bindings is foolish. Each has their place, for sure, but on the desktop integration is everything.

Python still lacks many of Matlab's features, its only advantage is being Free Software.

You sound like you have never tried out SciPy, which has many of Matlab's features, and is written in C for blazing speed.

Yes, Python is Free. It's also easier to work with than Matlab. I love Python and hate Matlab.

BTW, a very ill-advised design choice of Python: http://www.python.org/dev/peps/pep-0211/ Ask any numerical analyst to know why it is a terrible idea to solve a linear system with inv(A)*b. But make sure you have at least half an hour free.

Damn, man, what the hell is your problem? You take a proposal from nine years ago, a proposal that was not accepted, and you call it out as "a very ill-advised design choice"? Anyone can propose anything. I could propose that Python add a "MAGIC" operator that would randomly screw up all your matrices. That wouldn't be accepted either. Would you then criticise Python because of my stupid insane proposal? Get a grip.

Well, it doesn't sound like we really disagree very much. Python is a different tool than Java, so they don't generally compete head-to-head in my experience.

True, my requiring Python for my department doesn't cause it to be much more prevalent in jobs across the globe. On the same note, your not having seen them doesn't make them less common.

Still, I'm being objective when I say there's lots and lots of python jobs out there. Here's an example of a few dozen (hundreds? I didn't count them) Python job listings from just one site:

http://www.python.org/community/jobs/

I'm not saying that there's not lots of Java jobs too, because there obviously are. And I'm not claiming that there are more or less of one or the other, because I have no idea what the ratio is.

On the "quick programming" note, I'm surprised you state you don't understand it and then give an example of how you use Python (not Java) for a calculator (an example of "quick programming")! That's exactly what I'm talking about. The ability to fire up the interpreter and instantly be in business, without ever creating a file, a class, or anything. I'll often want to crunch some data quick and dirty, or do some parsing that's a little too complex for command-line tools, and I can do it by just firing up a Python interpreter and having at it. My comment about Java was really just to reflect that (as far as I know--I'm no Java guru), no one fires up a Java interpreter and starts making stuff happen right then and there without at least creating and compiling a file.

You can also make fairly sophisticated command-line utilities with very few lines in Python, which I was also thinking about as quick programming.

BTW, a very ill-advised design choice of Python: http://www.python.org/dev/peps/pep-0211/

Only... it never happened. So your point (if there was any) is moot. Not arguing against the rest of your rant - but bashing a language for a poor design choice that was never happened seems a bit silly.

BTW, a very ill-advised design choice of Python: http://www.python.org/dev/peps/pep-0211/ [python.org] Ask any numerical analyst to know why it is a terrible idea to solve a linear system with inv(A)*b. But make sure you have at least half an hour free.

AFAIK PEP 211 and the related PEP 209 were never actually accepted into the language. Python users that want multidimensional arrays use the numpy package, along with the scipy package that builds on top of numpy.

For solving a linear system Ax=b, you just use

x = numpy.linalg.solve(A, b)

which calls LAPACK behind the scenes. For a simple matrix multiplication (or M-V or V-V depending on the dimensionality of the arrays) A*B=C you do

C = numpy.dot(A, B)

which is implemented with a call to BLAS.

BTW, a very ill-advised design choice of Python: http://www.python.org/dev/peps/pep-0211/ Ask any numerical analyst to know why it is a terrible idea to solve a linear system with inv(A)*b. But make sure you have at least half an hour free.

To make a long story short; solving Ax=b by calculating x=inv(A)*b is a terrible idea because calculating inv(A) is an inherently difficult thing. While it would be extremely useful to have inv(A), it's not strictly neccessary to obtain in in order to solve Ax=b.

At the most basic level, the technique which most would be aware of to solve Ax=b is basic Gauss Elimination, with an augmented matrix and back substitution. In fact, this is often the very first thing people learn how to do in a linear algebra course. It isn't much better than finding the inverse, but it saves a lot of computation in the long run.

Of course there are many other techniques. Happily however, most packages can now automatically make the best choice on which technique to use, depending on the properties of A. In Matlab and Octave, it all boils down to using the left division operator like so
x=A\b
instead of the inverse calculating
x=inv(A)*b

Using the first command, Matlab and Octave will choose a technique that best suits the matrix A. This page has a list of all the techniques that Matlab can use to solve the linear system. To my knowledge, Octave has a number of techniques as well, but I'm not sure if it's as comprehensive as Matlab. Also, Octave's left division operator has been known to have bugs.

And to return to the main topic, Octave and Matlab both use LAPACK extensively, which is written completely in Fortran(and based on BLAS). There's really no other language for linear algebra.

Citation needed. Even if not phython, what does Fortran have over modern compiled languages, for example?

0) A lot of legacy code people still have to work with is written in FORTRAN. Sad but true.
1) Many very optimized libraries available. Check if your language du jour has an implementation of a routine for solving a linear system using BLAS. That provides a huge improvement.
2) Many libraries are in fact only available for FORTRAN. For calculating the eigenvalues of a sparse matrix, there is only ARPACK (for Fortran), Arpack++ (a kludgy C++ interface to the very same FORTRAN library), and Matlab's "eigs" (a Visual Basic-style interface to the very same FORTRAN library).
3) Very expressive. For instance, you can reverse the entries of a vector of complex numbers in a single compiler instruction. This is a toy example, but for more complicate stuff this expressiveness pays: the compiler has an easier job in understanding what code can be safely optimized and what cannot. More complicate stuff involving e.g. C++ method calls suffers in terms of pointer aliasing problems and similar stuff. Of course you may write the very same thing in C or machine code, but for 99% of the computations you would use the "standard" interface to vectors/arrays of your languages and forget about this sort of micro-optimizations. A good commercial FORTRAN compiler (forget about gfortran, sorry GNU but sadly it's true) does this automatically.
4) FORTRAN 95 is not a punch-card language anymore, it has most of the fancy modern stuff if you wish to use it. While "bad programmers can write FORTRAN in every language", good programmers can write well-factored and perfectly readable FORTRAN code.

Nevertheless, I do matrix computations, and still I try to avoid it as much as I can. Most people in our field use MATLAB (which is essentially a Visual Basic-style interface to most of the awesome number-crunching FORTRAN libraries) even though for tight "for" loops its performance sucks. If performance is mission-critical, you may write FORTRAN subroutines and call them from MATLAB, and that's very convenient. Python still lacks many of Matlab's features, its only advantage is being Free Software.

BTW, a very ill-advised design choice of Python: http://www.python.org/dev/peps/pep-0211/ Ask any numerical analyst to know why it is a terrible idea to solve a linear system with inv(A)*b. But make sure you have at least half an hour free.

The book is about Python so it probably isn't that out of place that there is reasonable support for csv files included in the standard install:

http://docs.python.org/library/csv.html

No support for Unicode (yet) would probably be the biggest caveat. I've had good luck with it, but I haven't exercised it in particularly interesting ways.

Or you can use a general purpose language and be done with it.

Python has its uses, but it also has its overhead. Good luck getting any kind of performance with pure Python code on a handheld device with 4 MB of RAM and a 67 MHz CPU. Or good luck getting a good frame rate with a graphics engine that uses PyOpenGL. (And why is the snake wrapping itself around EA Games' old box-ball-cone logo?)

Or you can use a general purpose language and be done with it.

Google is providing a standardized UI on top of Linux

Then let the better UI win. Will it be one that's Java-only, or one that can be used in its native C++ environment or with Python, Ruby, or even Java?

Symbian is dead.

Even if it were true, and with about half of the smartphones in the world running Symbian I don't think it is, what has that to do with Qt?

there is very little need for a specialized UI toolkit like Qt now that there are both fewer platforms for it to run

Huh? There are more platforms than ever for Qt to run. Do you mean Microsoft isn't delivering operating systems anymore?

It looks like Python + Pyro will get you Erlang-like functionality, and then some - including remote execution.

My 2c, this review is entirely the norm for the rails community.

This is a community of 'developers' who spend (so far as I can tell) the vast majority of their time coming up with names (rails, merb, cucumber, etc) and writing blog posts (yes, I get the irony of pointing at *his* blog) about how badass they think are, while writing trivial libraries and using that to trumpet how 1337 they they think they are. Both this review and likely this book should be passed up, along with the rails community as a whole.

*Clue*, when looking for a development community, look for a group of people who spend time *coding* at their conventions instead of a development community who spends the vast majority of their time grandstanding about how awesome they thing they are.

1. Download and install Python 2.6.1: http://www.python.org/ftp/python/2.6.1/python-2.6.1.msi
2. Download Impacket from http://oss.coresecurity.com/repo/Impacket-stable.zip (or maybe http://pypi.zestsoftware.nl/impacket/ or some other mirror)
3. Download the scanner from http://iv.cs.uni-bonn.de/uploads/media/scs.zip
4. Unpack Impacket into a folder, then install Impacket from a command line with c:\python26\python setup.py install
5. Run the scanner with the command c:\python26\python scs.py [start_ip] [end_ip]

(Hat tip to an AC comment at El Reg). Just a warning - it runs like a dog. I found that a passive Honeypot like Honeybot works well and is easier to install.

Out of curiosity, I checked how Python handles fsync() stuff - turns out that it's the same as in C.

I never heard about this and often coded with the assumption that a flush() writes to disk, but I was wrong.

Now can we please acquire (NSFW): python.com and redirect it to (SFW): python.org?

-metric

While I'm happy to see that libapache2-mod-python at last supports python2.5, I'm very dissapointed that debian developers didn't include python2.6. Do we have to wait another 22 months for it?

If the debian folks think that python2.6 could cause problems they are free not to make it the *default* python. But not including it at all is insulting for the python development team. Most important, since python2.6 is considered a stepping stone to python3, it is also very inconvenient for those who want to start migrating their code to python3.

Python uses UTF-16 internally on Windows and UTF-32 on Unix (I think "UCS-4" implies that values greater than 0x10ffff are allowed, but Pythons converters to UTF-16 and UTF-8 do not handle this, so it is better to say it supports UTF-32).

Python uses UCS-2 or UCS-4 internally but sys.maxunicode maxes out at 0x1114111 on UCS-4 builds because there aren't any defined characters that high. Read Include/unicodeobject.h in Python's source code to see for yourself.

I believe that if they had used UTF-8 from the start none of this crap would be happening.

Storing unicode strings internally as UTF-8 is madness. Imagine the trivial case of s[3], which bytes would we return? We'd have to walk the string to find the start of that fourth character, then walk it some more to get the whole thing. It'd transform a whole pile of O(1) operations into O(n) ones, and performance would suffer greatly for it.

Now, I'm not familiar with Python but I'd say you're trolling. Then again, your complete post is content-free except for some handwaving about "deep knowledge" and "cursory familiarity".

Take a look at Python's simple print statement and tell me with a straight face that it's an OO method instead of a parser feature. Contrast this with Ruby's Kernel#print statement, which is treated as a simple member function call instead of a language construct.

The fact that method calls (assert, print and del) are included in the language syntax, means that Python is not (yet) fully OO.

I've been using Roundup Tracker http://roundup.sourceforge.net/ at work for a while, and it's been a great experience. Stable, fast, and very easy to mod/customize to your own needs or preferences (it's written in python).

An live example of the web interface of a roundup tracker can be seen online at http://bugs.python.org/

I fail to find any reference for the delimiter-based argument for making print a function (I looked for reasons for a print function here, and that PEP has some references too). Note that they didn't just add brackets, they actually changed print's semantics from being a statement to being a function.

I am sorry about the C thing -- I suppose I meant C-like languages as I hear this argument from users of such languages the most.

As for "pushing it [significant whitespace] so forcefully", I think you will find that most of the "python fanbois" are just saying that they tried it and it works, while the delimiter guys are far more belligerent about the stupidness of not having delimiters.

Your short example tripped me up, but >>> "User ID: {uid} Last seen: {last_login}".format( ... uid="root", ... last_login = "5 Mar 2008 07:20") is very readable. Even though I think that "format" is a poor choice for the method name because you're doing more than string formatting, don't you?

Guido made a major fuck up there- by removing braces but not strictly defining whitespace

Stop. First, the whitespace rule in Python *is* strictly defined.

The formal, exact, unambiguous specification of how Python interprets whitespace is in the official language reference - Lexical analysis.

It's pretty wordy, but I've studied it and it's quite precise. The relevant section is here:

"Firstly, tabs are replaced (from left to right) by one to eight spaces such that the total number of characters up to and including the replacement is a multiple of eight"

This is exactly the same as the default behaviour of Unix `expand`.

[Guido has] created a language where it's possible to have two identical looking pieces of code do very different things.

It depends what you mean by "looking". To you, perhaps 1 tab looks the same as 4 spaces. To me, maybe it looks the same as 2 spaces. To Jeff, maybe it looks like a red dot in his specially-configured editor. To Python, it happens to look the same as 8 spaces.

DO NOT MIX TABS AND SPACES. Then, I guarantee you that any two pieces of code which look the same to you (whether they use tabs or spaces) will also look the same to Python. (You don't have to enforce this across a whole file, just on a per-block basis, but it's best if your whole project has an agreed indentation standard).

If he had said that it must be indented by exactly 1 tab or exactly 4 spaces or whatever other measure and everything else would throw a syntax error.

That's silly. Then you'd be at Guido's whim; you'd have to indent the way he chose. This way, you can choose any indentation you like. Tabs, 2 spaces, 4 spaces, 3 tabs if you like. As long as you are internally-consistent, Python will be happy.

My second point to you: If you are pasting code from somewhere into your code, and you do not fix up indentation so it matches the surrounding code, you are worse than Hitler. Or at least very lazy. I don't care if you are using Python or C or Brainfuck.

If you carelessly paste 1-tab-indented code into a surrounding block which is 4-tab-indented, and don't fix it up, then how do you think I will feel when I open it in my editor configured to expand tabs to 2 spaces instead. It will be totally unreadable -- and this is why we indent in the first place (in any language, that is).

Python forces you to tidy this up, and that can only be a good thing. If your code is confusing Python, it's probably confusing a bunch of other readers as well.

There is a standard

Of course the list would be pretty long (good thing I don't have to list it), and of course Unicode is very significant, but I think there are other things just as significant if not more. Example: everything's an iterator now, not just a list.

BTW, Python 2.x has all the unicode support you need to write a correct application. You just have to use u'unicode strings' instead of 'strings' in a lot more places. Python 3.0 has just switched the default, which will make it easier for application developers to get it right. And that's VERY important. In both versions you have to think about encodings.

My prediction is about 18 months before Python 3.0 is considered the default. My team, in general a pretty early adopter of technology, won't be using it for at least 9 months, waiting for our dependency stack to fill in.

My fulltext search library, Hypy, on the other hand, should have Python 3.0 support any day now.

For those interested, IBM is running a primer series on the new language/runtime features.

There's also this older (but still relevant) PEP that explains things that did not change between the 2.x series and 3.0.

Personally, I'm not looking forward to migrating existing code bases (especially non-trivial ones) to 3.0, but I'm planning to do all new development against it (of course assuming that the various packages I use have ports).

For Python trivia lovers, here the the actual moment in time when 3.0 was let loose on the world. I'm such a sentimental geek :)

R handles non-matrix data structures much, much better than Matlab does

This advantage is even larger for Python. Use the NumPy package for efficient array handling and basic linear algebra. Use SciPy for optimization and statistics. Use Matplotlib for amazingly powerful 2d graphics. And if you occasionally need R, which does have an wonderfully deep statistical library, you can access it with rpy.