LWN: Comments on "Moving to Python 3"

Moving to Python 3 (I Feel Sorry)

foom — Sun, 13 Mar 2011 23:45:56 +0000

I assume your comment was a joke? Cause Ruby has been incompatibly changing way more than Python...

Moving to Python 3 (I Feel Sorry)

litosteel — Sun, 13 Mar 2011 17:22:52 +0000

why don't you move on to Ruby. And let the fun begins.
I'm really sorry by the Python, Perl and other lang's people.
If a languages changes from version X to version Y, may is not a language, but a joke...
(sorry for the flames, but can't stop my feelings)

Avoid Version Numbers

bluss — Tue, 08 Mar 2011 22:55:56 +0000

Ironically, __builtins__ is officially an implementation detail of CPython. Recommended way to find the module containing the built-in functions on Python2 is: import __builtin__; on Python 3: import builtins.

2.x features and improvements

pboddie — Mon, 21 Feb 2011 23:26:25 +0000

But, at this point, there have been 3 releases of 3.x made now, and 2.x isn't being developed anymore. So, if you want any new features ever, you either have to pick up maintenance of 2.x, or switch to 3.x.

However, most of the implementations apart from CPython work with 2.x features, and although there have been noises amongst some of them about 3.x support being a possibility, the priorities of their developers would appear to be the development of other kinds of features than language features. So, for example, PyPy would seem to be sticking with 2.x support and concentrating on performance - it's already faster than CPython for some things and getting faster - so if you value those kinds of features over the language tidying that 3.x represents, then you're not going to switch to 3.x.

But then again, neither are the implementation developers, so 2.x is still a very safe bet.

Moving to Python 3

valhalla — Fri, 18 Feb 2011 21:03:56 +0000

Or you could use distutils / distribute, and then shebangs are taken care of at installation time.

Most PKGBUILD for said distribution just run python2 setup.py and everything works.

Quite frankly

foom — Thu, 17 Feb 2011 21:17:54 +0000

I attempted to ask the "are you really sure?" question a few different times during the development of 3.0, but obviously the answer was "yes!" every time.

But, at this point, there have been 3 releases of 3.x made now, and 2.x isn't being developed anymore. So, if you want any new features ever, you either have to pick up maintenance of 2.x, or switch to 3.x.

I wouldn't say it's impossible to conceive of the first alternative happening, but I'm certainly not interested in doing that, even though I'd really prefer if 3.x just magically ceased to exist. In another 2-3 years when 3.2 is installed ubiquitously alongside 2.x, maybe I'll even start writing python3 code. Stranger things could happen. :)

Moving to Python 3

kleptog — Thu, 17 Feb 2011 20:50:05 +0000

I think you misread my post: I have a fixed number of FDs and a fixed number of threads. Each FD has a completely different purpose and protocol and so an event loop is not really practical. You have to get several different components of the system (which don't know of each other's existence) to work through a single event loop. Sure it's possible, but threads are a nice way to isolate them.

Of course in the general case you are right, a service like a webserver should try to reduce the number of threads. But also in the special case of CPython it's pointless to use more threads, since the GIL prevents more than one thread running at a time anyway.

Quite frankly

NikLi — Thu, 17 Feb 2011 19:51:14 +0000

i don't see any new features in Python 3 that would make me want to switch.

I mean, "why?". And then there is a certain pressure to make the switch and show to the world that Python3 was a huge success, unlike the "perl6 fiasco", and then show the success of the python development model, PEPs, BDFL, etc. This seems like burning bridges as in "if we go back to python2, we will be like those perl6 people we've been making fun of".

The techinal differences are minimal and many of them in the domain of "nits".

I find arguments that say that "in the future there will be only Python3" misleading. There are many firms that use python extensively for their services and THEY WON'T SWITCH ANY TIME SOON. Count google as one of them, and i bet you they haven't got the least interest to rewrite their infrastructure to python3 because "dict.keys is an iterator", etc.

And, last but not least, YOU DON'T BREAK "Hello World".

Quite frankly in education i'd rather teach my students Python2, so they'll go work for google or something...

Moving to Python 3

foom — Thu, 17 Feb 2011 14:27:10 +0000

+1000 to the sentiment. Decoding bytes to codepoints is a total waste of time, almost always, and just adds unnecessary complication to the system.

However, as I said in http://lwn.net/Articles/426906/ python3 *does* do non-lossy decoding/encoding for filenames with random bytes in them.

Moving to Python 3

rqosa — Thu, 17 Feb 2011 08:41:14 +0000

> at least one thread per FD

Forgot to mention this in my previous post: the "one thread/process per FD" pattern is the main design issue that made possible the Slowloris DoS attack, which LWN covered 2 years ago.

Moving to Python 3

rqosa — Thu, 17 Feb 2011 08:26:36 +0000

That way can scale poorly, because there must be at least one thread per FD.

Using an epoll-driven main loop and a pool of worker threads (with one work queue per worker thread) makes the amount of threads become independent from the amount of FDs, so you can adjust the amount of threads to whatever gives the best performance. It also has the benefit of avoiding the overhead of thread-start-on-FD-open and thread-quit-on-FD-close, since you can reuse the existing threads. (Make it so that any idle thread will wait on a semaphore until its work queue becomes non-empty. Also, rather than using epoll directly, use libevent, so that it's portable to non-Linux systems.)

Moving to Python 3

rqosa — Thu, 17 Feb 2011 08:10:08 +0000

Or libevent with pyevent (or with gevent).

Moving to Python 3

spitzak — Thu, 17 Feb 2011 04:14:54 +0000

In the real world, text that is "UTF-8" can contain ERRORS (ie bytes that are not in UTF-8 order). They CANNOT be converted to UCS-2 or UTF-16 or UTF-32 or whatever Python thinks should be used. Any such conversion will either throw an error (resulting in a denial-of-service bug) or will be lossy (resulting in who knows what security or functionality loss bug).

The real result, in Python 3 and 2 and on Windows and virtually everywhere else where the "wchar" madness infects designers is that any programmers working with text where the UTF-8 might contain an error is that they resort to destroying the UTF-8 support by saying the text is actually ASCII or ISO-8859-1 or whatever (sometimes they double-UTF-8 encode it which is the same as ISO-8859-1). Basically the question is whether to eliminate the ability to see even the ASCII letters in the filenames versus the ability to see some rarely-used foreign letters in the cases where they happen to be encoded correctly. If you don't believe me then you have not looked at any recent applications that read text filenames, even on Windows. Or just look at the idiotic behavior of Python 2, described right here in this article!

Congratulations, your belief in new encodings has set I18N back 20 years. We will never see filenames that work across systems and support Unicode. Never ever ever, because of your stubborn belief that you are "right".

The real answer:

Text is a stream of 8 bit bytes. In about 1% of the cases you will care about any characters other than a tiny number of ASCII ones such as NUL and CR. You will then have to decode it, using an INTERATOR that steps through the string, and is capable of returning Unicode code points, Unicode composed characters, and clear lossless indications of encoding errors.

Strings in source files should assume UTF-8 encoding. If the source file itself is UTF-8 this is trivial. But "\u1234" should produce the 3-byte UTF-8 encoding of U+1234. "\xNN" should produce a byte with that value, despite the fact that this can produce an invalid UTF-8 encoding. Printing UTF-8 should never throw an error, it should produce error boxes for encoding errors, one for each byte. On backwards systems where some idiot thought "wchar" was a hot idea, you may need to convert to it, in which case encoding errors should translate to U+DCxx where xx is the byte's value (these are errors in UTF-16 as well), but conversion back from UTF-16 will be lossy as these will turn back into 3 UTF-8 bytes.

Moving to Python 3

foom — Tue, 15 Feb 2011 14:52:38 +0000

> It is exactly python's fault that it pretends unix is like windows, when it isn't.

Except that python doesn't actually do that, see comment above...

Moving to Python 3

nevyn — Tue, 15 Feb 2011 14:32:21 +0000

> Yea, it is not Python's fault [that unix doesn't look like windows]

It is exactly python's fault that it pretends unix is like windows, when it isn't.

Avoid Version Numbers

Webexcess — Tue, 15 Feb 2011 14:20:55 +0000

I was actually using:

    not str is bytes

But when you really mean "is this python3" then that's not clear to someone reading the code so I changed it.

Moving to Python 3

marcH — Tue, 15 Feb 2011 13:05:16 +0000

> Perhaps I am confused after all. I fail to see how Go can be statically typed, with, in particular, specific types for each function parameter, as well as "duck typed", where any type which provides certain methods will be accepted. If types must be known at compile-time then what would be the point of "duck typing"?

The point is: no need to design and maintain a type *hierarchy*. This point looks orthogonal to the static versus dynamic debate.

Moving to Python 3

mpr22 — Tue, 15 Feb 2011 11:15:28 +0000

Data sharing looks easy in threadland, as long as you don't look too closely. Processes make you worry about files and sockets and pipes and god-knows-what, and J. Newbie Programmer thinks that all looks like a lot more work than just having threads that can all see all the data.

(See also: "Why do I have to go through this big scary graphics library with lots of things to set up? Why can't I just stuff pixels into the graphics card?")

Avoid Version Numbers

ldo — Tue, 15 Feb 2011 01:48:15 +0000

I hate version numbers. Dont check for version numbers; instead, check for something as close as possible to the actual functionality you need.

Python even helps you, by providing ways to query it for things. E.g. to check for the bytes function, you dont have to go through the rigmarole of watching for a NameError exception; just write

hasattr(__builtins__, "bytes")

What could be simpler? And similarly the PYTHON3 version check could be replaced with something like

not hasattr(__builtins__, "unichr")

(Negated so its True for Python 3.x and False for earlier versions.)

Moving to Python 3

yuhong — Tue, 15 Feb 2011 01:24:44 +0000

Yea, it is not Python's fault that historically there has been no standard character encoding beyond ASCII for Unix filenames, in contrast to Windows LFN filenames and Mac HFS+ filenames, both of which used UTF-16 from the beginning.

Moving to Python 3

cmccabe — Mon, 14 Feb 2011 19:39:10 +0000

> Where I first started running up against problems was in a GUI that had a
> central append-only (which eased the locking constraints) data structure,
> and a corresponding tree of threads. Each thread could generate a new
> node(s) on the data structure, which might need more analysis by more
> threads. The operations on the data structure that needed to be thread
> safe had the thread safety encapsulated in the data structure. It just
> fell naturally into a threaded design.

In my experience, when you start sharing a lot of data between threads, you can take one of two approaches. You can have a giant lock that covers all threads. This is sort of like the old BKL or the GIL itself. One giant lock is simple, but it limits scalability a lot. Alternately, you can have many different little locks. This is great for performance and scalability, but hard on the poor programmers. Debugging becomes very difficult because runs are not repeatable. Code reuse is impaired because everything is tangled in this web of locks and you can't easily move code around.

When you have many little locks, the usual approach is to impose absolute ordering, so that if you take lock A before B at any point, you must always take A before B. That's what the kernel does. It seems to be the best strategy, but again, why impose this on yourself when you don't have to? Just don't share state unless you have to.

It's sad that programmers have been trained to think that threads are "simple" and "natural" and processes are "hard." That's the exact reverse of reality. I blame Windows and its high per-process overhead.

Moving to Python 3

cmccabe — Mon, 14 Feb 2011 19:26:36 +0000

> I'm not a huge fan of threads but where they mostly come in is dealing
> with I/O. Say you have an app that has to send/receive data over 3
> different pipes and in between it also has to do actual work. While you
> can write a main loop that does a select() over each descriptor and calls
> the right code when something becomes readable/writable, it's conceptually
> much clearer having a thread whose job it is to read any data and process
> it. Especially when you have to deal with issues like write() blocking,

Twisted is a great way to do multiple I/O operations without using threads. It wraps the ugly select() interface in something much nicer.

http://en.wikipedia.org/wiki/Twisted_(software)

Moving to Python 3

ssmith32 — Mon, 14 Feb 2011 04:33:54 +0000

As the other comment mentioned - I/O stuff is common.

Where I first started running up against problems was in a GUI that had a central append-only (which eased the locking constraints) data structure, and a corresponding tree of threads. Each thread could generate a new node(s) on the data structure, which might need more analysis by more threads. The operations on the data structure that needed to be thread safe had the thread safety encapsulated in the data structure. It just fell naturally into a threaded design.

As far as being mutex-oriented programming - with an appropriately designed shared data structure, I've rarely ran into that problem. There's usually a couple operations that you think hard about, get right, encapsulate, and move on. OOP really complements this well.

As far as the GIL-specific issue I ran into - with the GIL, your python interpreter runs on a single core, and all threads in that instance of the interpreter run on that core. So it makes multi-core kind of useless for heavily threaded programs. If you go the multi-process route, you get multiple interpreters. But like I said, sometimes threads can be nice :|

Moving to Python 3

cmccabe — Sun, 13 Feb 2011 21:12:44 +0000

> Perhaps I am confused after all. I fail to see how Go can be statically
> typed, with, in particular, specific types for each function parameter, as
> well as "duck typed", where any type which provides certain methods will
> be accepted. If types must be known at compile-time then what would be the
> point of "duck typing"?

Golang's philosophy is that inheritance is evil. Not "multiple inheritance is evil" (that is Java's philosophy), or "inheritance is often less useful than composition" (that's Scott Meyers' philosophy in Effective C++). Just "inheritance is evil."

Why is inheritance evil? Well, it forces you to do a lot of work up front before you start writing code. A lot of that work is just writing boilerplate code like Singletons, abstract base classes, Factories, Adaptors, etc. This leads to longer and less readable code. Changing the inheritance hierarchy is difficult after you've written the code. Moreover, unless the code is totally trivial, you will *have* to change the hierarchy in response to changing requirements and new insights into the design that you'll have over time.

The dirty little secret of C++ is that code written in the high-level, object-oriented style often tends to be longer than code written in the old-fashioned C style. It starts to smell like Java.

For a good criticism of Java, and deep inheritance hierarchies in general, see:
http://steve-yegge.blogspot.com/2006/03/execution-in-king...

[snip discussion of TLS, const, and restrict]

You seem to have a good understanding of const and restrict. Your analysis is correct. I'm glad to hear that __thread will be standardized soon. pthread_getspecific is slow on Linux.

Moving to Python 3

spaetz — Sun, 13 Feb 2011 20:42:49 +0000

What's wrong with multiprocess. According to the docs, some parts don't work on *bsd. Which breaks intrroperability.

Moving to Python 3

kleptog — Sun, 13 Feb 2011 13:39:49 +0000

I'm not a huge fan of threads but where they mostly come in is dealing with I/O. Say you have an app that has to send/receive data over 3 different pipes and in between it also has to do actual work. While you can write a main loop that does a select() over each descriptor and calls the right code when something becomes readable/writable, it's conceptually much clearer having a thread whose job it is to read any data and process it. Especially when you have to deal with issues like write() blocking, etc...

This right away gives you 4 threads. Add a thread to monitor everything (since thread death does not get signalled anywhere) and you're at 5.

There's not so much shared state as that I/O on any port can execute callbacks which could access anything the initiator of the request wanted (go closures!). There's barely any locking, python's atomic instructions is sufficient (though I imagine Queue does it under the hood).

One effect of the fact that I/O falls outside the GIL means that the process running at full speed can take 110% CPU. (There's a lot of I/O).

Back to the issue at hand: Python2's unicode handling bites me daily. Whoever decided that using str() on a unicode string should *except* when you have a unicode character, should be shot. Just error *every* time, then I won't get called at 3 in the morning to fix the bloody thing (usually buried in some library, even some standard python libs have had bugs in the past).

Moving to Python 3

nybble41 — Sun, 13 Feb 2011 09:33:01 +0000

> You are confused. Go has static typing. As in, checked at compile-time. Code that misuses types will not compile.... I don't know why you would say that templated code is not as "strongly-typed" as other C++ code.

Perhaps I am confused after all. I fail to see how Go can be statically typed, with, in particular, specific types for each function parameter, as well as "duck typed", where any type which provides certain methods will be accepted. If types must be known at compile-time then what would be the point of "duck typing"?

Note, too, that it is entirely possible to misuse types in a "duck typed" language, even with compile-time checking. Since there is no information regarding the connections between types (namely inheritance), any type which provides the right method signatures will be accepted, whether or not they were intended to be used in that fashion. This is where explicit interfaces and inheritance can prove very useful as a way of preventing semantic errors.

Go code and C++/D templates are not as strongly-typed for the reasons I stated above: namely, any type with a matching signature will be accepted, even if that use of the type's members is incorrect or even undefined. Classes with inheritance are more strongly typed because they explicitly state that they implement the expected interface--the semantics, not just the type signatures.

> Also, you seem to be confused about C++ as well. dynamic_cast *always* "requires a runtime lookup" on the RTTI (runtime type information) in C++.

RTTI is only required to test that the object you are casting is derived from the class you are casting to. As such, it is a very simple test. In Go the compiler must either generate separate code for each type (like C++/D template functions) or else look up the member offset or function pointer by name for each object at runtime, which seems to me quite likely to be far more expensive.

> I also would like to note in passing that C/C++ have the const, restrict and __thread keywords, which could be used to provide exactly the same message-passing interface you describe in D.

The 'const' and 'restrict' keywords in C++ are not equivalent to 'immutable' in D. Immutable data is guaranteed to never change, and this is enforced by the compiler. You can't pass mutable data to a function expecting immutable, for example. (You *can* pass mutable data to a function which accepts 'const' data, in addition to immutable data.) The 'restrict' keyword is just a declaration of intent. If you declare a pointer 'const' and 'restrict' then the compiler will optimize the code on the assumption that the data cannot be altered via another pointer, but it is up to the programmer to ensure that this is actually the case. I do not think it insignificant, either, that in D you have to specifically declare data as shareable between threads (again enforced by the compiler, unlike in C/C++), whereas in C/C++ all global data is shared by default and you must use __thread to make it private. In D thread-safety is the default; in C/C++ it is a rarely-used compiler-specific extension. (C++0x will supposedly add TLS as a standard storage class.)

Moving to Python 3

cmccabe — Sun, 13 Feb 2011 01:55:38 +0000

> [For golang] One could say that this is only because there is an
> implied dynamic_cast (but with worse performance, since it requires a
> runtime lookup) at every location where an object is used.

You are confused. Go has static typing. As in, checked at compile-time. Code that misuses types will not compile.

Think of it this way: if you refer to a type T in a C++ template, and then use T::foo, you're not doing a dynamic_cast. You're just using the normal type system. If T does not have a foo method, the code will not compile. Similarly, in Go, you will get a compile-time, not runtime, error, if you try to use methods on an object that don't exist.

Also, you seem to be confused about C++ as well. dynamic_cast *always* "requires a runtime lookup" on the RTTI (runtime type information) in C++. If you do not compile with support for RTTI, you cannot use dynamic_cast. C++ templates, on the other hand, are a completely compile-time mechanism. I don't know why you would say that templated code is not as "strongly-typed" as other C++ code.

> While I fail to see any reason to prefer extraneous syntax over a library,
> there is in fact some syntax in D intended to support multithreaded
> programming: the 'immutable' and 'sharable' type keywords, for example,
> plus the fact that global variables occupy thread-local storage by
> default. Assurance that shared state cannot be mutated behind the scenes
> (not just through a given reference, like 'const', but *anywhere* in the
> process) allows large messages to be passed efficiently and safely.

There's a lot of syntax in D, but is it the right syntax? I think we are going to have to agree to disagree.

I also would like to note in passing that C/C++ have the const, restrict and __thread keywords, which could be used to provide exactly the same message-passing interface you describe in D. In fact, there have been a lot of them created over the years.

Moving to Python 3

jensend — Sat, 12 Feb 2011 18:43:45 +0000

Numpy started supporting Python 3 with 1.5 last summer; SciPy just finished the second release candidate of .9, which supports Py3K, and the final version should arrive quite soon. Matplotlib looks like they need some help getting things ported though.

With NumPy and SciPy finally Python 3-compatible, two of the biggest reasons why people have stuck with Python 2 are finally gone. With the release of GTK+ 3 with PyGObject, distros that have depended on PyGTK+ will start to move as well. Chances seem good that we may see most of the momentum shift to Python 3 this year.

Dealing with external scripts

ssam — Sat, 12 Feb 2011 17:23:14 +0000

probably best not to worry. python2 will still be around for a long time. there is still plenty of FORTRAN 77 around, especially in science.

Moving to Python 3

nybble41 — Sat, 12 Feb 2011 03:44:53 +0000

> Saying D has duck typing because it has templates is a little misleading. Nobody would seriously say that C++ has duck typing, and it also has templates.

Why not? The following is valid D code:

void callMethod(T)(T object)
{
if (object.property)
object.method();
}
...
callMethod(new ClassA);
callMethod(new ClassB); // unrelated to ClassA

Any type which has the required property and method can be passed to the template function. I would say that looks exactly like duck typing. You can do the same thing in C++ with template functions, and in fact the STL makes extensive use of such functions.

If you end up using interfaces and/or inheritance instead that is only because the strongly-typed approach (which Go does not support) has advantages over duck typing, including better compile-time error checking and runtime performance.

> Speaking of metaprogramming... one nice thing about Google Go is that because there's no inheritance hierarchies, there's no dynamic_cast. One less ugly piece of clutter.

One could say that this is only because there is an implied dynamic_cast (but with worse performance, since it requires a runtime lookup) at every location where an object is used.

> The message passing stuff in Phobos is interesting. It seems that the integration into the language is just at the library level, though, rather than being an integral part of the syntax as in Go.

While I fail to see any reason to prefer extraneous syntax over a library, there is in fact some syntax in D intended to support multithreaded programming: the 'immutable' and 'sharable' type keywords, for example, plus the fact that global variables occupy thread-local storage by default. Assurance that shared state cannot be mutated behind the scenes (not just through a given reference, like 'const', but *anywhere* in the process) allows large messages to be passed efficiently and safely.

Moving to Python 3

foom — Sat, 12 Feb 2011 01:50:09 +0000

They don't ignore random-byte filenames. Filenames are decoded from bytes to unicode with the *locale encoding* (not always utf8), and the "surrogateescape" error handler. That allows roundtripping filenames through unicode even if they're not in the proper encoding at all (although in that case they'll be garbage).

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

Moving to Python 3

cmccabe — Sat, 12 Feb 2011 01:33:17 +0000

> D compiles to native binary code, like C or C++

Well, technically gcj can compile Java to native binary code. However, Java in general has poor integration with non-Java code-- I can't deny that.

> Its metaprogramming features give you all the flexibility of C++-style
> class and function templates, including compile-time "duck typing"

Saying D has duck typing because it has templates is a little misleading. Nobody would seriously say that C++ has duck typing, and it also has templates. For most of your classes in either C++ or D, you're still going to be worrying about inheritance hierarchies and doing "big design up front" which seems more like the Java way of doing things, not the Ruby way.

Speaking of metaprogramming... one nice thing about Google Go is that because there's no inheritance hierarchies, there's no dynamic_cast. One less ugly piece of clutter.

The message passing stuff in Phobos is interesting. It seems that the integration into the language is just at the library level, though, rather than being an integral part of the syntax as in Go.

Overall, the more I learn about D, the more I see it as a "better C++". Like C++, it tries to include everything *and* the kitchen sink. Thankfully multiple inheritance didn't make the cut this time, but most of the other clutter did. (And just like C++, there are some weird omissions-- like reflection.) Google Go, on the other hand, seems to be a more elegant and minimalist language, kind of like C. I like that. But, these are just first impressions, and I guess I might change my mind later.

Moving to Python 3

cmccabe — Sat, 12 Feb 2011 00:13:05 +0000

There was a thread about non-UTF8 filenames on LWN a little while back. (One of many, I'm sure.) The consensus seemed to be that they were quite useless. They tend to break the mental model of programmers too. For example, programmers tend to assume that printing a filename to stdout is *not* a security vulnerability. But if that filename contains control characters... surprise! It can hack your terminal emulator.

Python has a pretty long history of "forcing" what it believes to be the correct behavior on its users. It even tells you how to use whitespace. I am not surprised at all that they ignore non-UTF filenames. Frankly, it's a good decision.

Dealing with external scripts

foom — Fri, 11 Feb 2011 22:48:16 +0000

Yes -- most people seem to be dealing with this problem simply by sticking with Python2...

Dealing with external scripts

schwitrs — Fri, 11 Feb 2011 22:19:34 +0000

I maintain a scientific software package which is partially written in Python, but more relevantly, has Python user scripts which I do not and cannot maintain. It is very important that old results are reproducible. A requirement of very minor, obvious changes to the scripts might fly, but the Python 2 to Python 3 transition doesn't seem to be this. Has anyone tried to deal with this sort of problem?

Moving to Python 3

nybble41 — Fri, 11 Feb 2011 21:02:10 +0000

D is far from "Java with slightly better syntax". It compiles to native binary code, like C or C++, and can link directly against C and C++ library functions. Its metaprogramming features give you all the flexibility of C++-style class and function templates, including compile-time "duck typing". It has a multithreading model based on message-passing, not mutexes or conditions, with explicit sharing and process-wide immutability built into the type system. Object invariants and pre-/post-condition annotation are available to support design-by-contract.

Moving to Python 3

cmccabe — Fri, 11 Feb 2011 19:47:36 +0000

D is kind of interesting. Wikipedia says it's existed since 1999, but apparently the 1.0 release was only in 2007.

To me the big question is why I should use D over, say, Java. D has "Java-style single inheritance with interfaces and mixins" according to Wikipedia. If you're going to be Java-style, why not just use Java? I'm sure that D's syntax is probably slightly better than Java's. (That's not a difficult achievement.) But does that slight improvement justify throwing away all the existing libraries and code?

On the other hand, Google Go doesn't have inheritance at all. It has duck typing, enforced at compile-time. Its approach to concurrency is not mutexes and condition variables, but channels. I think these two improvements alone justify the switch to another language.

I am curious how the D and Google Go runtimes compare to the JVM. My experience has been that the JVM runs code relatively fast, but starting the JVM itself takes up a huge amount of resources. In comparison, equivalent C++ or C programs have a lower up-front cost. This is one of the reasons why Java web hosting is still more expensive than PHP web hosting, even today. Java has a high up-front performance cost but then does better than PHP over time.

upgrade to ugly code?

amtota — Fri, 11 Feb 2011 13:16:21 +0000

> It certainly can be done, it will just be ugly for a while.
And here lies the heart of my complaint: what sort of "upgrade" makes your code harder to read and maintain?

Moving to Python 3

shane — Fri, 11 Feb 2011 11:45:16 +0000

You could try here:

http://getpython3.net