Submitted by Python 3.0, ‘Python 3000’, has reached its first public release. This version will be followed by beta releases throughout 2008, and the final release is scheduled for August 2008. “Python 3000 (‘Py3k’, and released as Python 3.0) is a new version of the language that is incompatible with the 2.x line of releases. The language is mostly the same, but many details, especially how built-in objects like dictionaries and strings work, have changed considerably, and a lot of deprecated features have finally been removed.”
I respect how Python development seems to constantly be pursuing quality over maintaining backwards compatibility. An important part of optimization is being able to throw away efforts that are not suitable for the future, from a quality perspective.
I hope that the market will realize this over time, as well, and embrace the new possibilities the language seems to offer. Even if it will break existing programs.
I will *definitely* be looking into Python 3.0!
Given that large Projects like Zope not even use the latest version of python 2, I wouldn’t have too high hopes.
Backward compatibility is also very important make python a credible alternative in business.
Companies, that intend to write software with millions of lines of code are not likely to chose Phyton over e.g. java, if you need to rewrite the code every time the language developers finds a more elegant way of doing things.
In some sense I would say that the Python people are a bit too smart for their own good.
You do know that they’re making the “incompatible” 3.0 version in parallel with the 2.6, beackwards compatible version, right?
So for a long time, there will be a new, backwards compatible Python version as well as the 3.0
So I think they’re aware that the backwards compatibility is important, while at the same time understanding that it will sometimes stand in the way of progress.
Yes, I’m aware that the 2.x branch will be maintained for years to come. But put it this way: If Python was just like Microsoft, they would wrap 2.4 into a new package, add a JavaScript utility and call it 3.0, and six months later they would release Python 95
Thank God (or someone, I dunno) that there’re still sensible people in this world
Yes, big companies like Google are never going to use python because it’s lack of backwards compability. No, wait…
Python is, imho pretty much the best language to write web apps at the moment, assuming you control the enviroment where the apps are deployed.
For web applications, I would probably prefer Java in most cases for performance reasons. On the other hand, sometimes there are more than speed to consider. With tools like Plone and Zope very advanced web functionality can be created without even touching the Python that supplies the functionality in the background.
Python is still a very nice language though. I’m not saying that big companies won’t use python. What I’m saying is that they wont use python 3.0 They will stay with the 2.x branch for as long as possible, making much of the new nice stuff sort of wasted..
Just compare the Python situation with that of Java. In the java case, 10 years old, or older java classes runs well on the latest java 6. But even so most people still use jdk1.4, people are afraid to upgrade even though java 6 is a completely different animal with respect to speed and ease of development than jdk1.4, so in reality there is very little reason not to upgrade. Still they don’t. So, What do you think will happen to python where backward compatibility is broken deliberately.
IMHO, having just one branch, where you try to be backward compatible for say at least 10 years but evolve without breaking old things is a better way to introduce new things. That way more daring developers have a better chance to influence old conservative ones with a “if it worked for grand dad it works for me” attitude.
“””
For web applications, I would probably prefer Java in most cases for performance reasons.
“””
Because, as we all know, hardware is expensive. And programmers are cheap.
Check out Django:
http://www.djangoproject.org
If it can handle the Washington Post’s site, it can probably handle your sites. It scales out like you wouldn’t believe. And with memcached, you have caching at multiple levels, at as fine or as coarse a granularity as you desire.
And the “Curse Gaming” site has shown that it can handle 600,000 pages per hour. (That’s pages, not hits.)
Edited 2007-09-01 17:59
As you say, people (not just programmers) are expensive, hardware is cheap.
I have checked out Django, and IMHO the usability for the content providers leaves a lot to wish for. If you want to go the python way, Plone http://www.plone.org is probably a much better choice as it will require less training for the end users, and it have a large flora of plugins so chances are that you don’t have to do much programming, other than tweaking the templates to your liking.
It is also built as a client server applications where you can have many frontends connecting to one database backend making it scale almost infinitely.
The fact that it comes in a bundle with Python/Zope/Plone makes it very easy to get started with as you don’t need to install and maintain a separate database. (even though you can if you want).
The fact that it is built on an application server saves a lot of lines of code in case you need to do something more advanced in the backround such as banking or shopping cart applications.
The Templates in Plone is written in TAL (Template Attribut Language) where every template is a full html page with no special html tags. This means that the easily can be handled well by standard html tools. It is also possible to add mockup data in the templates during the design process that then left out when applied to the server.
On the other hand, doing it in java isn’t exactly rocket science these days either, and that will go easier on your system resources. With modern tools like Netbeans or Oracle JDeveloper, making web GUI for your applications is very much a point and click thing, and writing the actual application logic probably carry about the same difficulties regardless of what programming language or application server you use.
I suppose that in the end, your choice will depend on what background you have e.g. what languages you know and what performance you need, and the amount of application logic you need before you push out your web pages to your users.
http://oodt.jpl.nasa.gov/better-web-app.mov
Nice movie. It really shows how Zope/Plone shines compared to most other technologies when it comes
to ease of development. It really has it all, internationalization, good template language, code generation from UML, skinability, good security, accessability…
The java part of the movie is a bit out of date though. You don’t need to write XML setup files in modern Java EE 5. Another thing you don’t use EJBs for user interfaces, they are for business logic.
Today, EJBs contains just business logic, and not a lot of life cycle stuff like they used to do. You can generate Java code from database model or vice versa, just like you can in Rails and other similar with a few mouse clicks in modern IDEs like Netbeans. So I would say that modern java rocks at least as much as the various other technologies shown in the movie when it comes to rapid development.
However, unlike old python code, ugly old sucking EJBs still run unmodified on modern Java EE 5 servers using the latest version of Java. This is actually a good example of how you can make radical improvements can be done without breaking backward compatibility.
I wish python developers had taken a similar road in Python 3.
Zope/Plone is very specific about what version of Python it needs. E.g. the Zope 2.10 used for Plone
needs Python 2.44, version 2.5.x will not work, the same goes for some older plone 2.x versions.
Now they add even more incompatibilities, this is not good for an otherwise good platform. It results in that people will need to install several python version with the obvious chances of making mistakes.
“””
“””
The rest of the movie is a bit out of date, as well.
Best I could provide. It’s a snapshot of 2006.
So you contend that Java used to suck for web development, but has turned a new leaf, recently?
Please, no links to Jonathan Schwart’s blog.
Edited 2007-09-02 04:13
The rest of the movie is a bit out of date, as well.
Yes, among other thing, Plone have just released Plone 3 with a lot of AJAX goodies that makes the application feel snappier. They have also tidied up a lot in the code. It is also faster probably due to that they now use Zope 2.10.
So you contend that Java used to suck for web development, but has turned a new leaf, recently?
Oh yes it has changed! Pre Java EE 5 web development for java not only sucked, it sucked major. In fact they probably compete for the title of worst API ever.
The main difference is the introduction of annotations in Java SE 5 and used by Java EE 5. This made it possible to get rid of the XML config files.
Another big difference is the Java Persistance API that makes it very easy to map properties of java objects to a relational database, in most cases you will not have to write any code at all for this to happen, the only thing you have to do is to give the class an @Entity annotation directly before the class declaration. Java will automagically try to map property names in your java object to field names in your database.
Yet another change is that EJBs now have lost all the life cycle stuff and only contain business methods. They look much like ordinary java classes, What makes them special are again in the annotations. I really don’t know why the movie talked about EJB for web GUIs, they are normally part of the business logic, where the speaker in the beginning of the movie oddly enough seamed to be satisfied with the bad old J2EE.
Contrary to what your movie tells us, java programmers hate XML files just as much as anybody else, its Just that JBoss/Red Hat haven’t noticed yet.
The difference to your movie, is also that there now are good GUI tools to handle things, for us so we don’t have to manually write a most of the stuff that is written in the emacs examples of your movie. Even if you use bad old J2EE, the typing to create a hello world servlet would probably be one or two lines of code.
Speaking of Application logic, again using annotataions or a few mouse clicks in Netbeans you can turn a java method into a web service that can interact with .Net or be used as backend for AJAX stuff in your web pages.
Another major enhancement is that JSF now is standard part of Java EE 5. This makes it possible for IDEs like NetBeans to do drag and drop development of web pages, much like how it is done in Dreamweaver, but with more focus on application logic.
So yes, Java for the web isn’t hard anymore. Still, if you know python but not Java and don’t have extreme needs for speed I would say stick with what you know. That java doesn’t suck anymore, doesn’t mean that all other methods of doing web applications have become obsolete, merely that Java caught up with the others.
Again, what makes the comparison interesting here is that Sun almost threw out everything they got, and started fresh while still maintaining backward compatibility.
The tradition in the python world seam to be that if something sucks throw it out and replace it with something new and elegant and the smart people will follow. This Python 3000 thing is not the only example, e.g. look at Zope2 vs Zope3.
It is probably true that the smart people will follow, but unfortunately smart people seldom work for free so this attitude adds to the cost of the platform.
I was in complete agreement with you, until I read the reply to your post. I still agree with you. I think it is important that if you recognize vastly better ways to do something that you aren’t so committed to compatibility that you add awkward for the sake of backward compatibility.
I think one of the things that keeps Microsoft from innovating is the legacy support they have to have. You can put me in the category of a Microsoft opponent. But, you know they have talent. If they didn’t have to maintain compatibility, they could probably release something even I would like. Being open source affords the luxury of not being obligated. And, I don’t think they (Guido) ever promised not to break compatibility. I don’t think they are promising they will never break compatibility again, either.
Edited 2007-09-01 01:03
You know, with all the money Microsoft has, I never understood why they never did what Python is doing: keep the backwards compatible stuff but also make an OS that’s free of legacy and can be as good as they can make it. They probably worried it would be a competitor to Windows. Oh well, that’s what you get if you value money above all else.
this is one of the best and most exciting languages of our time. I can’t wait for teh 3.0 release
Can you elaborate? I’ve never used python… What are its strong points and what type of programs would really benefit from being written in python?
Here you go: http://www.python.org/about/
* very clear, readable syntax
* strong introspection capabilities
* intuitive object orientation
* natural expression of procedural code
* full modularity, supporting hierarchical packages
* exception-based error handling
* very high level dynamic data types
* extensive standard libraries and third party modules for virtually every task
* extensions and modules easily written in C, C++ (or Java for Jython, or .NET languages for IronPython)
* embeddable within applications as a scripting interface
Python is powerful… and fast
Python plays well with others
Python runs everywhere
hahahha i didnt read your post before posting mine. but it seems we see eye to eye on this one and in somecases almost word for word.
* very clear, readable syntax
That’s a matter of personnal preference. I don’t like the absence of visible block delimiters myself.
* intuitive object orientation
Intuitive? What is that supposed to mean?
* very high level dynamic data types
Oh yeah, even integers are objects, and most of them are builtin, shared instances. So the interpreter carries around pointers to integers and have to dereference them all the time instead of juts manipulating the values directly, all for the sake of the once in a while useful feature of being able to treat thee like objects of the integer class.
They could have done boxing/unboxing to convert a plain, normal, basic integer type into an integer instance as needed.
* extensive standard libraries and third party modules for virtually every task
So extensive that there are even several for the same tasks, including some deprecated ones.
* extensions and modules easily written in C, C++
(or Java for Jython, or .NET languages for IronPython)
Easily written… Yeah, I guess so. From the top of my head:
– they just figured (in 2007) almost all of the places where to use const so we don’t need to const_cast every constant string anymore
– they provide horrible macros to do various things (and some of them don’t include braces so you have to surround them yourself). They apparently still haven’t discovered inline functions, but seeing how they just discovered the const keyword, it may be a while.
– they provide horrendous macros for boolean types that do fugly casting that breaks strict aliasing rule – but you have no alternative to test booleans, so you either have to live with the warning, disable strict aliasing or just screw their macros and do it by hand, thus breaking source level compatibility
– creating a new type is a snap that just requires a ridiculous initializer list with a shitload of zeros and a macro in the middle. Very pretty. A common principle of object orientation is to have opaque structures that are initialized by some function, and you’d think that people designing an OO language would have a grasp of such concepts.
– things have unconsistant naming schemes (new/dealloc, alloc/free).
– the python header has to be included first because they felt they had the right to alter global defines that are used by system headers (imagine if every other library had this kind of requirement)
– you only need to redundantly specify the name of the module you want to create twice.
– almost forgot: explicit reference counting, which is exceedingly stupid and would alone largely suffice to make the api not the least bit user friendly, unlike what fanboys say.
* embeddable within applications as a scripting interface
Thanks, but no thanks. Lua is a cleaner language, more compact, with a non-retarded API, and it’s faster to boot.
Edited 2007-09-01 01:48
>Lua is a cleaner language
Mmm, if memory serves in Lua if you create a variable without specifying ‘local’, then it’s a global variable.
Global by default isn’t clean IMO.
Oh yeah, even integers are objects, and most of them are builtin, shared instances.
We have a saying around here: “you’re already in the sticks, so you might as well enjoy the grits!”
We’re talking about a bytecode interpreter here. You’ve lost the performance battle before it starts, so why get bent out of shape about stuff that’s in the noise?
So the interpreter carries around pointers to integers and have to dereference them all the time instead of juts manipulating the values directly
This cost is largely moot with good implementation techniques. You can use type inference to statically unbox integers, or you can use a tagged representation in which you store the integer directly in the pointer word.
Of course, the scripting languages aren’t even playing the high-performance game, so these implementation techniques probably aren’t worthwhile.
“Python is powerful… and fast
Python plays well with others
Python runs everywhere”
Of course you left out one key point which Python doesn’t do well at: Performance/Scalability. That combined with the fact that they refuse to maintain backwards compatibility strikes this otherwise fantastic framework from the realm of business applications.
It seems that some people are really playing up the “lack of backwards compatibility” bit. That’s the major thing about this 3.0 release. It’s special. It is *the* release where compatibility is going to be broken in favor of future expansion.
The vast majority of the existing python code base will run under python 2.2, 2.3. 2.4, and 2.5. You might as well argue that C++ is not ready for the enterprise.
As to performance… it depends on what you are doing. Python *can* be quite fast. It is very high level, and the high level constructs are blazingly fast. Now, if your program runs in a tight loop… it’s oodles faster than Ruby… not as fast as Java. Unless, of course, you use the psyco module, which gives you JIT compilation. Using that, I’ve gotten python within a factor of 2 of C’s performance (gcc -O3) for finding prime numbers. Loops don’t get much tighter than that.
Edited 2007-09-01 04:29
It is very high level
Python isn’t actually particularly high-level. It’s got some moderately powerful high-level constructs, but the guts are all laid bare for you to play with (eg: objects as hash tables). This isn’t inherently a problem, because sometimes you need low-level access, but I find myself leaning on such features way too often when writing PYthon. It’s also desperately missing some features (eg: multi-methods).
and the high level constructs are blazingly fast.
IE: The stuff already written for you in C is pretty fast…
it’s oodles faster than Ruby… not as fast as Java.
Ruby is comically slow, and both are in a different league than Java.
Using that, I’ve gotten python within a factor of 2 of C’s performance (gcc -O3) for finding prime numbers. Loops don’t get much tighter than that.
Or much more simplistic/trivial. Wake me up when Psyco can give you that kind of performance on non-simple performance-critical loops that spans hundreds to thousands of lines.
Edited 2007-09-02 20:01
“Of course you left out one key point which Python doesn’t do well at: Performance/Scalability”
I’m sure the people behind YouTube would disagree with you.
“I’m sure the people behind YouTube would disagree with you.”
You do realize that the only thing governing performance over at YouTube is bandwidth availability/IO throughput, right? It has absolutely nothing to do with whatever language they used. From a programming perspective, there isn’t much interesting about YouTube actually…just a lot of repeater controls with embedded <object> tags. *Yawn*
Python strong points:
+ Simple syntax
+ Interactive evaluation
+ Simple, dynamic semantics
+ Sanely-designed libraries (not overdesigned!)
+ Significant whitespace
Python weak points:
– Slow as balls
– Syntax can be awkward for multi-line statements
– Significant whitespace
Pretty much every program that doesn’t need speed* is probably better written in Python than in, say, C++ or Java.**
*) And even some that do. Text processing and GUI programs, for example, can easily be written in Python because most of the heavy computation is implemented in C libraries.
**) And of course, if you need the elegance of Python with speed more in the ballpark of C, there is a certain L-word I could point you to
“””
Python weak points:
– Slow as balls
“””
I didn’t realize that balls, as a class, were slow.
But it really depends, doesn’t it? Python can be quite fast. But put it in a tight loop… and it’s a lot slower than a compiled language. Install psyco and add this to the top of your python programs:
“””
import psyco
psyco.full()
“””
It gets you JIT compilation. The bad news is that it is x86_32 only.
Edited 2007-09-01 22:01
But it really depends, doesn’t it?
No, not really.
Python can be quite fast.
Python code itself is invariably slow. Python programs can be quite fast if they spend most of their time in native C libraries.
I think it’s telling that the Python standard library is mostly implemented in C, rather than Python.
It gets you JIT compilation.
Psyco’s improvements are… fragile…
Incidentally, there has been a lot of academic efforts into making Python fast. None of these have become generally useful. I think they’re all barking up the wrong tree.
“””
“””
Yes. Python rewards you for using the high level constructs.
“””
“””
Of course. They *should* be implemented in C.
“””
Psyco’s improvements are… fragile…
“””
Psyco’s improvements are… hit and miss. You don’t always see a lot of improvement. But that is because python is already faster than some people expect.
“””
“””
PyPy? I’m a bit skeptical of it myself.
Yes. Python rewards you for using the high level constructs.
The question is, what are those high-level constructions implemented in? There is a clear advantage to languages powerful enough to largely be implemented in themselves.
Of course. They *should* be implemented in C.
Why? Not writing a language’s standard library in itself is basically an admission that it’s not suitable for high-performance code!
It might be enlightening to peruse the OpenDylan sources at http://www.opendylan.org. Specifically, trunk/fundev/sources/dylan/integer.dylan. You’ll notice that even integer arithmetic is implemented largely in Dylan, with the compiler providing only low-level machine-word operations. This is for a language that’s playing in C’s league in the performance department, not Python’s.
PyPy? I’m a bit skeptical of it myself.
There have been perhaps half a dozen academic papers on improving Python performance through things like type-inferencing. Google “Python type inference”.
Edited 2007-09-02 00:12
“””
“””
“””
“””
High performance is not a first tier goal of Python. And ‘C’ is not dirty.
Some of Python’s standard library is written in Python. Some of it is written in C. That is appropriate.
Rayiner, I’m not proposing that we reimplement the Linux kernel in Python. That would be inappropriate.
Python has great advantages over other languages in terms of development speed, and good performance for a wide range of applications.
Only when performance is critical would I agree with your reservations.
Python has great advantages over other languages in terms of development speed, and good performance for a wide range of applications.
Meh. As a language, I’d rank Python solidly behind Common Lisp, and solidly in front of Java. This is based on having written more than one multi-KLOC program in each. Adherents of ML or Haskell claim that these are at least as productive as CL, perhaps more, but I can’t back that up first-hand. At the same time, benchmark-wise, these languages are all in a completely different league than Python. On the Great Computer Language Shootout, CL, ML, and Haskell are all within about a factor of 2 of C, while Python is slower by a factor of 18.
(I should point out that CL, ML, and Haskell all have sophisticated native-code compilers, and that Python uses a bytecode interpreter. For various reasons, however, I’m convinced that a comparable level of compiler technology still wouldn’t get Python into that ballpark).
Only when performance is critical would I agree with your reservations.
It’s more complicated than that. On one hand, if you can heavily leverage native code, or your code is I/O bound, you can use Python even for tasks where performance is very important. On the other hand, if you can’t leverage native code at all, you can’t even use it for tasks where performance is a factor.
Edited 2007-09-02 03:27
Lisp is more productive for the programmer than Python? Is Cobol better, as well? How about Prolog? Snobol?
“””
It’s more complicated than that.
“””
Yep. It is. The thing is… you can usually leverage native code.
But… if you can’t, you might have to fall back to faster and more popular languages, like Common Lisp.
Lisp is more productive for the programmer than Python?
In my experience, yes, unless the lack of CL libraries bites you. I suspect you’ll hear the same thing from Haskell and ML users too, by the way.
Yep. It is. The thing is… you can usually leverage native code.
I haven’t written a program in a long time where I could just use a pre-existing Python library to do the grunt work. My projects over the last few years: network simulations, physics analyses of various sorts, and various compiler-like things. You’d traditionally write this sort of stuff in C, but with a good, fast HLL, you would you?
Edited 2007-09-02 06:43
python is a dynamic object orriented language with easy to learn and almost intuative syntax. I always think of it like Perl but in english
. you can write all kinds of alpications with it, virtualy tayhting you can think of and python plays well with others. most of my python projects make use of WxWidgets wich plays extrememly well with python.
for more info check out their site at http://www.python.org
but I hope some tutorials for beginners are made. I am just learning python now and it seems like it is already changing. For instance.. supposedly the print keyword is now going to be called like a function.
instead of
print ‘Hello World!’
what will it be?
will it be print(‘Hello World!’) ??
Edited 2007-08-31 21:40
I love python and rarely code in any other language now. I’ve posted about its merits man times before – i won’t do it again.
I would love py3k to fix the following language features:
NameSpaces
Python has plenty of useful practical support libraries and people add more. Its really extensible and people extend it too. For a really elegant language its a real shame that namespaces for imported modules/functions and even within a piece of code is not so clealy defined or protected. I would love some kind of rules to be enforced here – so far they don’t. You can “import * from” or “import A as B” as much as you like and trample all over each other’s code.
Concurrency
Python has, as is the python way, nice easy to use libraries for threading. Sadly these are actually interleaving python bytecode within a python interpeter. Having multicore doesn’t help – they’re not used. Also the great big lock also prevents any granularity for concurrency. I know their way is portable – but these days they should at least have an option for (1) OS threads, (2) userland threads on multicore. Even the much-touted Stackless Python (www.stackless.com) has nice micro-threads but these again are interleaved within the same interpreter.
Asynchronous I/O
This is allegedly handled by the big Twisted projects. But there is no good documentation and the sites are un-pythonic in that they are dark and scary – not the python way!
XML
XML was really well supported by python — ooh back in 1990! Now they have a cut-down version of a library that is a little out of date. This has led to competing XML add-ons which confuse the hell out of users. PyXML. 4suite. and the one based on gnome’s libxml. and more. They need to go back to their “batteries included” ethos and get a good, solid, fully functioning XML libary into the base python. I have to add a separate one just to do a range of XPath queries.
Edited 2007-09-01 01:23
namespaces:
Not sure what you want there. Python isn’t much different fro c++/java here. Yes, you can import conflicting names, but it is also a really easy problem to solve.
I’d rather have it this way than to have extra complexity for every situation.
Concurrency:
Yes, using multicore CPUs would be good. Not a problem I have atm but I agree.
XML:
For simple things I find that elementtree is simply amazing. I never want to have to use xml.dom.* again.
There might be some advanced features missing there though, haven’t done enough to say for sure.
Yes, completeness is good, but just don’t force me into the DOM swamp again.
It’s nice that the language and the implementation are moving forward, but I wish people would stop confusing those two together. It makes discussing programming languages a real pain.
No, people, it doesn’t make sense to say that the programming language runs efficiently.
Backwards compatibility is not a problem as long as you can have multiple versions on the machine at the same time and the application can specify which version to use.
If you can’t have multiple versions active at the same time then the devs (either at Python or whatever distro) are just plain not smart.
Anytime any base “application” (database, compiler, etc.) upgrades to an incompatible version you should be allowed to have multiple versions active at the same time.
Having multiple Python version doesn’t solve everything. Imagine you want to utilize pyuno functionality from OpenOffice.org in Plone, e.g. to do some kind of documentation convertion thing.
You will see that pyuno will require Python 2.33, while Zope/Plone will require Python 2.44. The only solution is to build some kind of client server solution.
But having only one version wouldn’t solve that problem either.
Two versions of the same language that can’t communicate is the same as two different components written in two different languages and that makes them not communicate (also not smart for migration, hard to do yes) .
I don’t really care if the incompatibilities comes from major or minor changes in the Python version number. If a new Python version can’t run code that was written two years ago, Python has a serious problem. If such behavior was an isolated event I wouldn’t complain, but this is very common.
You don’t see many correctly written C-programs that fail to compile when gcc gets a major upgrade, and even less for minor upgrades. Java code from ten years ago runs fine in the latest version of Java 6, in fact in the majority of all cases even compiled Java classes from 10 years ago would run just fine.
This sort of indicate that the problem somehow is with Python, or at least how it is developed. Not caring for old users is not a good way to build customer relations in the long run.
As a language Python is easy to use, and you can quickly put together code that do what you want as you don’t have to declare variables as in C or Java, but most of that advantage goes away if you have to have two or three versions of python installed.
Multiple pythons lead to more maintenance. E.g. if you add a new database driver you will have to add that to all of your Python installations.
“If a new Python version can’t run code that was written two years ago, Python has a serious problem.”
Then Perl has a serious problem too. Most Python code that runs fine in 2.3 also runs fine in 2.5 (and will keep running in 2.6). Python issues in 2.x releases are no different than Perl issues in 5.6 vs. 5.8 releases.
“You don’t see many correctly written C-programs that fail to compile when gcc gets a major upgrade, and even less for minor upgrades.”
But you have to recompile some stuff don’t you? Most problems with new Python releases are in native modules, not in pure Python code.
There are a number of posts on the speed of python, and its use of libraries compiled from C source.
Python was never meant to be fast. It was meant to be easy to learn, and intuitive to use.
You’ll find if you look that some of the basic libraries are compiled from C and some are entirely written in Python – but this is not of utmost concern to the Python project. Language semantics and idioms are more important than speed.
Of course incremental improvements are not ruled out and over time some of the interneal implementations ave been improved, and in some cases written in C.
If you need speed – and with modern hardware these cases are specific – then you shouldn’t be using Python.
People often find that rewriting cpu-intensive tasks in C and adding interfaces to Python works well – and you’ll see this with number crunching libraries for example (Numeric, for example).
Motto – use the right tool for the job. Python’s design goals are not the same as C or Lua or Java.
This is a fair point, no doubt. Different languages land at different spots on the performance/productivity spectrum. What I’m trying to point out is that the point where Python lands is not a particularly great one in comparison to other stuff that’s out there. If it weren’t for the libraries, ease of learning would be the only thing it’d have going for it, and after all you only have to learn a language once!
I hope Python 3.0 will have a more systematic and well-organized standard library. Unlike for Java, there seem to be no enforced naming conventions.
Moreover, I hope Python 3.0 will be COMPLETELY object oriented, like Ruby but with easier syntax. Currently, it feels patched on in too many ways and makes me reminiscent of C++. For example to open a file it’s “f = open(“text.txt”)” but to close it it’s “f.close()”.
All of these inconsistencies and impurities needed to be eliminated. Although, Python in its current form is already one of my favorite languages.
I hope Python 3.0 will have a more systematic and well-organized standard library. Unlike for Java, there seem to be no enforced naming conventions.
As far as I know, there are no enforced naming conventions in Java either. E.g. nothing in java prevents you from have lower case names for classes,
or name your packages any way you want.
The main difference is that when java was released, Sun tried to educate their new users on how java code should look, e.g. by supplying plenty of code examples.
Other than that letting the language enforce naming conventions is a good idea, and I really would like to see it in Python.
How the file thing an impurity? open is a constructor that returns a file object. File objects support close methods.
You could have something like:
f = file()
f.open(…)
f.close(…)
but that’s just longer for no reason.
Constructors are inherently non-object methods, for obvious reasons!