Cohesive? Python is a wonderfully simple language, but it also has (or had) a lot of old misfeatures from early designs that weren't cohesive, and I think this has improved. String methods, the iterator protocol, exceptions as classes (journey into the comp.lang.python archives for constant "why doesn't except 'foo' catch raise 'foo'? -> because 'foo' is not 'foo'" questions), and so on. There are many aspects of the language that have gotten cleaner, more cohesive, and simpler as the language has grown up. We can subclass from 'list', have computed attributes, and so on. There's a lot that has been enabled in recent versions of Python that make it easier to write more cohesive code. From SQLObject to Django, to Zope 3 style Schema - all of these now allow complex fields to be defined in regular class statements in the 'a = b' format. Older code tended to need them to be in lists or dictionaries. I have reams of old Zope 2 code that has Formulator schema defined as such. I see old SQLObject code and cringe. Doing '_columns = [StringCol('foo', ...)]' is uglier than 'foo = StringCol()'. Move to another tool doing something similar, and they'd do it in a slightly different way. But now, a lot of those systems can do the 'a = b' style in a class construct that wasn't easy to do in older versions of Python. It makes using all of those systems easier because there are less concepts to have to learn as a developer.
Maybe Python was just easier when it couldn't do as much? Like when it really required hacking with the object system in order to get persistence (Extension Classes, I'm looking in your direction)? It was things like that, which Zope required to run, that made it hard to use tools like 'epydoc'. It made it harder to install Zope as a library and just use parts of it. That's changed with Zope 3, and a lot of that has been made possible by improvements to Python itself.
I think that most of the changes to Python have been for the better, and have allowed Python to clean up it's older, simpler, and less cohesive early designs. I've really enjoyed the language as it's matured. I don't use generators every day, but I'm damn grateful they're there when I need them. I can't say how happy I am the iterator protocol is around and I don't have to write __getitem__'s that deal with both random and sequential access - this was a very annoying issue on a project we had a few years ago. "If the __getitem__ key is a string, they're using it mapping style, so raise KeyError. But if it's an integer it's probably a loop so raise IndexError..."
I'll take the growth. I think it's done in a balanced way.
Change is unpythonic
Posted bymorphexat
2005-11-08 12:36 AM
For me, I think code that's hard to read and hard to do one way is unpythonic, as python had a good design that I certainly got used to using in a certain way. Using map, filter, lambda and so on to handle sequences is something I've grown accustomed to.
Seeing list comprehensions like this for example
print [(i,f) for i in nums for f in fruit if f[0] == "P" if i%2 == 1]
doesn't remind me of anything pythonic. That should be block of code, not a one-liner.. having several if statements on one line does not make it more readable IMO.. It's also not good that there are changes to the language that deprecate certain features - sure, the old features will go away some day, but when? How long will we have multiple ways of doing something? And what happens to the promise that Python will be backwards compatible? Do we end up with one big ball of mud, like lisp?
Maybe Python was just easier when it couldn't do as much? Like when it really required hacking with the object system in order to get persistence (Extension Classes, I'm looking in your direction)? It was things like that, which Zope required to run, that made it hard to use tools like 'epydoc'. It made it harder to install Zope as a library and just use parts of it. That's changed with Zope 3, and a lot of that has been made possible by improvements to Python itself.
I think that most of the changes to Python have been for the better, and have allowed Python to clean up it's older, simpler, and less cohesive early designs. I've really enjoyed the language as it's matured. I don't use generators every day, but I'm damn grateful they're there when I need them. I can't say how happy I am the iterator protocol is around and I don't have to write __getitem__'s that deal with both random and sequential access - this was a very annoying issue on a project we had a few years ago. "If the __getitem__ key is a string, they're using it mapping style, so raise KeyError. But if it's an integer it's probably a loop so raise IndexError..."
I'll take the growth. I think it's done in a balanced way.
Seeing list comprehensions like this for example
print [(i,f) for i in nums for f in fruit if f[0] == "P" if i%2 == 1]
doesn't remind me of anything pythonic. That should be block of code, not a one-liner.. having several if statements on one line does not make it more readable IMO.. It's also not good that there are changes to the language that deprecate certain features - sure, the old features will go away some day, but when? How long will we have multiple ways of doing something? And what happens to the promise that Python will be backwards compatible? Do we end up with one big ball of mud, like lisp?
Replies to this comment