Become a fan of Slashdot on Facebook


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re: Curly braces = good. Indents = bad. (Score 1) 173

Actually, lots of people would miss it - just go ask on on comp.lang.python for example - it's one of the features that many people really prefer about the language. I for one do. I totally get that you might not like it, but to a /lot/ of people not only is it not a negative, it's a big positive.

Comment Re:Curly braces = good. Indents = bad. (Score 1) 173

C'mon, go re-read what I said - not once did I suggest that "everyone" (or anything close to that) was having problems with those things, only pointing out that that is a class of problems that can arise due to having both braces and indentation (which is significant on some level to the human but not the language). Unlike many of the anti-Python posts, I didn't make any claim that this was a major source of bugs, a huge issue, etc.

Anyway, looks like my posting limit is just about up with this story, not sure if /. will let me continue feeding ACs, so thanks for the discussion and have a great day!

Comment Re:Curly braces = good. Indents = bad. (Score 1) 173

*sigh*, no, it's not that at all. I'll assume you're trolling, but for the sake of the discussion: yes, obviously the compiler requires them, but that's purely because that's the way the language was designed. My point - which I'm pretty sure you got - was that if you're coming from a language like Python, you tend to wonder why a language like C++ requires them. As in, you don't see the point of them, that's all.

Comment Re:Curly braces = good. Indents = bad. (Score 1) 173

I guess so? I dunno - somewhat ironically, I do *all* of my Python development in vim and I have no special plugins or anything that assist with it other than the native indent stuff, and it's only with other languages (Java/.Net/ObjC/C++) that I feel the need for a full IDE.

Maybe that's for other reasons though (like other languages being more verbose or something). I just find it interesting that in the scenario in which you feel I should really need the aid of a good tool is where I use the most rudimentary development environment. :) Again, I move chunks of code around all the time, so it seems like I should be running into this issue constantly and yet... it doesn't happen. I don't consider myself some superstar dev, I don't consider myself lucky, so I'm at a loss to explain it, especially when the same is true of all of the other people I've worked with that use Python as well. Life's mysteries I guess!

Comment Re:Curly braces = good. Indents = bad. (Score 1) 173

People that think braces and statement terminators are problematic have never used a good auto-formatter.

Hmm, that seems like a pretty sweeping generalization, no? I've used every major IDE out there too, and I don't dev in just Python. As noted earlier, my dislike of braces is that they are noise, and more subtly, they introduce this problem where the block structure indicator that actually matters to the tool (the braces) is a weaker indicator than the one people naturally see more strongly (the indentation - the "shape" of the code is a stronger indicator of structure than some relatively small symbols).

I'm genuinely confused by people who think that cutting and pasting a few lines in problematic in Python. That sort of thing is what people do all day, every day... and somehow it's not causing widespread problems or anything close to it. Even copying and pasting from websites works well (although I find there aren't many real world cases where anyone copies and pastes code verbatim off the web, especially anything more than a few lines).

Anyway, all I can do is reiterate that I've used Python for decades, and watched others - of all skill levels - use Python for decades, and this simply isn't a problem that occurs with any sort of regularity (like I mentioned elsewhere, I can't actually remember the last time I /ever/ saw this happen in practice). Because of this, I really struggle to reconcile lots of first hand experience to the contrary with people who assert it's a major problem (or even a minor problem that occurs with any sort of regularity). Any suggestions?

Comment Re:Curly braces = good. Indents = bad. (Score 1) 173

Hmm, no, that's not what I said (or meant). Rather, when I go to a language like C++, the braces feel entirely superfluous, which begs the question: why are they here? Even with the IDE doing a lot of the work to keep them in sync with the indentation (which in itself is pretty telling), they still feel like completely unnecessary noise.

All languages have things you do that aren't really for your benefit as the developer and are there because the language or other tools need them, and that's a source of friction and too much of that makes it tedious to use that language. Remember in the old days when in C you had to put all your variables at the start of a function? Despite a few who would claim that it aided in "organization" or something, the fact of the matter is that it was because the tool chain just wasn't smart enough yet. Not a big deal, but a case where you're doing stuff not because it helps you, but because the language requires it. For me, curly braces are another example of that, that's all. If you like 'em, great, more power to you. But Python is by no means broken or bad or poorly designed for not having them.

I don't miss them in Python, and in languages that use them I really wish they weren't there.

Comment Re:Curly braces = good. Indents = bad. (Score 3) 173

Well, I too have anecdotes in the opposite direction, so not sure what to say. I've used Python on very, very large projects that have undergone multiple, massive refactorings and I'm not aware of a single time in a refactor that this was an issue. Honestly, as I've read your message and others' and genuinely tried to imagine the circumstances under which it would happen, I'm really struggling. Like, do you have these 10 page functions or something and large swaths of code are being cut and paste willy nilly?

The "major source of bugs" comment - is that "major source of bugs [in programs I've worked on]" or "major source of bugs [for Python programs generally]"? If it's the latter, I'd love to hear more because, again, my experience and the experience of everyone I've ever worked with who uses Python is the exact opposite.

Comment Re: Curly braces = good. Indents = bad. (Score 2) 173

"nearly impossible to find bugs in" ?? Sorry, but that's at best a wild exaggeration. I have no way of knowing if you've really seen "teams" of programmers spend "weeks" looking for one line being wrong with tabs or spaces, but it strains credulity - if it's true, then that may say more about those developers. Sorry, I'm sure that comes across rude, and that's not my intention, but ... wow. So this code passed your unit tests and there was some corner case w/o coverage in which it resulted only in something like a logic error and not something more obvious like throwing an exception? Not saying it can't happen, but the whole scenario sounds a bit fishy, especially if it took multiple teams multiple weeks to find it. Anyway...

On the whole, I haven't found Python any harder to find bugs in, and there are a good chunk of bugs that simply don't occur in it, so that it has been a net gain for me. I guess YMMV, but again, I've used Python along with other languages for literally decades and what you're describing just doesn't occur. Maybe I should go buy a lottery ticket or something because I'm wildly lucky... or maybe this just doesn't happen very often in practice.

Comment Re:Curly braces = good. Indents = bad. (Score 4, Informative) 173

I think I get the point you're trying to make, but I'm a bit dubious - it's a syntactically valid change, so there's no reason for the tool to complain. That's in the same class of errors as deleting a digit from a constant, accidentally pressing '+' instead of '-', removing the '=' from a '=' expression, and so on.

I personally don't care if certain people like Python or not - language preference is often fairly subjective. I'm doubtful, however, about claims that the indenting is bad in any objective way - I've seen too many people use it for too many years on too many projects without it being a problem. I mean, don't you think this would be tripping people up constantly if it were a real issue in practice?

I've watched veteran devs pick up Python as well as recent college grads pick it up, and this just isn't an issue. I can maybe/kinda/sorta almost convince myself that I've just been extraordinarily lucky to have never had this be a problem, but for it to not be a common problem for all of those other people, on all of those other projects? Nah, it just doesn't add up. Everything I've seen suggests that this is a problem that could occur in theory, but rarely if ever does in practice.

Comment Re:Curly braces = good. Indents = bad. (Score 5, Insightful) 173

Indentation is the strongest indicator of block structure to the people reading and writing the code, but the toolchain uses a *different* set of indicators (the braces and semicolons). Any person who is looking at code - especially just quickly scanning code - is going to rely on the indentation to denote blocks first, and then to a lesser degree things like curly braces - the spacing and positioning are simply stronger visual cues.

In most languages, this is what can lead to a few types of subtle bugs, e.g.

if (x y);

Python's stance is that the humans and the tools should use the same block identifiers. Sure there are other ways to solve the problem (like make the tools look for likely errors and warn the user), but Python chose the route of just getting people and tools on the same page - it's not a bad solution.

Personally, I've used Python for many years now, in everything from tiny startups to Fortune 500 companies, for everything from small tools to enormous, distributed systems. Like any language, it has its strengths and its weaknesses, but the indentation is not an issue in practice, but is instead an asset. All of the potential or theoretical problems that people complain about with indentation-based blocks are overblown and simply doesn't occur in practice - at least no more than any other type of problem (I can't even remember the last time we had a bug due to it - probably not in this decade).

If that's not your cup of tea, that's fine. I just find it interesting that (a) it does not actually cause problems in practice and (b) when I hop over to a language like C++ I find that curly braces are just noise and feel wholly unnecessary - just extra stuff to help the tools along, and not there for my benefit as a developer.

Comment Re: Why in the heck should a file server need 2M l (Score 1) 222

Yeah, no disagreement there - I was addressing just the LOC aspect.

FWIW Python's threading model does have concurrent execution of threads, but only for a part of the time - it does support true OS-level threads, but a single, process-wide interpreter lock gets held when running Python bytecode or in a Python API function, so /some/ applications see benefits to using multiple threads (typically cases when you can either do lots of work in a C API or when you are waiting on I/O and just want concurrency but aren't necessarily CPU bound), but often that is not the case and/or the app has trouble using all available CPU. On the upside, it's really great in that you can't corrupt Python's internal state and crash with threads, but that's a pretty minor upside. :)

The multiprocessing library is pretty nifty - at my current job we run a Python request handler process on each CPU core and use pipes to talk to a "controller" process (ends up being message inter-thread communication, so a lot like if you use ZMQ), but it's still a far cry from normal threads. And if you just need concurrency and aren't CPU bound, then gevent is pretty spectacular.

But despite all of this, I think Python's threading model is still one of the big design decisions that can make it a difficult choice in some environments - for our current system, we settled on Python despite this and decided that the cost of dealing with it is offset by the other benefits of Python, but it'd sure be notice to avoid that.

Long term, I'm keeping an eye on pypy+STM ( - it's nowhere near ready and may not ever be, but it's cool in that it's taking a radically different approach to the problem.

Comment Re: Why in the heck should a file server need 2M (Score 2) 222

Yeah, that's a good point. I think an even better example might be low level bit twiddling of a byte stream and conversion back and forth between a struct in memory and a packed binary file format - C rules there and in Python you end up jumping through weird hoops a lot of times. The struct module helps a lot (though to your point it's more verbose than the same task in C), but only to a point.

Comment Re:I hate Python (Score 1) 222

I'll bite, though I wish you hadn't posted anonymously. :)

1) I don't think Twisted is that relevant because it's judging a language based on a library that some third party wrote. And Twisted was insane in part because of the callback-oriented approach to asynchronous programming it took (these days you can use e.g. gevent, which is awesome).

2) The whole whitespace issue is pretty simple, actually. In all the languages you cited (C, C++, Java, etc.) there's a problem in that in reality there are *two* systems for denoting blocks, and the programmer (and IDE, if used) keeps them in sync. The first is the *actual* system, which are things like the { } tokens in C. The second is the whitespace - you'd be rightfully skewered if you tried to write code without "proper" formatting because it'd be an unreadable mess. The problem is that the language parser cares only about the first one, while the human - intentionally or not - generally leans more heavily on the second one, most of the time.

Instead of removing the redundancy and having both the machine and the human rely on a single means of denoting blocks, we instead went with the bandaid solution of making the tools help point out errors like this:

while (x < 100);

Python took a different approach and made the language use the same code block delimiter that humans use for both pseudocode and real code: the whitespace. Some people simply don't like that, and that's fine, but for me it makes great sense and I'm pretty skeptical of people who are rabidly against it, since they undoubtedly rely on whitespace all the time, even if it's subconscious.

3) I use Python a ton, and it's because it's concise while readable, in part due to the language design and in part due to the rich set of built in data types and standard libraries. For any non-trivial task, an equivalent C program (and I love C, BTW) is often 5x or more LOC. That's totally fine because C is great at what it's for, but it's also really great to write 20% of the code to do stuff in Python. A core part of Python's philosophy is to keep in mind that code is read far more times than it is written, so readability is hugely important (for example, the colon at the end of e.g. an 'if' statement wouldn't really be necessary, but Guido et al actually did some code readability tests and found that it improved readability, so he put it in).

Obviously you can write ugly code in any language, and Python is no exception, but I've found that Python makes it easy to write readable code.

4) Performance is often a bit of a red herring. Yes, Python itself is quite slow, but in day-to-day work there's often very little code that actually needs high performance. I've worked at several companies with large Python systems and for most parts of the system, if something takes 1ms vs 0.05ms, it just doesn't matter, but the cost of building, testing, and maintaining that component does matter. A lot. Further, huge parts of most Python programs are actually running C code because so much happens in libraries. Doing file I/O? Networking? All of that is really in C. Number crunching, image manipulation, crypto, etc. etc. - it's all C routines in a pretty Python interface.

Beyond that, in cases where you really do have some chunk of code that has to be blazingly fast, you can easily write it in C and call it from Python (see ctypes, libffi, cython, and so on). Python is by no means a perfect fit for every problem, and it does have its warts, but it's a really terrific fit for a huge set of problems, and a good fit for many more. (and on the performance front I didn't even touch on pypy, which is a drop-in replacement for a large and growing set of Python programs - basically a no-effort perf boost)

5) The kicker for me actually has to do with your question of "What the heck is the attraction". Developing in Python is just more fun. It's kind of silly, on some level, but you might be surprised by how much that matters. I've programmed extensively in many languages, and every 6 months or so I do a hunt to find a replacement for Python, but to date I always come back to it. And when I find myself programming in another language I often get annoyed at all of the useless stuff that language makes me do - stuff I know isn't really necessary because in Python I don't have to do it. I get annoyed at how much the other languages get in the way. I get annoyed at how much work it is to refactor something, even with a spiffy uber-powered IDE. I get annoyed at how much time I spend not working on what I'm trying to accomplish, but working on other things because the language and/or stdlib won't do it for me. I get annoyed at how many hoops I have to jump through just to get up and running. I get annoyed waiting for stuff to compile and link, even when it's nearly instantaneous.

The short of it is that Python is just really fun. It totally encourages a highly iterative approach to development, which in turn encourages you to test everything. I find large Python apps to be far more maintainable (and far less buggy to begin with) than apps written in other languages. You could argue that that's just me, and I'm totally ok with that, haha. :)

Slashdot Top Deals

To iterate is human, to recurse, divine. -- Robert Heller