|
|
Subscribe / Log in / New account

PyCon: Evangelizing Python

PyCon: Evangelizing Python

Posted Mar 28, 2013 14:50 UTC (Thu) by pspinler (subscriber, #2922)
Parent article: PyCon: Evangelizing Python

My concern with python's indentation is that it sometimes presents practical difficulties to collaboration.

For example, I can't reliably count on being able to copy and paste code segments from my colleague's emails (especially email sent from outlook, bleah). I've even found this issue when attempting to read and reuse code published on some web pages.

otoh, for a language that uses syntax markers for flow of control, copied code will work as copied regardless of indentation, and auto-indentation tools will always correctly restore the code to a readable status.

-- Pat


to post comments

PyCon: Evangelizing Python

Posted Mar 28, 2013 15:58 UTC (Thu) by mpr22 (subscriber, #60784) [Link] (9 responses)

My main practical annoyance with Python's use of indentation as the exclusive syntax for block structure is that it interferes with convenient use of the REPL for testing code snippets (since rectangle select is approximately never as convenient to use as linewise select). I also find the whole business of needing to care about indentation, when in a delimited-block language my text editor can do 100% of the caring-about-indentation for me, a positively retrograde step.

PyCon: Evangelizing Python

Posted Mar 28, 2013 18:24 UTC (Thu) by jwakely (subscriber, #60262) [Link] (8 responses)

I always thought I was the only person who had that problem using the Python REPL, I find it incredibly annoying but all the Python users around me never seem bothered by it.

PyCon: Evangelizing Python

Posted Mar 30, 2013 12:25 UTC (Sat) by thoeme (subscriber, #2871) [Link] (7 responses)

Puh! And I thought *I* was only one being put off by python's use of identation... It always reminds of my miserable time in university using some retarded pascal interpreter on the school's VAX system. I tried to learn Python, but stopped imedeately when I found out that first example would not work due to 2 <tab>s in a block identation. Stupid design choice.

PyCon: Evangelizing Python

Posted Mar 30, 2013 17:58 UTC (Sat) by jwakely (subscriber, #60262) [Link]

I have no problem at all with the indentation in a source file, but I wish the REPL was a bit smarter about handling the variations in whitespace that easily occur when selecting and pasting chunks of code.

PyCon: Evangelizing Python

Posted Mar 30, 2013 18:44 UTC (Sat) by smurf (subscriber, #17840) [Link] (5 responses)

Why should Python's indentation be a problem?

You use indentation in pretty much every other high-level programming language, otherwise you won't understand your code tomorrow.
The only difference is that Python uses the indents directly, while most other languages require redundant clutter like braces or BEGIN-END keywords to tell the compiler what to do.

Related to this, about everybody I know has written (or debugged) at least one piece of interesting C code like

   if (foo)
       if (bar)
            baz();
   else
       quux();
You simply don't get to make these mistakes in Python.

Interestingly, the idea of indentation as primary syntax seems to spread to other contexts.
Cf. CoffeeScript or HAML.

PyCon: Evangelizing Python

Posted Apr 5, 2013 4:16 UTC (Fri) by welinder (guest, #4699) [Link] (4 responses)

> You simply don't get to make these mistakes in Python.

That's actually wrong.

When a tab sneaks in you so get to make those mistakes and there is
nothing that visually tells you anything. Things line up neatly,
but don't actually work.

In C you don't get to make those mistakes. If it's important
then you can see it.

PyCon: Evangelizing Python

Posted Apr 5, 2013 6:19 UTC (Fri) by smurf (subscriber, #17840) [Link] (2 responses)

So set up your editor that your tabs actually do the same thing, visually, that Python thinks they do logically. Simple.
Or tell your editor to not use tabs at all. Again, simple.
Or tell your editor not to use spaces (i.e. ony Python indent == 1 tab) and make the tabs wide enough that you can't miss any misalignment.

The Python community has more-or-less agreed on the second option; personally I strongly prefer the third. But that's as much bikeshedding as whether a C open brace goes on the same line as the if statement, or below it (and if so, which indent does it get?)

This kind of mistake (mixing up tabs and spaces) is so easy to check for that Python actually has an option for it. Which C compiler checks for "wrong" indentation on nested statements?

PyCon: Evangelizing Python

Posted Apr 5, 2013 7:02 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

any language that requires me to have a specific configuration in my editor to use the language is not a reasonable choice.

If you are a full-time programmer who works in a nice, dedicated environment, you may end up with a nice tailored config.

But, like most sysadmins, I have to support software on all sorts of systems, many of which I haven't ever touched 5 minutes before I'm working on the code.

by the way, this is why I'm a vi person. every system has some variation of vi that I can run to get the job done. other editors, it's not the same thing.

PyCon: Evangelizing Python

Posted Apr 8, 2013 21:08 UTC (Mon) by wtanksleyjr (subscriber, #74601) [Link]

>any language that requires me to have a specific configuration in my editor to use the language is not a reasonable choice.

That's why I stopped trying to learn APL, by the way. So I do agree with your basic concern.

But it's really not accurate to say that Python requires an editor with a specific configuration. I have to edit Python with Notepad from time to time, and nothing breaks. It's simply a matter of comfort and caution to use an editor that won't make it easy to do things that screw up code -- but the language doesn't care.

So many times I have to edit code that a hardware engineer or a skilled, dedicated sysadmin (who isn't a double-classed programmer-sysadmin like I am) has previously modified. Very commonly I'll find random indentation (hardware engineers are the worst -- I recall cases where every newly added line of C was added flush left, no indentation at all, in the middle of properly indented code; and then no attempt was made to bring the result back upstream).

It's a minor thing to note that Python CAN be told to error out if the indentation is mixed in any way; by default it only errors out if the indentation is completely ambiguous, or if it contains spaces before tabs on the same line.

> But, like most sysadmins, I have to support software on all sorts of systems, many of which I haven't ever touched 5 minutes before I'm working on the code.

Same here. And I'll also say that Python is usually not the first choice of sysadmins -- Perl is usually much closer to a sysadmin's basic toolbox, and much much further away from a programmer's, while Python makes all the sysadmin tools take more typing to use.

> by the way, this is why I'm a vi person. every system has some variation of vi that I can run to get the job done. other editors, it's not the same thing.

Hahahaha. You work with SANE systems. Healthy systems. I work with systems where sometimes the only choice is vi, and sometimes the only choice is notepad.exe.

Anyhow, if you can't install your editor, you can't install a language. You're stuck with what you've got. In my case, I switch between bash, powershell, and cmd.exe. If I took your complaint seriously, I would have to hate using powershell and bash because they aren't available on all the platforms. Naw... Better to simply and silently resent the corporate choices that made the better choice unavailable.

We're stuck with the corporate tools we're given. (Pun intended but unindented.)

(BTW -- I'm a vi guy too, given the chance.)

-Wm

PyCon: Evangelizing Python

Posted Apr 5, 2013 8:42 UTC (Fri) by intgr (subscriber, #39733) [Link]

> there is nothing that visually tells you anything

Note that this is fixed in Python 3, it gives you a "TabError: inconsistent use of tabs and spaces in indentation"


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds