What is Pythonic? (2005)
blog.startifact.comI think it's important to think of Pythonic as something that's subjective and evolving.
The C examples given are idiomatic in C. The reason they're idiomatic is because they fit with a mental model that most of the C community uses: data structures in an enumerated address space, and passing around hunks of mutable memory with handshake semantics. If your code interacts with code that was written with that in mind, life should be pretty good.
Python has the same sort of thing, but at a different level of abstraction: objects, frequently enumerated by identity, grouped together by user-defined abstractions, with the understanding that function side effects are rare, unless they're object methods.
Haskell is arguably cleaner / terser, but it's yet another set of idioms. The only thing that makes pythonic Python is that it's used by the rest of the community. It's a shared understanding that's neither better or worse than any other shared understanding.
You can't have this both ways. Either what is 'Pythonic' is subjective and community-based AND your arguments about Haskell are also subjective and based on the Haskell community, or some things are just better than others both within Python and among languages.
But even in the second case, you have to do more than wave your hands around to show that Haskell is superior if you want to move beyond pure, substance-less snobbery. If you did that, you'd find that you were leaning on some assumed values - for example, the values of the Haskell community.
If all you have to say is that Python's values are subjective while Haskell's values are the actually important ones, this is really pure snobbery without any substance.
I don't think trjordan said anything like that.
Nice overview. I think a lot of the tenets of pythonicness are based on the heuristic that there should be minimal cruft and friction between the reader and the code. I should be looking at a reasonably close approximation of my interpretation of the problem. Was it let or var? Semicolon or no semicolon? Was it := or set! <- or <<- ? Squiggly braces or none? Does the second indented line after a non-squiggly block count as part of the block? Was it private static or static private? Does const go before or after the function definition? Does i++ increment first or provide a value first? I should have to think less about any of these things and more about the problem.
Usually, syntax is minimal enough to get out of your way, and where there is syntax, it attempts to be consistent and to enforce clarity.
In most of those cases there's no point thinking of them, just type the first one that comes to mind and move on
I hate poorly styled code. Edit: I don't know why I'm being downvoted for this. That kind of mentality inherently churns out bad code.
They're all inconsequential to code quality except for some like i++ vs ++i which isn't even style, it's syntax. preincrement before, postincrement after, not hard to remember
Syntax and style are tightly coupled in Python. It's not hard to remember i++ is the same as i+=1 or that if(bool) { can optionally have a line break between the guard and the brace. In other languages, you have more choices. If you have more choices and just type what comes to mind first, you're going to get stylistic inconsistencies.
I submitted a related link before - Unpythonic Python
The article mentions Zope quite a bit - which was a big thing for a company I worked for in 2001 (Loudcloud), as we had a number of customers that wanted to use it. Whatever happened to Zope? Wikipedia seems to suggest there hasn't been much development in the last 4 years - anybody know?
Zope the framework really fell out of favor. Some of the good bits were pulled out and built into Repoze.bfg, which later merged with pylons (used by reddit etc) to become Pyramid.
We might be in the "post-pythonic" Python era. There was a discussion a few months back on #python to the effect that judging "pythonic"-ness was a shibboleth indicating the judger was not the best Python community member. Wish I could find a log.
I have a lot of love for python but when I want to achieve something that is easy in other languages but not available in Python because "thats not Pythonic" for some reason I think Stockholm Syndrome.
Functional is the new pythonic!
(edit: It actually is, half of the good things in Python, like list comprehensions and tuples and destructuring, were first seen in functional languages!)
BDFL Guido van Rossum is not in favor of adding functional programming stuff to python. So, by fiat, functional programming is not very pythonic. :)
You are both partially right. List comprehensions are considered pythonic, and they are similar to map and filter from the FP world. However the map and filter functions themselves are somewhat unpythonic.
I guess list comprehensions in Python are, as you say, similar to map and filter from the FP world, but they are even more similar to... list comprehensions from the FP world.
"unpythonic" once again meaning "disliked by van Rossum."
Half the good things in any halfway decent language are also seen in any other halfway decent language.
(2005)