Submitted by Guido van Rossum, the creator of the Python programming language, has published on his blog an interesting status report for Python 3.0 (‘Python 3000’), the upcoming major revision to the language scheduled for mid-2008. He discusses the rationale for redesigning the language, syntax changes, new features and libraries and inter-compatibility issues.
fix the problems with the language before it gets worse. developer got 2.6 to buy enough time before full transition to 3.0.
I’m glad that they’ve allowed for optional typing, it’s especially nice how they’ve rolled that into their annotation/decoration system, makes far more sense there.
I regard Python as great. A decade ago I was using it to do scientific computing .. and it made prototyping easy. Since then I’ve used it for a whole range of tasks, from network services to image processing.
Different languages are suited to different tasks. C for low-level systems development, J2EE for high level “business logic”, and so on. Python has its strengths but seems to applicable quite widely too.
For anyone new to python I would say this – many people say that the leap from the idea in your head to working code seems to require the smallest translation with Python. Users also remark that they find they don’t need to do syntax debugging as much – code sometimes even works first time!
My own wish is for the class namespaces to be cleaned up. I hate “from package.abc import *” … or “from package2.xyz import as def” … that’s seriously anti-python .. its inelegant, it a cause of serious errors and clashes. And scaling across systems and coders is made much more difficult. I prefer the stricter Java namespace naming but would love the inventive Pythonistas to come up with a suitably elegant solution.
I wished they could re-consider the “white space matters” idiom. That’s the only reason I am not using Python in my day-to-day work.
It’s kind of odd how some people can’t seem to get past that.
When I started using python, the white spaces bugged me a bit (most likely from other places where white spaces can be problematic, like makefiles)
I got used to it pretty quick and today I don’t consider it a drawback at all.
I know that my (and other peoples) code will be properly indented and I don’t have to put any form of begin/end markers.
I can’t easily do one-liners like in for example perl, but that’s the only drawback I can think of.
Do you think it’s a practical problem or is it just that you don’t like it?
It’s kind of odd how some people can’t seem to get past that.
When I started using python, the white spaces bugged me a bit (most likely from other places where white spaces can be problematic, like makefiles)
I got used to it pretty quick and today I don’t consider it a drawback at all.
It can be a drawback because python’s use of white space makes it extremely difficult to do command line things with it.
It’s strange that the original Python developer had years before stated that the current whitespace requirements were a regret (I don’t remember exactly what the alternative was, though it was not as far as C-style syntax), yet did not address them in his blog post.
I think it is a practical problem, not necessary with the language, but perhaps with the tools we have today.
Let me explain, I quite regularly code in several different code editors (varying between common text editors and common IDE’s) on different operating system. The problem I see when switching editors is that the white space indentation will more often than not be mis-aligned.
This often occurs in GNU/Emacs, switching from Emacs to other text editors, and the indentation is mis-aligned.
Don’t mis-interpret me too much here, I am very, very picky with how my code is indented, otherwise I can’t cope with the code on a professional level.
And if it didn’t use indentation someone else would complain about whatever it used instead.
Either you live with it or Python isn’t for you.
If they dropped indentation in favor of explicit block markers, maybe they could implement first class functions instead of these lambda expression with a kludgey syntax.
But anyhow, what can you expect when people brandish the lack of braces as a selling point right at the beginning of the tutorial: http://docs.python.org/tut/node3.html
“make shorter programs because you don’t need braces around blocs”. Brilliant. The relevant thing is expressiveness, not removing punctuation. They should forbid blank lines as a next step, to make programs even shorter.
By the way, can any python buff explain me what is the difference between tuples and lists? I still can’t figure what it is and why both of those things have to exist in the language.
Edited 2007-06-26 15:20
But anyhow, what can you expect when people brandish the lack of braces as a selling point.
A better selling point of that is actually: Braces are there for machines, humans go by indentation anyway.
I really have no strong feelings about it. If they decided to add an end marker, I wouldn’t complain. But I don’t find it a big enough problem to worry about. Maybe I need to copy-paste more.
By the way, can any python buff explain me what is the difference between tuples and lists?
People sometimes use the tuple as an immutable list, which isn’t the point really.
You could read this, maybe that will clear it up a little:
“Tuples are for heterogeneous data, lists are for homogeneous data.”
http://mail.python.org/pipermail/python-list/2003-March/194177.html
I don’t think the intent has been communicated very clearly and since tuples are the easiest way to make an immutable list, maybe it shouldn’t be enforced either.
“maybe they could implement first class functions”
What’s a “first class” function? “def” isn’t good enough?
Why are braces better?
I hate braces and semicolons, why don’t C/C++ get rid of those so that I can like it better?
Whine whine whine.
“can any python buff explain me what is the difference between tuples and lists?”
Tuples are immutable, lists arent’
Do you think it’s a practical problem or is it just that you don’t like it?
Whilst I like python and use it a lot both at home and at work, I have definitely had problems resulting from this. The trouble is that as soon as the indentation is damaged, either by someone using an editor that is configured to use hard tabs or by copying code to another place (eg. to move it into a function) then the semantics of the code are destroyed. I can live with this, but I think the people who are claim ‘there is no problem’ are just burying their heads in the sand.
While I have broken code in the ways you describe, it is never really hard to fix. On the other hand doing this forces you to re-format your code consistently and thus improving readability.
I find it very annoying to read C or Java code where the indenting and bracketing changes halfway through because they copied in code from somewhere else or something like that.
On the other hand doing this forces you to re-format your code consistently and thus improving readability.
I am a lazy programmer. I don’t want to be forced to do anything!
I just hope no one forces me to maintain your code.
No, but I might pay you to…
The trouble is that as soon as the indentation is damaged, either by someone using an editor that is configured to use hard tabs or by copying code to another place (eg. to move it into a function)
Yes, those might be problems. An editor that isn’t python-aware, can mess things up for you, so that is something to watch out for. I haven’t really seen those problems myself, but it might be a bigger issue than I realize.
Copy-paste bugs, I have had. Unittesting catches almost all of those for me. Even if there was no risk of error in copy-paste, I’d still not feel comfortable about code that didn’t go through unittesting, so for me that’s not additional work.
Yes, there are situations where those are real problems. But there are also ways to avoid most of those situations.
I’ve coded in Python since 2002. I love it. It’s fast.
+1 on this. My 2 favorite languages: Ruby and Python.
I agree. I picked up Python in mid-2005, because it was the scripting language of choice at my new job. I had been using Perl as my scripting language, and resisted the change, but after a couple of days of using Python, I got used to the indenting and lack of braces/semi-colons, and now I much prefer Python over Perl.
Just my own experience and preferences.
I completely agree.
Having been bitten by this bug in python a number of times I just gave up on it. I was just wasting time fixing tabs and burning up all the benefit that a scripting language is supposed to give.
I won’t use it until they add “end” constructs or { } semantics.
Each method declaration starts with def foo(self,…
which I find ugly..
You might think it’s a bit ugly, but it’s hard to solve some of the things you can do in Python without it.
Also, I suspect it’s tightly connected to how methods are called (self.<method>)
One example of things that could be difficult to achieve without explicit ‘self’ is adding a method to an already existing class. As it is now, it’s very simple, partly because of ‘self’:
class A(object):
__pass
def m(self):
__print self.__dict__
A.m = m
A().m()
(leading spaces replaced by underscore, since writing code here doesn’t work too well.)
In short, I’m willing to type an explicit ‘self’ if the only alternative is giving up clarity or features.
Originally, I too found the use of ‘self’ as a bit of an ugly hack, until I delved more into the way Python worked. Off the top of my head, the two other ways of giving the same functionality, without having the first argument be set to the instance the method was called on (naming that argument ‘self’ is really just a convention, and is not required), you could add a variable called ‘self’ to the namespace of the method, or simply check if an identifier is referencing something on the class before resolving it to local variables and then global variables.
The first alternative I would consider to be an even uglier option, and it would be almost antithetical to the way Python works (non-pythonic).
The second option automatically removes from the local namespace any identifiers currently referring to an object contained by the instance. If that were not bad enough, because Python is highly dynamic, code in many places can add, remove and change objects within an instance. Debugging code under this type of identifier resolution would be a nightmare.
Additionally, the method currently employed by Python allows functions and methods to exist largely as the same type of object, with the code that deals with calling a function in the interpreter making the distinction. (In reality a method object is more of a wrapper for a function object.) It also allows the identifier resolution system to be much more “pure”, in that an attempt is made to resolve it to the local namespace first, then (in the case of nested code) the namespace of the containing function, and finally within the global variables.
From the article: “Python 3.0 will break backwards compatibility. Totally.”
So, to use P3, you have to throw away a decade’s worth of work. I’m not convinced that is a good idea.
Consider that PHP 4.x is probably still more widely used than PHP 5.x. After what? Five years? And I don’t know if PHP 5.x *totally* broke backward compatibility.
So, to use P3, you have to throw away a decade’s worth of work. I’m not convinced that is a good idea.
That’s why there will be a Python 2.6
Your decade’s worth of work won’t be using the new features in P3, so if you just want to keep using the old code, no problem.
If you want to mix new code with your old one, there’s the helpful tool to fix the code for you. So far only found here:
http://svn.python.org/view/sandbox/trunk/2to3/
But yes, there will be a little bit of extra work.
Edited 2007-06-26 14:42
“So, to use P3, you have to throw away a decade’s worth of work. I’m not convinced that is a good idea.”
Python breaks compatibility in a good way. It falls halfway between PHP and Perl. PHP is a hack language and has so many design errors that they have to constantly break things to move the language forward. They have to change things because they don’t bother to think about things two weeks in advance. Perl on the other hand, is a very well, thought out language. However, it didn’t bother to break backwards compatibility during its lifetime. This has made the language unnecessarily complex. In addition, when Perl 6 comes out, things will be broken in a very, very bad way.
Python falls somewhere in between. A lot of time is spent on adding/designing features properly so very little change is usually necessary. In addition, when a new version of the language comes out, you are either able to use the new syntax in the older release or import new features into the older release. For example, when 3.0 comes out, the majority of features will be mixed into a 2.6 release. So you could actually slowly change your code structure to match the new code structure without breaking your program and when you are ready to move to 3.0, you will be simply able to do it.
And in all truthfulness, the changes are not as disruptive as PHP. In Python, you will be going from an OO design to a more refined OO design. OTOH, in PHP, people were asked to move from a hacked together PHP 4 procedural language implemented website that lacked any sort of design to a hacked together PHP 5 object oriented language website lacking any sort of design. That is a very difficult task.
“So, to use P3, you have to throw away a decade’s worth of work. I’m not convinced that is a good idea. ”
Or you could just continue to have 2.x installed along with 3.x.
Using ‘self’ is just a convenient convention – you could just as easily call it ‘me’. The reason is so you know which _instance_ of the class is being used. It didn’t start with Python, but it works very well for it’s design purpose. If that’s your only problem, then I guess it’s gotten to the point of ‘only thing left is nitpicking’.
As far as breaking compatibility – sometimes you just have to break legacy to fix problems. At least in non-MS worlds, it’s easy enough to keep both v2 and v3 on the same machine and have both versions running at the same time until you decide to convert over to the new version.
(I’ve had to fix a few PHP scripts because of v4/5 incompatibilities, but hey, that’s how progress goes {g}).
Why do you explicitely need to write “self.” whenever you want to access a member variable? This is just useless noise.
Many companies have some kind of coding standard that enforces explicit usage of ‘this’ in C++/Java.
Apparently, they don’t think it’s useless noise.
I think I prefer the explicit ‘self’ over the C++/Java compile-time warning about name hiding when you use local variables with the same name, but I guess it is a matter of taste.
Many companies have retarded coding standards. Standards are usually elaborated by bureaucratic f–ks and are not a useful metric to determine whether doing things in a certain way is good or not.
For instance, I know of a big french company whose standard forces you to declare all variables at the beginning of functions in C++, which renders one of the most useful patterns of the language (RAII) impossible to use.
A common convention is to prefix member variables with m_, which solves the name hiding issue just as well and is much less ugly than “this->”.
Edited 2007-06-26 18:50
Many companies have retarded coding standards.
True, but I’m not sure that’s one of them. There is some value in being explicit.
A common convention is to prefix member variables with m_, which solves the name hiding issue just as well and is much less ugly than “this->”.
Yes, and if I see a variable called m_x, myX, x_ or some of the other common naming standards I will know that it’s a member.
If I don’t see any of that, then maybe it’s just public member and the coding standard doesn’t apply to anything public. Or maybe there isn’t a standard at all. Or someone just isn’t following the coding standard.
When I see this->x or self.x, I know for sure. There’s some value in that. But I would be happy with a way of knowing that took less typing and looked nicer. I’m afraid my traumas from working with perl makes me cringe at the Ruby @x notation, although it probably is better…
“Many companies have retarded coding standards. Standards are usually elaborated by bureaucratic f–ks and are not a useful metric to determine whether doing things in a certain way is good or not. ”
Good thing we have you here to tell us exactly what standards and syntax python should use, eh?
Don’t like “self”? Don’t like indentation? Be a man and stop whining.
I don’t like Perl but I don’t see a need to whine about that every time there’s a post about Perl (or some other language I don’t like) on osnews.
python supports optional curly braces. you just have to activate it using
from __future__ import braces
-tomer
into c would boost speed.
i think this discussion is going off tracks. syntax is important, and reducing visual noise means it’s easier to read, debug and write (“code is being read much more often than it’s being written”), so that, imho, makes the python syntax almost perfect. of course people will whine about the missing curlies and semies, but you’ll learn to forget them in a couple of days and then, suddenly, it would strike you how fun it is without them.
but that’s just syntax. it’s not *that* important. imo, the most important thing in python is the “zen”, especially the “there should be only one way to do it” part. that’s the biggest philosophical difference than separates python from other languages. and that’s why i like it so much.
whining about the syntax is very superficial. if you want to whine properly, at least challenge the “big fish”