Live data from Hacker News

I don't like Python. Does that make me a bad person?

news.ycombinator.com

161–170 of 231 posts

Re: I don't like Python. Does that make me a bad person?

#161
post #111

Earlier quoted context omitted.

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 genera…

[(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])

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.

Re: I don't like Python. Does that make me a bad person?

#162
post #130

Earlier quoted context omitted.

Doesn't python have sorted sets? Oh, what a pity. Does python only have one single implementation of sets? Too bad. Is the runtime behaviour of that implementation documented? Let's take a look ... I'll be back. This could take a while.

Python has sets as a built-in datatype. If someone needs a different implementation, there's nothing stopping them from writing one.

A couple of points.

1. I love python.

2. The OP was being a troll.

3. People need to be more honest about themselves and their favorite pet languages. I can write a sorted set in assembler too, if I wanted. However, there's been several times that I've wanted a sorted set data type while coding in Python but found that none was easily available. I hate the, "you can write your own!" counterpoint, because it is essentially meaningless unless you can prove that writing your own is as trivial as importing someone else's implementation.

Re: I don't like Python. Does that make me a bad person?

#164
post #119

Earlier quoted context omitted.

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 l…

I'm willing to forgive the creators of Python if they didn't optimize their syntax for copying-and-pasting code. Hotfixing is a naturally perilous process regardless of language. I've spent hours tracking down untested hotfixes in Java. You're also probably less likely to come across a badly formatted block of python code because that would generally result in a bug. Much like misplaced brackets in Java/C/C++ would r…

I'm willing to forgive the creators of Python if they didn't optimize their syntax for copying-and-pasting code.

Copying and pasting is also known as refactoring. A syntax that makes that much harder than it needs to be is mis-optimized, IMO.

Re: I don't like Python. Does that make me a bad person?

#165
post #133
post #121

Earlier quoted context omitted.

Urgh, I learned Java in school and recently had to use Java at work to do some stuff with a bad XML schema (think lots of " " wtf is element "child" for??). I used XStream for it, and started off trying to write the objects the "right" way, i.e. with private members for child nodes and getters and setters for them. However, having drank deep of the Python well, I got about 20 minutes into it before I realised that my…

One thing to look out for here is this: if you are writing getters and setters for primitive data types like strings and ints and stuff you're doing it wrong. Instead of public Customer(String name, int custId) do public Customer(CustomerData cd) where CustomerData is an object. In Customer you would have getters and setters for CustomerData rather than each item that identifies your customer. This is for extensibili…

ouch.

If you encapsulate all the data about a customer in a "CustomerData" object, do you really need a separate "Customer" object? Or do you mean, not the whole customer but larger bundles of information like addresses etc. that don't need any business logic or abstraction but are nice to have as one single bunch of data?

(I mean, there's a reason why C++ still has "struct"s even though OO zealots will tell you they come from the devil).

Re: I don't like Python. Does that make me a bad person?

#166
post #4

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... . 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.

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 s…

I think you just need different techniques for Python than for C. You can write a dummy view that calls dir() on the request object (which will probably tell you how to get the POST data), asks it for its __class__, asks it or its __class__ for their __module__, asks for sys.modules[request.__module__].__file__, and so on. If you just want to know what's in the request object, rather than what its methods are, you can get its __dict__ and print that out, and then you get not just the type of its contents, but an actual example. When you have a REPL and an example of an object, you can call help() on the object and get generally pretty good documentation on And there's the inspect module, like LordLandon_ pointed out, but which I didn't know about. And when the going really gets tough, you can monkeypatch random libraries to change the way they work (e.g. to add logging) in order to debug the problem. All of the above applies to Python development in general, not just Django.

Django in particular has several additional advantages:

• it has an "interact" mode that pops you into a Python REPL so you can poke at all of this stuff interactively instead of having to save a source file and hop over to your browser;

• it has really first-class documentation;

• if you raise an exception in debug mode, the traceback includes dumps of all of the objects mentioned on all the levels of the traceback stack, along with a few lines of source code from the stack frame;

In short, Python offers much more power to undertake the kind of analysis you were wanting to do than C or C++, but you have to do it dynamically, instead of statically.

Re: I don't like Python. Does that make me a bad person?

#167
post #148

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 py…

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 ba…

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

Re: I don't like Python. Does that make me a bad person?

#168
post #99
post #87

Earlier quoted context omitted.

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.

All the popular scripting languages "do" the same things. But I prefer Ruby to Python (while still liking Python) because it feels more programmer-friendly. Ruby: a = %w( apple pear orange ) Python: a = [ "apple", "pear", "orange" ] Ruby: a=%q/O'Malley says "Hello"/ Python: a = "O'Malley says \"Hello\"" Python lets you use "'" or '"' as the delimiter, which solves 80% of these cases - but why not generalize the conce…

My usual approach to the first one in Python is:

    a = "apple pear orange".split()

Re: I don't like Python. Does that make me a bad person?

#169
post #7

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

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.

Re: I don't like Python. Does that make me a bad person?

#170
post #165
post #133

Earlier quoted context omitted.

One thing to look out for here is this: if you are writing getters and setters for primitive data types like strings and ints and stuff you're doing it wrong. Instead of public Customer(String name, int custId) do public Customer(CustomerData cd) where CustomerData is an object. In Customer you would have getters and setters for CustomerData rather than each item that identifies your customer. This is for extensibili…

ouch. If you encapsulate all the data about a customer in a "CustomerData" object, do you really need a separate "Customer" object? Or do you mean, not the whole customer but larger bundles of information like addresses etc. that don't need any business logic or abstraction but are nice to have as one single bunch of data? (I mean, there's a reason why C++ still has "struct"s even though OO zealots will tell you they…

The latter. In my contrived example, I meant that "Customer" was the main object you would use, with methods etc. to work on customer information. Then the data that would pass between objects is encapsulated in its own (very simple) class.

Edit: I didn't parse the "ouch" the first time I read this. Sorry, I'm not trying to be an ass about it. But when I first started trying to figure out the "right" way to do it, I came across something (probably by Allen Holub) that confirmed something I was suspicious about: There is no sense in having a private variable if you are just going to expose it with public getters and setters (except for sanitation purposes). The real point was to pass in the data through data objects, and keep the private members unexposed. This also means (typically, at least for me) a lot fewer getters and setters. It's completely against the Java Beans "way," I think, but it works well in real life. I use Java Beans only for persistence, because I like the automatic JB-xml conversion. That is, I make data objects out of the data that I want to store into a Java Bean, and do the automatic xml storage and read thing. It took me a while to figure that out. My first app, I hand-coded the xml. Ugh.

Post reply on HN