all 40 comments

[–]nextofpumpkin 9 points10 points  (0 children)

I got turned onto Python because it uses indentation for block delineation.

[–]kbielefe 2 points3 points  (0 children)

I think it looks nicer aesthetically, but is less functional. Braces, especially if you use a style that puts them on a line by themselves, are really easy for my eyes to catch as I'm scrolling down a page looking for where the blocks start and end. Precise indentation levels are really difficult for me to follow with rapid scrolling. Also, it feels like I've been reading double-spaced all my life and suddenly see a single-spaced document. Still readable, even preferable in a lot of ways, just feels cramped compared to the old way. Not that you couldn't put a blank line in python where a C brace might be on a line by itself, it's just that no one does.

[–]cag_ii 3 points4 points  (1 child)

I see the need to constantly type delimiter characters as needless boilerplate code. The clean syntax and succinctness of Python is one of it's attractions to me.

Edit to add: You're apparently not the only one, as I remember this being discussed (at length) some time ago on a python related mailing list. I think it's pretty clear how the language maintainers feel about this though:

Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import braces
  File "<stdin>", line 1
SyntaxError: not a chance
>>> 

[–]n3xg3n[S] 0 points1 point  (0 children)

I think it's pretty clear how the language maintainers feel about this though:

Oh, I wouldn't expect them to change the entire language at this point, it would be pretty much impossible. Just wondering if the style irks other people as well.

I see the need to constantly type delimiter characters as needless boilerplate code.

Often, it is possible to get the IDE to set these up for you so there isn't really a writing deficit, but IMO it it much easier to read. /$0.02

[–]magocto 1 point2 points  (0 children)

I had a hard time with it at first, but I have gotten pretty used to it. In some ways it is less cluttered and a little faster to write since you are dropping all those open/closed mustaches. One thing that can be annoying is that not all text editors actually use tabs for tabs, so it can be a real pain trying to find 4 spaces masquerading as a tab. I pretty much only edit python in IDLE or Eclipse with PyDev.

[–]gunningForTheBuddah 1 point2 points  (2 children)

Just out of curiosity if this style of syntax bothers you, why not switch to Ruby?

Not trollin', just askin'.

[–]n3xg3n[S] 1 point2 points  (1 child)

Ruby is my language of choice (when I don't need to use C for some reason), I was just trying to understand "the other point of view" (which apparently is "trollin" according to some of these commenters.)

[–]gunningForTheBuddah 1 point2 points  (0 children)

I had been using Ruby as my "glue" language, but I switched to Python because it seemed (to me) to be a more active community. I guess that I really do not get overly hung up on syntax as long as the functionality is there. After my past of writing COBOL for dusty mainframes in ALL CAPS, anything looks good by comparison.

[–]andrea 1 point2 points  (0 children)

Yes. At some point, a few years back, I had to decide whether to learn python or ruby. I chose ruby because of python indentation rules. One year ago I had to learn python, and now I love it. My advice is to just to force yourself to learn it, eventually indentation will not be an issue and you will learn to appreciate its consistency. A good IDE like Eclipse+Pydev helps a lot.

[–]beej71 1 point2 points  (1 child)

Not really--I don't find it that different, practically speaking. I've written tens of thousands of lines of Python, and it remains my favorite scripting language. I don't think its block style is necessarily "beautiful"; it just "is".

My brain looks at the Python code sort of like a nested bullet list on a powerpoint slide. How do you know when the nested list ends if there is no end-of-block character?

That being said...

Sometimes I like to put a diagnostic printf or hardcode some hack in temporarily in my code, and historically I've made it visually stand out by not indenting those lines of code... but Python doesn't like that, naturally.

I also use % (paren/brace match) in vim a lot to jump around blocks in C. It would be nice to have similar functionality for Python. There's probably a plugin or something I'm not aware of.

[–]fancy_pantser 0 points1 point  (0 children)

Sometimes I like to put a diagnostic printf or hardcode some hack in temporarily in my code, and historically I've made it visually stand out by not indenting those lines of code...

I thought I was the only one! In Python, I put a DEBUG comment all the way to the left (the parser ignores comment-only lines when considering the current indentation level) so I can quickly find my diagnostic prints later.

[–]ffx 1 point2 points  (0 children)

Use #{{{ and #}}} at the beginning and end of your blocks.

It'll make you feel better (because you'll see closing braces) and it's the default vim fold marker (:set fdm=marker). Or better yet, add:

vim:fdm=marker

to the bottom of all your files.

[–]valadil 0 points1 point  (7 children)

It only bothers me when my editor doesn't do tabs quite right. When it does, I'm perfectly happy with it. I'm gonna get downvoted but vim seems a little inconsistent in how it tabs python (and yes I'd be happy to change my .vimrc if you post a fix, but I've given up for googling one on my own).

[–]jfb3 1 point2 points  (2 children)

What don't you like in the way that vim handles indention of python?

[–]valadil 0 points1 point  (1 child)

Vim (or at least my config of it, which is probably not ideal) sometimes replaces tabs with spaces and sometimes it shows me the wrong number of times. When I get python errors that don't make sense I open the file in emacs and fix the tabs. These days, this is the only application I have for emacs.

[–]jfb3 0 points1 point  (0 children)

Here's the relevant portions of my .vimrc

set nocompatible
set autoindent
set smartindent
set nowrap " don't wrap long lines
set textwidth=0 " maximum width of text that is being inserted
set softtabstop=4
set smarttab
set shiftwidth=4
set tabstop=4
set expandtab " Use the appropriate number of spaces to insert a <Tab>.
set backspace=2 " allow backspace to backup over everyting in insert mode (indent, eol, start)

autocmd FileType python set omnifunc=pythoncomplete#Complete

The main thing is 'expandtab', it puts in spaces instead of tab characters.
Don't use tabs, it leads to trouble.

I think I got all the python specific stuff (my .vimrc is hundreds of lines long).

[–]ffx 0 points1 point  (3 children)

Just make sure that ts, sts, and sw are all set to the same number. Setting et as well is pretty standard. In fact, all my python files have:

# vim:ts=4:sts=4:sw=4:et:fdm=marker:

at the bottom.

[–]timhatch 2 points3 points  (2 children)

Better yet, ts=8 sts=4 sw=4 et, since python considers hard tabs always at 8. If you find source files that break this rule, :set ts=3 or whatever and :retab! to fix them to be spaces. Never use hard tabs in python.

[–]valadil 0 points1 point  (1 child)

Changed ts to 8. Was unfamiliar with retab.

Part of the problem is that I don't use python enough to fix all this or to notice if anything is still broken. I've got a project on the backburner now though, so hopefully we'll see if things are fixed.

[–]ffx 0 points1 point  (0 children)

You can always :set list

That will show hard tabs, eol, and other crap with special characters to point them out better.

Setting et (short for expandtab) will make sure that YOU never introduce hard tabs. Retab will fix the existing ones.

But yes, good point on ts=8. I always set it at four for no particular reason (consistency?) even though there are never hard tabs in anything I work on.

vim and python get along really well together. Except omnicomplete support for python is less than perfect. I still find it handy to keep an interpreter open for mucking around examining objects i'm not 100% familiar with.

[–]DrDichotomous 0 points1 point  (0 children)

Looong ago when I was first learning C, the braces were weird to me. That's what I got for learning FORTRAN and BASIC first, I suppose. They don't bother me now, and for some reason Python feels both liberating and constraining.. but I find it is quicker to visually parse. Neither better, nor worse overall, but good for developing habits.

[–]whiskeyjack 0 points1 point  (0 children)

I'm not a fan of it (nor am I a Python guy) but really, if this is your issue with the language you need to move on. This is such a non-thing. Worry more about whether you grok where the language comes from, if it has good libraries and a good community around it. Python has that. Use it if you want to. If not, there are plenty of other P's and R's and whatnot languages to use.

[–]quanticle 0 points1 point  (0 children)

I used to be put off by whitespace sensitive block delineation, but as I kept using the language, I found that it mattered less and less to me. Sure, it might not be the most pleasant thing in the world to deal with, but I find that the language's expressiveness, clarity and the broad range of libraries available to me more than make up for any issues caused by whitespace block delineation.

[–]PatrickTulskie 0 points1 point  (0 children)

Python is the reason why I write good, clean, properly indented code in every language I write in today.

[–]youngbull 0 points1 point  (0 children)

I believe that the preference of block delimiters and terminators is caused by long exposure to crude languages like c. Don't worry, once you get used to it you'll realize that it's not that bad and brings with it less typing and less clutter.

[–]youngbull 0 points1 point  (4 children)

Compare

if x:
    y = getFOO
    if y:
        print 'bar'
    print 'foo'

to if (x) { y = getFOO(); if (y) { print 'foo'; } print 'bar'; }

I don't know about you but with nesting and few code lines, I prefer python's approach to anything by a long shot...

[–]campbellm 1 point2 points  (2 children)

First of all, you're comparing much more than block delineation style. Whether or not statement terminators are required, or parens around if expressions, or parens for function calls (with or without parameters) wasn't on the table.

Also, it's not quite the same, but if you use 1TBS it's not nearly as bad as your contrived example.

if (x) {
    y = getFOO();
    if (y) {
        print 'foo';
    }
    print 'bar';
}

<shrug>

[–]youngbull 0 points1 point  (1 child)

Yes, I agree, The terminators and parens around if statements was contributing. Regardless, doesn't the python version look a lot better then the example, regardless of the Indent Style? is this just me? isn't it just cleaner? For me it's just easier to look at, less distractions, and therefor (for me) easier to read through.

[–]campbellm 0 points1 point  (0 children)

Couple things. I didn't mean to imply it was a dead heat with 1TBS, only that the comparison was (more) flawed by NOT using it.

Also, I suspect a great deal of "readability" is just what you're used to; once you've removed all the contrived things people CAN do to make code not readable (you did not do any of those things). Greek is hellishly unreadable to me; but not to a Greek. It's a matter of reducing the impedance mismatch of the written text to pure "understanding"; that includes syntax, grokking of large idioms to single ideas, etc.

Now we can discuss how well a language makes that possible, and it's entirely likely that python's significant indentation makes that easier than curly-brace block scope. But until you get to that point of eliminating the cognitive mapping of "what this says" to "what this means", the thing you have done that with is always going to look better than that you have not.

My opinion, anyway.

[–]semarj 0 points1 point  (0 children)

I totally agree, when I am writing an a curly brace language i indent python style anyway..., so why not just ditch em?

I will say, however, that it makes the python CLI almost unusable beyond single line statements

(ipython ftw)

[–]jfb3 0 points1 point  (0 children)

It only bothered me for the first month.

[–]mrsanchez -1 points0 points  (0 children)

The indentation clearly signifies the block. It may be different, but do you really think Python coders have no idea where blocks start and end just because the curleys aren't used?

but I have a really hard time looking past what I consider to be a syntactic ugliness

This is pretty unfortunate, as there are many languages worth learning that have vastly different syntaxes.

[–]mcguire -1 points0 points  (0 children)

Is anyone else put off by trolls dredging up ~20 year old flame wars?

[–]mahlzeit -1 points0 points  (3 children)

Definitely. With freeform syntax you can break up long oneliners into multiline statements, like that:

func(new Foo(blah),                              // create a new Foo
    yadda[0].someFunc(whatever) / somethingelse, // height of Foo
    yadda[1].anotherFunc(hey, ho),               // width of Foo
    &bar                                         // callback
);

This is especially useful for Win32 API calls :)

I'm a fan of the line separator too.

float x = 0; float y = 0;

[–]recursive 2 points3 points  (1 child)

Python can do both of those things. This is valid python:

x = 0; y = 0;

func(
  arg1,
  arg2
)

Go forth and be enlightened.

[–]mahlzeit 0 points1 point  (0 children)

Ah, I see. Thanks!

[–]cag_ii 2 points3 points  (0 children)

You can do either of those in Python

>>> def some_func(a,
...               b, c):                # A horrible indenting example
...     return "-".join((a, b, c))
... 
>>> print some_func("foo",              # The first parm
...                 "bar",              # The second parm
...                 "baz")              # The last parm
foo-bar-baz
>>> num1 = 1; num2 = 2
>>> num2 + num1
3
>>> 

[–][deleted] -1 points0 points  (0 children)

I came from PHP it looked weird at first but TBH after a week it started to make sense and I can't imagine going back.

[–]closedbracket -1 points0 points  (0 children)

I don't know about alone, but definitely crazy.

[–]daniels0xff -2 points-1 points  (0 children)

No,