-
Personally, I use all of those features. Except print >>. Well, I haven't done a zip import yet, but it doesn't matter to me that it exists.
New style classes are great. Old style classes were naive and simple, but seriously lacking for serious development. Old style classes didn't scale through a project's development, because you could get yourself into binds that were infeasible to escape from without changing the API.
(I will agree, though, that super() is so ugly as to be nearly unusable.)
Of course another, more elegant language is possible. One that solves Python's problems elegantly, in a unified way, without turning the resultant programs into black magic. But of course the language is only a piece of it, the library -- both standard and not -- is much more interesting, and represents more of an investment than the implementation. People are pushing forward with implementations, and as they do so they are finding issues. Decorators would have made sense for Python 2.2, but we've waited a long time, because it's taken a while for the tension to build up, for people to actually use new-style classes and start to be annoyed with them.
It should be noted that these recent developments have been pushed by people in the community who are serious Python programmers. These suggestions aren't coming from people who want Python to be like their favorite (or most familiar) language, or people who have a chip on their shoulder when it comes to some particular style. That would be pretty concerning, but it isn't the case. PHP is an example of all the wrong features, and the wrong driving factors, and a weak leadership. Python isn't going the way of PHP.
But I do worry that @ will become another print >>.
-
"Old style classes didn't scale through a project's development"
Really? I've never used new-style classes in production code, and I've been working on some really large systems. The object model has never been a problem.
-
Hm, I somewhat like most changes introduced by 2.4, but I'm realy unhappy with the decorator syntax.
@something is ugly and unpythonic imho. Don't know if anybody has mentioned it, but I'd go with the decorator-block syntax, easy to spot, easy to read, and saves lot of typing.
decorator require_int:
def foo_has_been_decorated( a, b ):pass
def bar_too( a, b ):pass
-
what are function attributes and rich comprehensions?
-
I meant rich comparisons. A description can be found here:
http://www.amk.ca/python/2.1/
-
rich comparisons are bad? I don't think so, maybe they're partially redundant, but not so much.
Th same goes for booleans. True has to be true and not amn integer. Trying to consider a boolean like a strange number is plain wrong and is just a dumb derivation of C. I plaude the choice to add booleans.
What I feel like overcomplicated are the various dirty tricks like __slots__ , _metaclass_..
And especially `this`. It is useless, it mimics something that existed in the scripting world for decades but with a different semantic.
I *never* saw someone using it in python.
And >> it's plain broken, it's just a PITA that print is defined as a keyword and that trick is just something withouth any logic. Oh, and did I mention that the whole descriptor thing is mad? I mean, people where able to use python for years withouth this. Other languages scratch the itches that generated descriptors in really simple ways.
Oh, and adding list comprehension at the same time generators where added makes no sense. Now we have generator expressions.
Oh, and someone considered that sum() is completely useless given the existence of reduce() ?
But OTOH you have to consider that adding stuff *is* pythonic. We could live without the misteryous {} literal for dicts, or [] for lists. And especially for complex numbers built in. They could have just been libraries, but python is madethought to work in a different mood
-
With regard to the design and introduction of new functionality, the new-style class stuff is definitely the most worrying area, not because it doesn't address issues of concern - I'm sure better treatment of multiple inheritance, properties, and various other bits and pieces are very useful - but because it also attempts to address issues of increasingly marginal interest whilst leaving existing mechanisms in place: consider descriptors and the resulting mess of attribute access methods; consider metaclasses. I imagine rich comparisons and the heap of comparison methods that now exist (but are presumably rarely used) are the result of a previous process of enthusiastic lobbying, persuasion and enhancement.
It's a surprise that anyone has been able to get near to implementing Python using other technologies with all this going on.
-
do the features added since 2.0 make Python a better language?
Yes. Glad to be of help :-)
-
I agree with most of what you said, though I think that the new style classes were a step in the right direction, and find the bool type to be quite useful in terms of code readability.
What I'd *really* like to see, prior to there ever being a Python 3.0, is for the libraries to become more consistent across platforms. Especially where Win is concerned but in some cases Mac as well, the *capability* is there but it has not been implemented. Things like named pipes, process control, curses support.
Of course, this smacks of "code maintenance", and as we all know, code maintenance is "boring". Implementing new features (whether anyone wants it or not), is "exciting".
At the moment, though, you stand a 50/50 chance of your code being migratable from *nix to W32 if it does anything with the system. That's just not acceptable. I shoudn't have to use something like the Twisted framework for IPC on Win, not when it's baked into the kernal.
-
Because of their complexity, I was skeptical of the new style classes. Old style classes can be explained to a competent Java or C++ developer in about ten minutes flat.
A few years on, I'm actually using new style classes everywhere in my own code, including little excursions into meta-programming, where it makes my code easier to read and maintain. My code also sprouts class methods and static methods, because this often makes more sense than creating a standalone function or a whole new class.
So, yes, some of the features added since 2.0 make my code better, which makes Python a better language.
As for the "got along just fine" argument - I refer you to my updated version of the Four Yorkshiremen sketch
-
You don't have to use any of the new features, really, except maybe for lexical scoping, which IMHO is good. I hate to say that, but this is just whining.
Besides, who said that corner cases shouln't be taken care of elegantly?
-
Python has a very healthy process of extension - PEP, discussion, first implemention, test run, discussion over discussion.
Most living systems grow and change - humans, relations, societies, languages.
("most" = all I know)
To "freeze" them would be unnatural; and the language would die - as every system stopped from changing dies.
-
Odd then that some established figures in the Python community seem to regard the decorator process as a "beware of the leopard" situation.
Personally, I'd like to see more work done in the library area rather than increasing the complexity of the language. C++ took a popularity hit from Java (and is clearly going to take another from C#) because library standardisation wasn't a priority. And while the complexity connected to current improvements to Python may be reduced over time - ie. when Python 3.0 is released and old-style stuff is deprecated - the language risks a Perl 6 situation where the grand unveiling is likely to be regarded as a far off mythological event.
Python is an amazing language, but its popularity depends a lot more on the availability of quality libraries and packages than it does on the existence of checklist features from "language shootout" comparisons.
-
Hi,
I'm not a Python gur but I've been enjoying that language for almost two years now and I must say that main concern with this language (which is by far my favorite of all I've tested) is its community which is not always as supportive or friendly as you could think og regarding the language itself.
When I read the mailing-list or go on the IRC, a lof of people (among those who claim to be gurus) are plain rude regarding newbies or mid skilled.
IMO, this is main weakness of this language, its community which is only friendly with you when you know stuff. I found that most people dealing with Python think highly of themselves and this is a pain. I hardly asked any questions any longer.
For instance, go on IRC and ask why new style of classes are better and a bunch of people (I don't really care who they are) will shoot you as if you were dumb, but I'm sorry I don't really see why we should throw away old style classes since they are still really good in most cases.
This is the only reason I would leave Python... its community and arrogant people.
Just because Guido might be rude sometimes regarding his choices doesn't mean people in the community must follwo that path.
This is sad and I do know a lot of people who finally went to Perl just for that.
-
"""[...] main concern with this language (which is by far my favorite of all I've tested) is its community which is not always as supportive or friendly as you could think og regarding the language itself.
When I read the mailing-list or go on the IRC, a lof of people (among those who claim to be gurus) are plain rude regarding newbies or mid skilled.
IMO, this is main weakness of this language, its community which is only friendly with you when you know stuff. I found that most people dealing with Python think highly of themselves and this is a pain. [...] """
A strange story. You are entitled to your opinion of course, but the Python community is usually praised as being very friendly and supportive, especially to newbies. I haven't seen the behavior you describe in the Python newsgroup (although I've seen it in newsgroups for other languages). Sure, there are rude people everywhere, but they don't seem quite as common in c.l.py.
Can't speak for IRC, I usually don't go there. It does attract a different crowd though.
"""This is sad and I do know a lot of people who finally went to Perl just for that."""
To be honest, I don't know of anyone at all who made that switch. The other way around, yes.
-
"""You don't have to use any of the new features..."""
No, but I'll have to learn them, because I will encounter code that uses them, written by others. I don't object to learning new features... I object to a language that was once small and elegant becoming more and more complex, tacking on more and more features of dubious benefit. Python is still far away from being unwieldy, but it's slowly moving there, and it's that process that worries me.
-
Ok I may have been a bit rude and I don't want to digress too much.
I don't want my words to be misunderstood, I don't think that everybody in the community is bad. A lot of people are friendly and supportive but I meat also quite a big trend of thinking that "Python is the language that will save the world" and I was a bit sad about that.
By rude I mean, I saw many replies in the last year from newbies asking (I agree the same dumb questionsas did) who pay the price of that sillyness.
Regarding IRC, one example. A year ago I was looking for some information about unicode and I was struggling with it. I went on #python and ask some questions (certainly dumb) and the only people who replied were really rude. Which is funny is that one guy whos a newbie talked to me on a private message after that and told me he was quite "afraid" to ask any question on that channel since it was most of the time the same reaction. Then I went on #perl since it was more a generic question not related to a language, guys there were really cool and did help me.
I mean, OK, it might a one time issue but I have talked to many people who don't go anymore on #python since it is just a show off.
I'm not talking about the language here but people behind and I still do prefer Python to Perl.
But well maybe it is just me then and I walk away :)
Forget it.
To come back to the technical discussion, I agree with many people here when they say that the guys who work on Python should focus more on stabilising and improving the library which is the main strength of the language along with its easyness from the beginning.
-
FWIW, IRC can turn people into jerks. Or people can simply be sarcastic, which doesn't work in that medium.
Anyway, as far as scaling, the issue I saw with old-style classes was that you could write yourself into a corner. For instance, you could create a public attribute that later needed to be dynamic. This was probably the biggest issue I saw. Smart programmers never used public attributes, but that's annoying, and it's a waste of a big feature (attributes). There's a number of other situations that can also be resolved with descriptors that previously required weird __getattr__ hacks, or were simply impossible.
Personally I don't know why people are so concerned about the elegant, simple side of Python. Python has never been a minimalistic language, and its syntax is rather eclectic. And this is good -- unformity of syntax is nice sometimes in Scheme, but not actually helpful when reading code. And simplicity is nice for mathematicians, but not that big a deal for actual programmers. Predictability is extremely important, but that's more about semantics, not syntax. I think criticisms along those lines would be more substantive and important than syntax discussion.
-
Just for information, I'm not sure to get what you mean by :
"Predictability is extremely important"
Could expand please?
Thanks
-
A great place for Python newbies is the Python Tutor mail list. There are many knowledgable friendly people who provide the newbie community lots of help.
As far as the creeping featurism, I don't feel like I'm in a position to really comment that much. I'm still a newbie in many ways. So far, I'm lovin' Python. As long as they continue to follow the Zen of Python when they add features, then I'm ok with it.
-
We have an interesting historical example: C programming language. C is still one of the most widely used programming languages. Why? Because it's simple and small.
I cannot tell when the last new feature was added. But C language evolution is based on a simple principle: if you want new functionality, create a library. Why don't we follow this historically proven principle for Python evolution?
C++ could be the opposite example. This is an excerpt from Kernighan interview "When I write a C program of any size, I probably will wind-up using 75, 80, 90% of the language features. In other words, most of the language is useful in almost any kind of program. By contrast, if I write in C++ I probably don't use even 10% of the language, and in fact the other 90% I don't think I understand."
Let's stop to add new language features, why it's not too late!
-
I find many features added after 2.0 not superfluous but extremely useful. I am impressed how powerful features such as new-style classes with descriptors were added with minimal additional complexity.
I'm not saying lets put in every feature we can think of (in fact the Python dev team doesn't consider anything unless there are compelling use cases). However, I have used new-style classes and descriptors to write elegant succinct code that would have been a lot bigger and harder to understand had I used only classic classes and pre-2.2 features.
Also, a clunky super function is better than no super function. Python is getting better. Users just have to be judicious in deciding what features they need and shouldn't use something just because it's cool. But that has always been the case. More power to the developer!
-
I too find many of the new features extremely usefull. I like the fact that Python progresses rapidly instead of the more common Java-esque limbo. I certainly prefer this to the deadness of C, which IMHO is so antiquated it's only usefull for optimization.
I agree there is plenty of cruft in Python, but so far the good far outweighs the bad -- in particular many of the things Hans decries as corner cases I use all the time.
Sets: extremely usefull, often leading to clearer code.
decimal: Used anytime money is involved, and thus very important to have a standard.
reverse iteration: clearer code.
weak references: there is no clean alternative. this is a fundamental ability that is rightly built into the language.
boolean: how can you leave out something so fundamental? C-like boolean parsing just leads to errors, and less readable code.
list comprehensions: I use these all the time.
new classes: better than old; they should excise the old classes.
generators: usefull
static and class methods: klunky, but they should be improved not removed.
rich comparisons: fundamentally usefull, e.g. for Numeric.
Of course there are some things I don't like:
importing from zip files: this is really part of the language?!
function attributes: seem borderline
meta classes: I don't get how these are usefull, although that may well be a problem on my end instead of python's.
Python is now much more usefull than it was in the 1.5/1.6 days. IMHO saying that this progress will turn Python into Perl or Ruby is ludicrous.
-
If decorators will become antoher print>>, why not make decorators like this:
def my_function():
____>> staticmethod
____some code here
This started as a joke, but now i'm seriously considering it as a good solution. The token ">>" could be seen as "statment modifier"!
-
Jasper:
Importing from Zip files -- this was added to the language because it enabled the possibility of putting all the stdlib into a single zip file which could be more easily moved around and so on by virtue of being a single file. Some folks like that; it'd be impossible if zip imports weren't in the language.
Function attributes -- I personally don't have much use for these, but I've seen others do so. Mostly it's a way of marking the function so that other code can act differently on different classes of functions. But I agree it's borderline.
Metaclasses -- metaclasses should never be used. Except when they are needed. And then they MUST be used, the alternatives are just horribly unmaintainable. Including them is a GOOD idea, but they are (wisely) reserved for wizards (or non-wizards who use GREAT care).
-
"deadness of C,which IMHO is so antiquated it's only usefull for optimization."? Hey, Python interpreter is written in this dead language!