
I don't like Python. Does that make me a bad person? - thedigitalengel
I don't like Python.<p>I love C. I like C++ too. I used to write a lot of Java when I was a kid (as in high-school kid) but now that I've written quite a bit of C and C++, Java seems more like a toy language. I did enjoy Java back then, however. I yet to do any major work in C#, but it seems to be a powerful language, especially when handling certain kinds of complexity.<p>I've been learning LISP on weekends for two weekends now, and I find it interesting. I know little bits of Haskell (am planning to learn it later this year) and seem to like it too. Maybe I like the idea of liking Haskell, I'll know for sure once I actually start writing Haskell.<p>Coming back to the point - I don't like Python. I've never liked it. I've tried working on various Python projects but have always found some or the other excuse to prematurely back out. And mind you, I love coding - I spend most of my time writing code or learning new stuff about code.<p>My question to the hardcore python lovers is this (and mind you, by hardcore I mean the kind of people who wrote Exaile, not the kind who hack up a Python script every now and then to organize their iPod): No doubt many of you have come from C / C++ / LISP backgrounds. What is the paradigm shift you experienced? I look at a piece of C code in a certain way - how do I look at a piece of Python code? How do I think about Python? How do I think <i>in</i> Python (copied that one from Bruce Eckel)?
======
amix
Yesterday there was an interesting link on HN comparing NLP in Python vs.
other languages: [http://nltk.googlecode.com/svn/trunk/doc/howto/nlp-
python.ht...](http://nltk.googlecode.com/svn/trunk/doc/howto/nlp-python.html).
I think this article shows the clearness of the Python language - - and this
clearness and simplicity is the reason why I love to code in Python.

~~~
thedigitalengel
I agree that short python samples are as clear as a high level language can
possibly be. Implementing algorithms, for instance, becomes incredibly easy in
Python. I face problems when Python programs get above a certain length.

I've done some Django programming in the past. A view gets a request object
(pardon me if I'm wrong or if this has changed recently) and is supposed to
then render the response (or something similar, I don't remember exactly). Now
what is a request? If Django were in C, I would know _what_ a request object
really was, grep for it, and look up the header file. If request has a
GHashTable named post_data, I don't think I need two guesses about what it
exactly is. Same goes for C++ and C#.

Then you've inconsistencies. The same method may return a string object or an
integer on different calls. And this happens in practice - I remember when I
was (trying to) model a relational database in Django, I found a ManyToMany
field returning (when invoking values ()) a list of dictionaries instead of a
list of Model objects (which I was expecting).

Of course, if I was not dumb enough to not read the documentation I might not
have stumbled; but the point is that Python _allows_ this to happen. And since
I don't have the benefits of a compiler, anything other than basic syntax
errors (the ones I can catch by calling py.compile) explode at runtime.

The thing I've begun to notice that scripting languages tend to require you to
hold the entire structure of the program in your head as you code. In C++ you
know that unless you've gone out of your way to do some casting magic, a
string get_foo () will _always_ return a string. And you can _always_ do
get_foo ().c_str (). In python you're never sure.

~~~
duke_sam
You seem to be complaining that when using a language new to you in
combination with a large framework written in that language you would have
been forced to read the (very good) documentation to figure out what was
happening.

The inconsistencies you mention are (in a well written code base) very rare.
If you call a method get_name() odds are you are going to get back a string.
If you seem to randomly get back an int or a dictionary or a datetime object
it's a pretty good sign the code is foobar'd. Good Python programmers don't
abuse the dynamic nature of the language. Methods should return predictable
types (documentation is important), it might return different types depending
on the input but this should be documented and obvious (say a parse date
method that returns a datatime object if you pass it a string containing a
date and time). The values() example you use is very clearly documented as
returning a ValuesQuerySet that supplies dictionaries not models
([http://docs.djangoproject.com/en/dev/ref/models/querysets/#v...](http://docs.djangoproject.com/en/dev/ref/models/querysets/#values-
fields)).

In a number of years using python, the standard library and 3rd party
libraries I've never been left wondering "If I pass X to this method what the
hell type am I going to get back". Just like in C/C++ I need to remember it
returns a list or a string or a dictionary but that's usually where the mental
overhead stops.

Python is dynamic which means it's flexible. Flexibility is usually reached by
sacrificing simplicity so Python encourages testing and good documentation. I
would argue that these are both necessary features of any good code base,
Python is just more upfront about this than a number of languages.

~~~
thedigitalengel
I'm not really not complaining about anything - the shortcoming clearly lies
within me and not in Django or Python.

The purpose of this thread was merely to gauge what kind of paradigm shift
people who were used to programming in C or C++ generally experience when they
move to Python. Some people seem to find making the jump easier than others -
I personally have found it difficult and have made little progress so far.
Since I generally consider myself good with computers, I find this a little
unnerving.

------
gte910h
I'm a guy from a C/C++ background who did linux kernel development, and picked
up python along the way and used it to do desktop tools. I used python
(without knowing any of it) to write a disassembler for a project I was doing
in 2003 on a non-x86 processor. It took me 5 days to learn the language enough
to do so and to write the entire tool, at which point I "got it".

First off, Java isn't a toy language. You've characterized it improperly. Java
is a bureaucratic language. You have to cross your t's dot your i's, fill out
your requests in triplicate at the FactoryFactoryFactory to get the
objectOfYourDesire. Why is this so?

This comes back to how C++ works on projects, especially large projects and
midsize projects with a couple mediocre programmers thrown in (because, in
commercial software development, you rarely get control of your team). C++
does not work well for large team development unless 1> You have very capable
people 2> and you can fire everyone who steps outside the "defined okay
subset" of C++ you use on the project. The language is too big, certain parts
make it too uncertain, etc, for people to just willy nilly use all the
language features. So Java, is basically Sun's "redoing" of C++ where they
took its wild west nature, and made a BureauDisney version where you can't do
a dozen things that happens in C++ all the time when good programmers go off
the reservation or bad programmers enter the equation at all.

C++ has uses, but it's the sulfuric acid of programming languages: you have to
have good personnel control and fire those who screw around outside the
boundaries of the right style. A programming group with one guy programming
like C with classes and another guy programming like it's Ocaml without
garbage collection, and you're in for a mighty piece of hell.

So that's where Java came from. That's why it is what it is, and I hope I've
highlighted a non-business issue with C++ that comes up from it's
overabundance of "understanding breaking powers" which don't mess well with
total programmer freedom.

Now lets look at what python was, and what it is now: Python was originally
designed as a substitute for the pascal/BASIC line of programming languages
(specifically a language called ABC). It was designed to be very very clear.
It still _is_ very very clear. It is still quite terse compared with
C++/Java/C, but it's wordier than perl and ruby, but very much clearer for
even non-python programmers to decipher much of the time.

Over time, it grew into an Application development and webserver development
language. Why?

It has a very easy way to interface to C code. This is important, because C
does great module level integration, but once you get at the system level, you
start to get issues with namespaces, tracing bugs, etc. So python became an
alternative for tying C code together.

It writes very quickly. While you may not understand how to write it quickly
yet, usually python/ruby/perl will be quite a bit more productive on a feature
basis than Java/C#, and tons more productive than an equivalent C/C++ project.
This has to do with the fact it takes very few lines of these languages to "do
a job".

For you currently, you're possibly less productive in python right now than
you are in C++; I've honestly found this doesn't hold true more than 40-80
hours into learning python development while doing a real project for almost
anyone who can handle commercial C++ software development. The C++ people do
python faster than they do C++ and it has many fewer issues in the end than
C++ they would have wrote. We use weave.inline or something else to speed up
the inner loops with some native C, if even required for that application, and
all is good, it works just as fast for the user or application, and was
completed much faster with much less obtuse bugs.

If you spend those 40-80 hours on the language, you too will likely be a
faster developer in python than C++ for many features.

Some tips: You are not doing C, you are not doing C++, you are not doing Java.
Don't pretend you have to do the bueracracy that those languages require. If
you write a python program with absolutely no functions, it will run just
fine. So if all you need to do is process a small amount of text or open a
little server, you can do this in a flat file with just a series of lines of
code striaght out of main() in a C program. However with the size and
completeness of the python standard library, you'll rarely have to write the
rest of the functions.

Secondly, it's important to learn idomatic python today. If you write things
like "it's supposed to be" in python today, you get speed on par with C/Java
(or only 3-5x slower), and it's really freaky to see an interpreted language
do that.

Thirdly, it's important to _learn and use the standard language rather than
writing code_. Python module of the week blog is a great resource to do this:
<http://www.doughellmann.com/projects/PyMOTW/> Much of python's power comes
from a stupidly complete standard library that does much of what you need to
do so allows you to write 20 line programs.

Lastly, learn _easy_ ways to fall back on C/C++ in python. This way when you
use python for an application it turns out it's too slow for, you can still
add a bit of C/C++ to get the speed you need. You can embed C++ inline and
have it compiled on the fly with weave, so I suggest you learn that.

<http://www.scipy.org/Weave> for getting it

<http://www.scipy.org/Cookbook/Weave> for examples of use

<http://www.scipy.org/PerformancePython> for examples of how fast this runs vs
other things.

~~~
japherwocky
""" Java is a bureaucratic language. You have to cross your t's dot your i's,
fill out your requests in triplicate at the FactoryFactoryFactory to get the
objectOfYourDesire. """

This is such an absolutely fantastic way of succinctly describing why I
dislike Java so much. Bureaucratic!

Absolutely fantastic post, get this on a blog somewhere. I seriously wish I
could upvote you more.

~~~
Lewisham
It's also a great way of specifying why I love it. Having been bitten on the
ass one too many times by typing problems in a Python project, the feeling of
confidence I get from doing the Java bureaucracy (to some extent mitigated now
I do Scala instead) is something I have really come to love.

It's like a security blanket for me.

~~~
zephyrfalcon
(Disclaimer: Not meant as flamebait)

Not to be a prick, but if you're having "typing" problems with Python, you're
using it wrong.

Types are almost irrelevant in Python. What matters is whether, in a given
situation, the method you're calling is supported and does what is intended.
The actual type/class of the receiving object doesn't really matter, ditto for
any arguments you pass to the method.

While this may seem highly unsafe and brittle, it has important benefits. You
can just hack up some code that "just works" in a few minutes, without having
to sacrifice a goat to the compiler first, making sure that all the correct
types are specified, subclasses are defined, interfaces are implemented
completely, etc. The rigid type systems in other languages often require this
and more; making changes to your software becomes a chore. Rapid prototyping
this is not.

In Python, when used correctly, you don't have this problem. Write a bit of
code, write a test, run it, and decide what to do next. Ideal for testing out
ideas. It doesn't work? Throw that shit out and write something else; two
minutes later you'll be testing your new code again. Yes, you do need to have
unit tests, but the same is (or should really be) true for most languages.
Just because something compiles, doesn't mean that it does what you want.
(Except maybe in Haskell. :-)

Interestingly, the quickly-written prototype might well be good enough to
become the actual production code, with some additions. Just keep you tests
up-to-date, for reasonable use cases, and there's no reason why your code
shouldn't work in real life. Sure, that function foo(x) that wants to call
x.bar() will fail if you call it with an x that doesn't support the bar()
method. So don't do that, then! ;-)

Anyway, to summarize, I personally would much rather have Python's
flexibility, paired with unit testing, than Java's lack of flexibility paired
with compiler checks.

~~~
Lewisham
Well of course I'm doing it wrong, I got crashers during execution :)

I understand the concept, but sometimes in a medium-size project, you just
accidentally send the wrong object back. It happens. But Python won't tell
you, and it'll blithely wait for the code to get exercised before dying. I
don't remember exactly why I was having this problem, but the bug wasn't
shallow, and required a certain confluence of exceptions to occur before it
would fire. The sort of thing that would even escape most unit testing.

I would never force static typing on Python or Ruby or upon any language that
didn't want it, and when I switched to Python I was very pleased with dynamic
typing. However, I find myself much happier with the stronger compiler checks.
Writing a medium project in Python now frays my nerves!

~~~
zephyrfalcon
"I don't remember exactly why I was having this problem, but the bug wasn't
shallow, and required a certain confluence of exceptions to occur before it
would fire. The sort of thing that would even escape most unit testing."

I agree that this does indeed happen... I think it's a matter of, the more
flexible a language is, the more rope you get to hang yourself with, even
unintentionally and unexpectedly.

(Anecdote:) For my work, I have been developing and maintaining a fairly large
Python code base... (~70K lines... comparable to about 700K lines of Java
<wink>). Another developer changed a module so it would access the database
upon importing, which was a no-no (IMHO), so I changed it back, using a class
that gets the desired info from the db upon instantiation, and some sort of
singleton construct so the same instance would be reused. I also decided to
write a test to check that when this module was first imported, there would be
no instance of said class yet. To make sure it was a first import, I removed
any references to the module from sys.modules, then did an import. This worked
great... until I ran the whole test suite using nose
[<http://code.google.com/p/python-nose/>], which has its own ideas about
import order and such. This turned out to be surprisingly hard to fix... a
non-shallow bug that wouldn't even be possible in less flexible languages.

~~~
Daishiman
Regardless of the language, when you get to over 50K lines of code, cute
tricks need to go out the window.

------
zephyrfalcon
I've been using Python since around 1996. Back then I had used, or was still
using, C, C++, Turbo Pascal, Delphi, BASIC (groan) and assembler.

Python was so much more high-level than all these other languages that it was
staggering. It was pretty weird to use it at first. Where are all the
declarations? What are these "lists" and "dictionaries"? You mean I can just
stick any old thing in an object or even a class? Etc.

Soon it became obvious how much more powerful this new language was, and I
enjoyed replacing reams of Pascal/C code with a few lines of Python. I tried
to use it at work too, but failed because it was considered "unmaintainable"
by the powers that were (this was around 1999-2000). Of course, this just
fueled the feeling of having an obscure but superior language rebelling
against the big evil statically typed empire. :-)

Anyway, this used to be some of the appeal of Python. I suppose it still
applies to some extent, although since then, Python has been passed left and
right by languages that are more powerful, more flexible, more functional,
more "fun", and whatnot. Nowadays there seems to be a meme going around
claiming that e.g. Ruby is fun and flexible, while by contrast Python is
boring and conservative. It wasn't always like that. I distinctly recall
people discovering Python and exclaiming that "programming is FUN again!".

Then again, all of these things are in the eye of the beholder, mostly. If you
don't like Python, no big deal, especially if you have both lower-level (C,
C++) and higher-level (Lisp) languages at your disposal. (Personally, I used
to think that Ruby was butt-ugly and uninteresting... these days, I have taken
more of a liking to the spirit of the Ruby community, which (perhaps
ironically) reminds me of Python's in the 1990s.)

------
messel
<http://tryruby.org> You'll probably still dislike it. But at least you can
feel more comfortable comparing python to something.

I prefer Ruby, but appreciate Python and Perl. I come from C/C++ coding for 14
years.

------
Estragon
Yes, you're a bad person. We're assembling a re-education camp for People Like
You right now.

------
kbob
The paradigm shift is that in Python the most direct way is best.

Examples.

In Java, accessor methods are considered good style. In Python, directly
accessing a member is better. (more concise, makes client code clearer.) If
you need to do magic, you can use properties.

In C++ and Java, you use inheritance to denote which classes have a given
behavior. In Java, you also use interfaces. In Python, you simply give a class
the needed method(s). (I.e., you use duck typing.) That flattens or removes
lots of class hierarchies. If you need to do magic, you can use isinstance(),
issubclass() or hasattr().

In Python, you use the built-in types a lot. Many problems decompose easily to
lists, sets and dictionaries. That reduces code dramatically. Java and C++
STL's containers, in contrast, are so clumsy they make me look for ways to
avoid them. If you need to do magic, you can subclass the built-in types or
build new types with the same methods as the built-ins.

------
experimentor
Python is a great language. But there is nothing bad about preferring one
language/style over another. There are great programmers in all the camps.

Try the other two scripting languages - Ruby and Perl. I would prefer Ruby.
See if you like the way things are done there.

If you find that you are more at home with this language than Python, try
analyzing what makes you prefer it over Python.

I would suggest you to start with the basics of the Ruby language, and then
try building a simple web app with Sinatra. I find the Ruby style much more
comfortable than Python.

But if you don't like any of these languages, its still well and good. If you
get can shit done with C#, thats all it counts.

------
KirinDave
A lot of us don't like Python. It's a language with a mediocre design, a
somewhat frustrating syntax, and a stubborn refusal to commit to such
essentials as real closures and lambdas.

It's basically a language written by a group of people who don't trust you (as
a Python user) to be knowledgable and educated. Decisions have been made based
on the assumption that you are bad at your job.

Now, everyone seems to comfort themselves with the notion of making it “easy
for maintenance”; repeating “I am smart, surely, but not everyone can be as
smart as I am.” But this is ultimately a dodge that feeds into the problem
endemic to our industry: a disdain for everyone else and everyone else's
methods if they differ slightly from our indoctrinated best practices.

~~~
lelele
> It's a language with a mediocre design, a somewhat frustrating syntax, and a
> stubborn refusal to commit to such essentials as real closures and lambdas.

I agree about closures, but why lambdas would be so much better than named
functions (already available)? I think named functions help code readability,
which is among Python's top goals.

~~~
KirinDave
> I agree about closures, but why lambdas would be so much better than named
> functions (already available)?

Because sometimes you want to conditionally create functions on the fly. Named
functions are a very awkward way to do this.

It is unfortunate that we even have to have this argument. Anyone with
significant experience in functional programming can tell you how useful
unnamed functions are.

And it's important to realize they are not necessarily anonymous in _local
scope_. They're anonymous in the _global scope_.

> I think named functions help code readability, which is among Python's top
> goals.

Anonymous Lambdas need not be a detriment to readability. Why do you think it
would be otherwise?

------
cageface
You owe it to yourself to learn at least one dynamic high level language. The
advantage of Python (and Ruby, which I prefer) is that, for the right tasks,
it's an extremely productive language. Compared to C++ or Java you have to
write far, far less code and you can usually find good libraries that reduce
the amount of code you have to write even further. Python doesn't have the
elegance or flexibility of Lisp, but it's an extremely _practical_ language
for getting anything done that doesn't need C++ performance.

~~~
exit
curious what you prefer about Ruby. i'm very familiar with python, and have
only looked at Ruby long enough to decide (mistakenly?) that it wouldn't do
anything for me which python doesn't already.

~~~
asher
Given a = [1, 2, 3, 4, 5]:

    
    
        Ruby:    a.map{|i| i+1}.reject{|i| i%3 == 0}.map{|i| i*i}
        Python:  [i*i for i in filter(lambda i: i%3 != 0, [i+1 for i in a])]
    

Please ignore the fact that the whole operation can be simplified
mathematically - nontrivial map-grep-map operations do occur.

I find the Ruby version clearer because it proceeds from left to right like a
shell pipeline.

~~~
samdk
I see your point, but I think your Python's not terribly idiomatic and that's
a big part of the problem.

This is easier to read and understand, only goes through the list twice, and
loses nothing in terms of power:

    
    
        [j*j for j in [i+1 for i in a] if j%3 != 0]
    

(And for any given operation, there's very possibly a cleaner way to abstract
out the inner list comprehension, which would again make it a lot nicer.)

In general, I don't see much of a reason to use filter/map/etc in Python: weak
lambdas mean they're not terribly powerful. List/sequence comprehensions can
do everything they can do with cleaner syntax and/or fewer operations.

This, I think, is actually at the core of this whole discussion. The Ruby/bash
approach makes sense if you're used to working with sequences like Ruby/bash
do. The Python approach is more natural to me though, because I've written a
lot of Python. (And having spent the last year writing a lot of Ruby, I still
find the Python approach cleaner/easier to understand at a glance.)

~~~
LordLandon_

      [(i+1)**2 for i in a if i%3!=2]
    

Goes through the list once, and reads like set notation! (and does i+1 once,
which is what I assume you were going for with the separate [i+1 for i in a])

~~~
samdk
I kept the i+1 separate because the parent noted that this was a trivial
example and wanted to make a point about the more general map-filter-map
operation. _I_ wanted to make the point that you can do the map-filter-map in
Python more succinctly and more efficiently without sacrificing any power or
flexibility.

In this example, yes, it's easy to solve the problem with only one iteration
through the list. In a more complicated example (especially when the first map
step is expensive and you really only want to do it once) this kind of
solution may not work.

------
Aegean
I am a day-to-day C programmer. I am surprised to hear Python did not fit well
after C for you. In my view, Python is the like the easy scripting version of
C. I first learned Tcl/Tk, then Perl, then looked at bash scripting (my god,
horrible) and seen that the earlier three has some obscure syntax with some
special meanings of $'s and @'s and hyphenated flags everywhere with no
resemblance to C.

Then looking into python, I saw the same philosophy as C; A struct or an
array? Use a nice dictionary, set, tuple or a list, nicely kept under the [ ]
brackets. Throw them in for loops without the iteration integer. Its just all
the same things I do in C but easier, with no cryptic idioms. That's why I
love it.

I have 2 choices of languages for all my projects: C and Python

~~~
mkramlich
Agreed. And interesting you said C and Python.

A few years ago I was thinking about what would be the minimum set of
languages that would be good to know in order to be able to do almost anything
you wanted, and do it well, and to always be employable. I ruled out 1
language alone because of the C phenomenon: there's a whole class of software
where today C is the best choice, and a whole different set where C is a bad
choice. Therefore, the ideal set was 2+ with C being one. I ended up settling
on C, Java and Python. Java for enterprise/BigDumbCompany work, but also
because there's a lot of great tooling and innovation happening in the Java
space more so than other langs. Python for the role of glue and prototyping
and high level no boilerplate bureaucracy but where you could still trust
every developer using it. Ruby could probably fill that role decently instead,
except be a little better or worse in diff areas.

C, Java, Python

Then I found out that Google had picked these three as well. Nice!

~~~
kragen
No, Google picked C++, not C. Very different philosophy!

~~~
mkramlich
Thanks, looks like you may be right. I just found a post by Steve Yegge in
2007 where he said it was C++, Java, Python and JavaScript. I'm pretty sure I
found references elsewhere to C/Java/Python though. Close enough.

I had forgotten about JavaScript, I guess I considered that one a no-brainer
on the browser side. However, the line blurs between C and C++, especially if
you use the extra stuff only tactically as needed rather than a hard-core-
always-OO-and-templates approach.

------
doosra
I started off hating Python as well. I could not stand a language that didn't
terminate statements without semicolons! :) And python just seemed a lot like
Perl; when using both languages for large projects my code just seemed to
degenerate to "hacky."

But I've grown to like the simplicity of Python. One thing I don't like is its
threads implementation, however. Because of the GIL, multithreading (GUI +
background thread) just doesn't work right. Maybe I'm using it wrong?

~~~
jakevoytko
The Right Way for a long time was to run multiple processes. If you absolutely
needed threads, then the Other Way That Is Less Correct involved launching
threads written in C from a C extension

The Python community seems to be warming to the importance of threads. There
are several efforts breaking their swords against the GIL nowadays (Unladen
Swallow being the most prominent), and Antoine Pitrou wrote a new GIL to help
improve contention [1]. With any luck, by the end of the Python Feature
Freeze, there will be some significant headway towards efficient handling of
threads within Python, but I'm not holding my breath yet ;)

[1] <http://www.dabeaz.com/python/NewGIL.pdf>

~~~
jnoller
If someone were to submit a patch nuking the GIL, I doubt it would be a
language change, ergo, the language moratorium (a block on new syntax) does
not apply.

~~~
jakevoytko
I agree. To clarify, I'm hoping that _because_ they're not focusing on
language enhancements, they might make some major headway towards nuking the
GIL

------
est
> I like C++ too

I never met a hardcore C++ guy claim they like C++

> by hardcore I mean the kind of people who wrote Exaile

I think Python weren't meant to write desktop music players. Stuff like Zope
are hardcore.

~~~
thedigitalengel
I never said I was a hardcore C++ guy. :)

I'm more like a hardcore C guy.

I do know a fair bit of C++ though. Perhaps C++ would've been better if
compatibility with C was not kept as a fundamental goal. Just a personal
opinion.

Qt does an amazing job of taming C++. I used their framework for some GUI
design and loved it.

~~~
olliesaunders
I think what he is saying is, if you program enough C++, you'll grow to
dislike it.

------
njharman
The biggest revelation Python gave me is peoples thought process/problem
solving process/whatever you want to call it (I call it brains) work
differently. And importantly peoples brains are wired to work really, really
well with specific language qualities(dynamic, functional, boilerplateish) as
manifested in specific languages. But really poorly with other
qualities/languages.

So, no you are not a bad person. If you've given Python a honest attempt (took
me a year to do that, I had whitespace hangup that was hard to get past), then
you aren't missing anything either. Python just isn't the language for you.
Move on, be happy.

------
terra_t
You don't have to like Python. I don't.

Of course, I don't have any pretentions of being a "good person" either.

------
neutronicus
I don't much like it either.

Came from C++, learned Perl, got a job writing Fortran, learned Lisp. When
hating on Perl came into vogue on the internet, I said to myself, okay, I will
learn Python as a Perl replacement. It is a decent Perl replacement, what with
all the libraries and the fact that it is shebang-able.

Now that I've dispensed with background, what I don't like about Python:

1\. Assignments don't return values. I _hate_ this. An example. I would like
to write:

    
    
        if (m = re.match("woo, regular expression")):
            do some stuff with match object
    

Instead

    
    
        m = re.match("woo, regular expression")
        if m:
            do some stuff with match object
    

This obscures the fact that I only care about this match object if it
evaluates to true.

2\. List comprehensions kind of suck. [(a, b) for a in as for b in bs] is a
_cartesian product_ and not a zip? Really?

3\. Loops don't help this either: There's no equivalent of the Lisp (loop for
x in xs for y in ys do (stuff x y)). I have to explicitly loop over the index.
This pisses me off.

4\. I feel that I am generally shoehorned into creating and assigning more
objects than I would like.

Honestly it seems kinda crippled in comparison to Lisp, which, by the way,
_runs faster_.

I would go back to Perl if multidimensional arrays were not so godawful.
Perhaps I should try Ruby.

~~~
eru
Perhaps `zip' could help address some of your points?

> 2\. List comprehensions kind of suck. [(a, b) for a in as for b in bs] is a
> cartesian product and not a zip? Really?

Strange. I would say it sucked if it was the other way round. You can use the
`zip' function, if you want a zip.

    
    
      zip (as, bs)
    

> 3\. Loops don't help this either: There's no equivalent of the Lisp (loop
> for x in xs for y in ys do (stuff x y)). I have to explicitly loop over the
> index. This pisses me off.

Try the function `enumerate' and `zip'. E.g.

    
    
      for x,y in zip(xs, ys): stuff (x,y)
    

If you need an explicit index for your stuff:

    
    
      for (i, (x,y)) in zip(xs, ys): stuff (x,y)
    

> 4\. I feel that I am generally shoehorned into creating and assigning more
> objects than I would like.

I agree, only the other way around. Python is much too destructive and relies
on in-place updating. E.g. recently we got `sorted' that doesn't sort in-place
but return a sorted array --- but the `shuffle' function still works only in-
place. Also dicts are destructive. There should be a persistent (i.e. non-
ephemeral) data structure for key-value-mappings in the standard library.

------
twism
I was in the same boat as you before, but it is now my "go to" language. It
happened when I started using django. Just humor yourself and go through this
tutorial:

<http://docs.djangoproject.com/en/dev/intro/tutorial01/>

Don't copy and paste the code in the tutorial and when they ask you to type
something in the REPL, do it.

That's when it all started for me.

~~~
messel
I was looking for a smooth way to ramp up my Python (very weak). Just had a
little experience with it from the friendfeed api v2 on the app engine.

------
l0nwlf
"My question to the hardcore python lovers is this (and mind you, by hardcore
I mean the kind of people who wrote Exaile, not the kind who hack up a Python
script every now and then to organize their iPod)"

I'm disqualified to answer - as I come in your so called second type (softcore
python lover perhaps), people who uses python to fix things in day to day
life.

------
endtime
I like Python because, IMO:

* It's the most concise, expressive language I know * Friendly syntax: I just write what I'm thinking and it pretty much works * Most importantly: It includes a ton of functional programming goodies (of which I make liberal use), but I can still just say x = 1 when I want to. Best of both worlds.

------
l4u
Do you hate scripting languages in general? Maybe you should compare python
with other scripting languages.

~~~
squidsoup
I really dislike the term "scripting languages". While you could describe
Python and Ruby this way, it does them a huge disservice, implying that they
aren't capable of large scale application development. I think this term
should really be reserved for Bash et al.

~~~
prodigal_erik
I read "scripting language" as a legitimate warning about tradeoffs that make
it unsuitable for high-volume use, because the code is permitted to change so
much runtime behavior that most known optimizations (and other kinds of static
analysis!) are ruled out. For example, Twitter's Ruby to Scala migration made
news, so there's value in being able to broadly say what's different between
those kinds of languages.

------
Avataristic
I still write most of my code in C. Could never really warm to C++ and Java
was fun in the early days, but the sheer volume of API's, J2EE, et al
eventually crushed my spirit.

It took me several goes to become friendly with Python. I find it excellent to
try out algorithms. If I don't know how something is going to be best
implemented, then writing a bunch of classes in Python and tweaking attributes
and methods until the algorithm is as simple as can be helps me get there very
fast.

~~~
CyberFonic
I didn't warm to Python until v2.2. Took an article by Eric Raymond for me to
take another look at it and it finally clicked. Great for trying out ideas,
etc. But I still write all the heavy duty stuff in C. Its really cool to do
the heavy lifting in C and expose it as a shared library and then do the
coordination stuff in Python.

------
Kaizyn
Programming languages all come with a specific mental model for how you're
supposed to code in the language. That's why it's so useful to learn different
types of languages so that you "pick up" those different ways of thinking.
Everybody thinks differently so not every language is going to suit the tastes
of every developer. You may find that Lua or Ruby are a better fit with your
thinking patterns and that you are more productive using one of those as a
scripting language of choice.

The power of scripting languages really come down to a very simple thing: each
line of code in a scripting language is equivalent to roughly 5 to 10 lines in
a systems programming language. You're doing the same mundane programming
tasks but with fewer lines and getting nearly the same performance as if you
had written the code in one of the systems languages. It really won't make
much difference which one you use, you'll see the same productivity gains
using Perl, Ruby, Python, Lua or practically any of the others. However, the
more obscure the language you choose, the fewer developers and the fewer
available libraries to use.

------
HarrySimons
I hate Python too, only because of its insistence on indentation and because
of its verboseness relative to, say, Perl.

I'm not against the non-Perl philosophy of There Is Only One Way To Do It, but
for God's sake, don't insist on indentation! I am under a personal vow that
until Python lifts its indentation requirement (say, via a command-line
switch), I'm no way using this language for my programming needs.

~~~
jsankey
I've never understood this objection. Do you not indent your code anyway? If
so, why should you also need to delineate scopes in another way? Python allows
you to choose your indentation, it just requires consistency: something that
is always required by coding standards (with good reason).

If there was a command line switch, would you use it? Why?

~~~
cageface
Python's whitespace indentation seems like a great idea until you realize that
it makes things like copying & pasting code from web pages etc far more
difficult and, worse, makes automatically reindenting a block of code in an
editor impossible. If I come across a badly formatted block of code in Ruby or
Java or C in emacs it takes me _one_ keypress to sort it out. In Python I have
to carefully, manually look at each line.

It's also fun to spend an hour looking for a bug caused by somebody inserting
a tab instead of a space somewhere. We had a production crash that took us a
long time to fix because somebody hotfixed a file with the wrong editor and
did this.

I also don't understand how forcing people to indent code in the same way
magically makes people write good code. The kind of programmer that can't or
won't indent his code properly is introducing bugs far more serious than bad
layout into your project.

Python's a nice language in many ways but I consider the syntax to be a bug.

~~~
Jeema3000
It's also very annoying to have to un-indent an entire block of code during
debugging just because you want to comment out the conditional statement
around it...

~~~
ableal
You could do what you say - comment the conditional:

    
    
        # if x:
        if 1:         # DEBUG
            block

~~~
pjscott
Or, even quicker and dirtier:

    
    
        if 1: # x:
            block

------
pyober
Before I ever encountered Python, I'd gotten pretty familiar with a wider
variety of languages than C, C++, and Java.

So if you don't _have_ to learn Python right now, maybe you should first learn
Lisp, Haskell, or whatever else you want or need to learn that isn't much like
C/C++/Java. I think you'll have more fun this way. :-)

------
rue
I think an exhaustive answer is "mu". Focusing on the tools instead of the
problem is bad.

------
scelerat
Easy language to read, write, and maintain. Big standard library and lots of
tools. Win.

------
j_baker
If you ignore the fact that this page is a bit biased towards python, it is a
pretty good intro to Python if you're coming from a C++ or Java background:
<http://dirtsimple.org/2004/12/python-is-not-java.html>

My personal experience is that the Java-ish languages encourage you to
overthink problems a bit. Instead, I suggest that you just do what comes
naturally. This will actually get you pretty far, as Python doesn't have that
many gotchas (at least in comparison to Java or especially C++).

------
thejbf
Languages fit you if your tasks are fitting to those languages. As far as I
can see as a C/C++ programmer you should have been involved more lower-level
issues rather than writing software standing on several frameworks. Java is
not a toy language but it handles the stuff you were used to deal with almost
automatically so it feels like it is.

So what kind of programmer are you? What do you develop? These questions are
essential before making any advise.

~~~
thedigitalengel
Currently I'm a student and question of what kind of a programmer I'm is wide
open. I _am_ currently working on a project that has to do with the GC and the
JIT compiler for a language runtime. I plan to use my (remaining) student
years to gain as broad a programming experience as I possibly can, not because
I wish to be good at everything but so that I don't miss anything out. The
whole point of this post was to find out that since virtually everyone finds
Python so bouhaha and I don't, am I doing something wrong?

Secondly I don't mean to criticize Java. By calling it a toy language, I was
simply referring to the fact that Java tends to make writing bad code
difficult, and in doing this takes away some of the flexibility and power that
you tend to associate with other languages.

I mean

while ( _str++)_ str = ( _str) + 1;

becomes

for (int i = 0; i < sb.length (); i++) sb.setCharAt (i, sb.charAt (i) + 1); //
and relevant casting

While the above piece of Java code can be improved and condensed (for
instance, by calling getChars and iterating through _them* and _then_ creating
a new String - would be slow however), I think you get the point.

~~~
thedigitalengel
It seems some of the HN eats up some of the asterisks. But you get the idea.

------
expeditious
Python's alright, but it made me work too hard for what it does. I tried hard
to like it but using Python for writing scripts I was constantly asking it,
"why are you making me do extra work? Perl doesn't make me do half the crap
that you ask of me" (ex. regexes, quoting, string interpolating). Also, Perl
has the CPAN, so, I fired Python and use Perl.

------
shib71
Preference for languages can take into account everything from the syntax to
the libraries to the community. It's not surprising when someone has strong
opinions about them. The problem is when people get precious, but you seem to
be straight up about it. And with C and C++ you certainly won't suffer because
you aren't a Python guy.

------
scorpion032
Python people are too busy solving real world problems fast and quick and
getting their shit done, to fall in love with python.

Tools are just tools. And I don't mean to come across as a jerk. I love
developing. But that is as a means to an end, but not as an end in itself. -
Those who like the latter, end up as research scholars; or Rubyists.

------
kunley
Disclaimer: I'm not saying this to start a holy war...

Try Ruby. It gives much more freedom than Python, not to mention countless way
of shooting oneself in a foot (which you know already from the C family ;)

------
technomancy
If you don't like Python, it may just be an indicator that you know more about
functional programming than Guido, which is hardly a feat. Read his opinions
about tail-calls for a good laugh.

------
3KWA
A programming language is like a screw driver, the brand doesn't matter but
what you do with it!

------
exit
what don't you like about it vs python? it could be easier to respond to some
specific issues.

------
flexterra
Yes

------
adamilardi
yes

------
ahoyhere
I don't like Python, either. There's nothing wrong with disliking Python -
there's lot to dislike. There's also a lot to like, for a certain kind of
person - e.g. not you and me.

It's an aesthetic and personal choice.

------
grails4life
No.

------
jcapote
Nope, I fucking hate python.

