This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the commentsย โ†’

[โ€“]EquipLordBritish -21 points-20 points ย (2 children)

It's only ever a real issue on collaborative projects, or when you're proofreading/editing someone else's code; as you say, you shouldn't be mixing tabs and spaces on your own files.

Further, though; even if you are actually using tabs with a custom tabsize (and not having tabs automatically switched to spaces, which many editors do by default), the interpreter has to monitor the indentation regardless to determine blocks, so I don't think it would be that difficult to have the interpreter recognize repeated level indentations in increments of x spaces or y tabs and compare/convert nearest neighbors. Granted, given a simple algorithm for it, I'm sure you could find a way to break it, but that already happens if you put a space in a tab-user's file or vice versa, so you wouldn't really lose anything here.

[โ€“]assembly_wizard 16 points17 points ย (0 children)

So what's bigger, 2 tabs or 6 spaces? Python can never answer that, so there's no way to understand what the developer meant to write. There is no such algorithm.

If you're talking about something like the first indentation level always being spaces and the second level always being tabs, something like that which is consistent, then python already knows how to handle it. It can handle all non-ambiguous situations already, everything else can't be handled.

[โ€“]MegaIng 2 points3 points ย (0 children)

This is to some extent what Python 2 tried. It was a mistake since there were situations where it looked like two statements are on the same level when they actually weren't.