Python 3 angst 2016 edition



  • @Adynathos said in Python 3 angst 2016 edition:

    the existing tools still treat code as text, even though there exist many texts which are not valid code.

    To be fair, (nearly) all (human-readable) code is text. It's just that not all text is programming code.
    An IDE that disconnects the code and text is not as intuitively easy to understand as one that's basically an amped-up text editor.


  • Winner of the 2016 Presidential Election

    @djls45 said in Python 3 angst 2016 edition:

    @Dreikin said in Python 3 angst 2016 edition:

    it is pretty nice (for C-ish syntax) to read

    . . . if your code is nice and short like that. Once you start getting longer functions and loops, it can get quite out of hand.

    I don't really see how braces help with that. Whitespace, yes, but not braces. For sufficiently complex functions, I'd think editor-based effects like code folding and subtle background changes for blocks are much more useful and unobtrusive than whatever advantage braces might have.


  • area_pol

    @djls45 said in Python 3 angst 2016 edition:

    It's just that not all text is programming code.

    That is my point. What is the benefit of the IDE allowing me to write something that is not valid code?

    The code's functional meaning is captured in the abstract-syntax-tree and human communication is captured by comments, javadocs etc.
    Graphical presentation of these elements is a style decision which should be configured by the user in their IDE.
    As you @djls45 said in Python 3 angst 2016 edition:

    My biggest issue with Python is that it takes something that should be simply a non-functional style decision and gives semantic meaning to it.


    An IDE that disconnects the code and text is not as intuitively easy to understand as one that's basically an amped-up text editor.

    Visual scripting solutions have their own problems, but they are easier to understand especially for beginners
    and are great for discovering the API of the system you are working with.
    https://answers.unrealengine.com/storage/temp/2422-pickup.jpg



  • @djls45 said in Python 3 angst 2016 edition:

    @CreatedToDislikeThis said in Python 3 angst 2016 edition:

    no needless infromation-less lines

    So you prefer vertically cramped code? I find that almost as unreadable as code that is not block-aligned on the left side. Line breaks and braces on their own lines help a lot to add readability to complex code by breaking up small logical chunks.

    No, I prefer adding vertical space when it holds some meaning (breaking into small logical chunks, as you say), not when it's required by the braces style.
    E.g. A lot of time, an if statement belongs in the same logical chunk as its preceding or following statement



  • @Adynathos said in Python 3 angst 2016 edition:

    Anyway, the root of the problem here is that the existing tools still treat code as text, even though there exist many texts which are not valid code.

    Treating code as an abstract tree seems like a logical idea.

    The problem is, how do you edit that tree? Turns out the only efficient way for humans to edit code (that anyone has been able to find) is as text. So you'd have to convert it tree/binary -> text -> back to tree.



  • @Dreikin said in Python 3 angst 2016 edition:

    @djls45 said in Python 3 angst 2016 edition:

    @Dreikin said in Python 3 angst 2016 edition:

    it is pretty nice (for C-ish syntax) to read

    . . . if your code is nice and short like that. Once you start getting longer functions and loops, it can get quite out of hand.

    I don't really see how braces help with that. Whitespace, yes, but not braces. For sufficiently complex functions, I'd think editor-based effects like code folding and subtle background changes for blocks are much more useful and unobtrusive than whatever advantage braces might have.

    Any cheap text editor has brace matching. Parsing the whitespace is a little trickier.

    Plus, whitespace can get lost in transit - ever pasted your code somewhere only to have every line start at column 1? With braces you can reconstruct the whitespace, with syntactic whitespace you lost that information.

    And sometimes you want to indent your code a little differently than usual. Things like fluent APIs, or long LINQ chains especially benefit from introducing additional indents. With syntactic whitespace, doing that screws with your syntax.



  • @Maciejasjmj I don't think Python does fluent calls. But yeah, in other languages, it's neat to be able to ignore indentation and just go with whatever makes the code more readable.


  • Discourse touched me in a no-no place

    @Maciejasjmj said in Python 3 angst 2016 edition:

    whitespace can get lost in transit

    That's what I've heard as being a real issue. Whitespace is fragile, so having some extra syntax gives systems a chance to handle things when stuff goes wrong. OTOH, it doesn't bother me all that much, not by comparison with:

    value_when_true if condition else value_when_false
    

    WHARRRGLBALFKADKSFJ!!!!!@£$@%$&!£!****£$***NO_CARRIER



  • @anonymous234 said in Python 3 angst 2016 edition:

    I hate tutorials because they either assume I know stuff I don't, or spend way too long explaining stuff I already do.

    Amen.

    That's why they need to be designed so you can just skip the parts you don't care about.

    IOW: not be done as a video. (My second main gripe about tutorials.)


  • Winner of the 2016 Presidential Election

    @Maciejasjmj said in Python 3 angst 2016 edition:

    Plus, whitespace can get lost in transit - ever pasted your code somewhere only to have every line start at column 1? With braces you can reconstruct the whitespace, with syntactic whitespace you lost that information.

    Hm, yes, that's a problem. In the tradition of old proverbs everywhere, the solution is, of course, not to do that.

    @Maciejasjmj said in Python 3 angst 2016 edition:

    And sometimes you want to indent your code a little differently than usual. Things like fluent APIs, or long LINQ chains especially benefit from introducing additional indents. With syntactic whitespace, doing that screws with your syntax.

    That's where my line-continuation exception comes in. Done well, the compiler ought to be able to figure out that's all the same line and treat all the extra indents as alignment. This requires all normal line continuations to be unambiguous, but I think that's not a problem for a lot of cases (functions with parameters in parentheses are easy, for example), but the fluent and LINQ-like stuff would depend on the implementation. I think LINQ is made in such a way that it shouldn't be a problem, though I haven't done enough of it to be sure. I think any fluent implementation where each new line would reasonably be expected to start with .something should also be easy in many languages (are there any common ones where .something would be the start of a new statement?).



  • @marczellm Why do you think virtualenv is a "huge wtf"? Do you understand what it's for?


  • FoxDev

    @Maciejasjmj said in Python 3 angst 2016 edition:

    whitespace

    That's really the only issue I have with Python (I've not used it enough to find other issues yet)



  • @dkf But that's the second-best Python statement!

    The best one is obviously for/else.


  • area_pol

    @anonymous234 said in Python 3 angst 2016 edition:

    The problem is, how do you edit that tree? Turns out the only efficient way for humans to edit code (that anyone has been able to find) is as text.

    I disagree.
    IDEs are already halfway there with their highlighting and suggestion features.
    Imagine an auto-completion that allows you to choose from ALL valid variants of the code (you start writing and choose alternative), but prevents choosing anything that is not on the list. Would it be that different?

    There are also systems completely change the way code is displayed. For example this one used in Unreal Engine, which is used by quite a lot of people.
    It shows information much more clearly than text: you see the types of all function arguments and outputs,
    you can choose the method/property to from a list.
    The only problem I experienced so far is that its hard to build complex expressions (with math operations), but surely this can be improved.

    I don't claim this is a perfect implementation of a structural code editor, but that it is a direction with a lot of potential and with enough work in that area, I believe it can surpass the traditional approach of writing text then parsing it.

    https://answers.unrealengine.com/storage/temp/2422-pickup.jpg


  • Discourse touched me in a no-no place

    @Adynathos said in Python 3 angst 2016 edition:

    with enough work

    QFE&R


  • kills Dumbledore

    @Adynathos said in Python 3 angst 2016 edition:

    Imagine an auto-completion that allows you to choose from ALL valid variants of the code (you start writing and choose alternative), but prevents choosing anything that is not on the list. Would it be that different?

    It would prevent me writing something like DoStuff(someNewMethod(argument1, argument2, argument3));, then pressing ctrl + . to generate the new method skeleton


  • area_pol

    @Jaloopa
    If that would be useful for you, the editor could (upon you writing this) suggest to add a new method with the given arguments.
    "add this method call + add method in base class in one step" is a transition from valid code to valid code, no need to go through the step of having a call to the method without it being defined.


  • ♿ (Parody)

    @Dreikin said in Python 3 angst 2016 edition:

    @djls45 said in Python 3 angst 2016 edition:

    @Dreikin said in Python 3 angst 2016 edition:

    it is pretty nice (for C-ish syntax) to read

    . . . if your code is nice and short like that. Once you start getting longer functions and loops, it can get quite out of hand.

    I don't really see how braces help with that. Whitespace, yes, but not braces. For sufficiently complex functions, I'd think editor-based effects like code folding and subtle background changes for blocks are much more useful and unobtrusive than whatever advantage braces might have.

    Braces are nice because they are unambiguous. Always. They require less work to decipher in case something goes wrong. Just like putting semicolons in javascript.


  • Impossible Mission - B

    @cartman82 said in Python 3 angst 2016 edition:

    https://twitter.com/zedshaw/status/801885519412006912

    0_1480021755491_upload-67f317c5-cb31-4b6e-8e2b-324244813253

    Ah, the good ol "I was just trolling hahaha I'm not an idiot that you thought I was" gambit.

    Meh. If you look at the context, it's pretty clear that yes, that's exactly what happened, and a bunch of people didn't get it, so he had to put in this disclaimer.

    @Dreikin said in Python 3 angst 2016 edition:

    I like indentation-based blocking, but I agree that allowing freely mixed indents types is a problem. Pick tabs or spaces, disallow other whitespace at the beginning of a line for indentation, and stick with it. My personal thinking is that indentation-based blocking should use tabs alone for indentation, and only allow spaces after all the necessary tabs at the beginning of a line, and only for certain allowed types of alignment (e.g., line continuations such as lining up multi-line function parameters). And maybe if you really want to do something different, braces might be opted-in for.

    Tabs for indentation, spaces for alignment is already a pretty popular pattern, so this would just canonify it in the language and remove some redundancy at the same time.

    I think, but can not yet prove, that Python could be made to enforce that pattern.

    [snipped a bunch of discussion about whether or not Python and/or various Python versions or various Python editors editors actually allow this]

    I like the way Boo did it. Its syntax is heavily inspired by Python, but the author got around this problem by checking the first indented line in each file. The parser remembers whether you used a space or a tab for your first indent character, and thereafter it's a parse error to use the other character in an indentation for the rest of the file. It doesn't force you to use spaces or tabs--you can use whichever you prefer--but it does force you to be consistent about it!



  • @Arantor it does. SQLalchemy uses fluent expressions in its query builder



  • @Jarry huh, TIL.


  • Winner of the 2016 Presidential Election



  • @asdf
    >.>
    <.<


  • Winner of the 2016 Presidential Election

    @Deadfast said in Python 3 angst 2016 edition:

    @cartman82 said in Python 3 angst 2016 edition:

    Zed Shaw

    Haven't we already established before that this guy doesn't know what he's talking about?

    I'm still not sure how his awful tutorials became popular...


  • Winner of the 2016 Presidential Election

    @HardwareGeek said in Python 3 angst 2016 edition:

    @Yamikuronue said in Python 3 angst 2016 edition:

    I'm sorry, what the actual fuck is Zed Shaw talking about?! That's not how ANYTHING works!? And has he never heard of Hanlon's Razor?

    Oh, wait, this is the blowhard who puts big red scare boxes at the top of exercises to say things like

    If you skipped Exercise 0 then you are not doing this book right. You must read every single thing I write here and read it carefully.

    Fuck you dude.

    He also likes to say things like, Don't worry about how it works; just make your code look exactly like mine. That's not teaching programmers; that's training code monkeys.

    Or, play around with this code, changing random things until it does what you want or breaks in interesting ways.

    ...
    ...

    What was the name of that one site that had stories about bad things happening when you do that in production code? Worse than Failure or something similar?


  • Winner of the 2016 Presidential Election

    @bugmenot said in Python 3 angst 2016 edition:

    Of (minor?) note is the fact that Gentoo doesn't use virtualenv (or any of those other things that Zecc mentioned) to handle the concurrently installed versions.

    That doesn't matter though because you can always just install the packages directly into those versions. virtualenv lets you segregate dependencies between various projects, which is a Good Thing even if you use the same version of Python for all of those projects, which many people do.

    @marczellm said in Python 3 angst 2016 edition:

    I think the fact that these all exist and are or were necessary is some point is
    THIS
    huge of a :wtf: .

    See above.


  • Winner of the 2016 Presidential Election

    @HardwareGeek said in Python 3 angst 2016 edition:

    @gordonjcp said in Python 3 angst 2016 edition:

    if it works correctly in Python 2.7, it ought to work in Python 3.x with maybe a few little adjustments that don't break backwards compatibility

    There are breaking changes. It may be possible to write code that works in both; I'm not sure, because I started learning Python after 3 was already well established, so I saw no point in trying to learn 2.

    AIUI, the biggest problem isn't the core language, it's library compatibility. Some libraries have been updated to use 3 features, and thus cannot be used with 2. Other libraries have not been updated for whatever reasons, and still use 2 syntax that no longer works in 3. Although the syntax changes are few and small, at least one of them affects pretty much every script and library ever written. If you are maintaining the library, it's a trivial fix, but if you depend on a library that isn't being maintained, or is maintained by a 3-hater, you're SOL.

    So much this.

    I do almost all of my work in Python 2.7, but, at least on personal projects, I am generally willing to go out of my way a little to make stuff work on 3.3+ as well.


  • Winner of the 2016 Presidential Election

    @ScholRLEA said in Python 3 angst 2016 edition:

    Most of the complaints I have seen really boil down to either "I don't like having to put parentheses around print strings" and "I hate when things change even if the change is an improvement". I have not read this particular screed yet, but my guess is that it is mostly those two complaints repeated over and over again.

    There are actually some valid complaints about Python 3; Armin Ronacher gets into some of those in a series of blog posts over the past 5 years:


  • Winner of the 2016 Presidential Election

    @Adynathos said in Python 3 angst 2016 edition:

    @Dreikin said in Python 3 angst 2016 edition:

    allowing freely mixed indents types is a problem

    Python does not allow mixed indents. Indents must be the same in the whole file.

    Only in Python 3. I've been gotcha'd before by the lack of mixed tabs and spaces errors in Python 2.

    @Dreikin said in Python 3 angst 2016 edition:

    My personal thinking is that indentation-based blocking should use tabs alone for indentation, and only allow spaces after all the necessary tabs at the beginning of a line, and only for certain allowed types of alignment (e.g., line continuations such as lining up multi-line function parameters).

    Ew. Tab indentation is Evil.

    @dkf said in Python 3 angst 2016 edition:

    @Adynathos said in Python 3 angst 2016 edition:

    Python does not allow mixed indents. Indents must be the same in the whole file.

    Do they enforce that, or does stuff just break if you get it wrong?

    The former in Python 3, the latter in Python 2.


  • Winner of the 2016 Presidential Election

    @masonwheeler said in Python 3 angst 2016 edition:

    I like the way Boo did it. Its syntax is heavily inspired by Python, but the author got around this problem by checking the first indented line in each file. The parser remembers whether you used a space or a tab for your first indent character, and thereafter it's a parse error to use the other character in an indentation for the rest of the file. It doesn't force you to use spaces or tabs--you can use whichever you prefer--but it does force you to be consistent about it!

    This is how Python 3 does it.


  • Impossible Mission - B

    @pydsigner said in Python 3 angst 2016 edition:

    Ew. Tab indentation is Evil.

    I often hear people say that, but I've never heard an explanation of the rationale for it.

    I have heard a good explanation for the pro-tabs viewpoint: if you indent consistently at 1 tab per indentation level, no one's tempted to reformat everything to make things indent more or less so it looks better to them according to their own personal style preferences; they simply change the width of a tab in their personal editor and everyone's happy.

    What's the anti-tabs rationale?


  • Winner of the 2016 Presidential Election

    @masonwheeler said in Python 3 angst 2016 edition:

    @pydsigner said in Python 3 angst 2016 edition:

    Ew. Tab indentation is Evil.

    I often hear people say that, but I've never heard an explanation of the rationale for it.

    I have heard a good explanation for the pro-tabs viewpoint: if you indent consistently at 1 tab per indentation level, no one's tempted to reformat everything to make things indent more or less so it looks better to them according to their own personal style preferences; they simply change the width of a tab in their personal editor and everyone's happy.

    What's the anti-tabs rationale?

    • What if you have a maximum line length enforced across your project?
    • What do you use to align continued lines?
      • If tabs, how do you make things actually line up?
      • If spaces, how do you:
        • Get around the inconvenience of not being able to use the tab key to indent continued lines?
        • Avoid accidentally mixing things up?

  • Impossible Mission - B

    @pydsigner said in Python 3 angst 2016 edition:

    • What if you have a maximum line length enforced across your project?

    • What do you use to align continued lines?

    Indent as far as the previous line, plus 2 tabs. (2 so that your continuation doesn't line up visually with something indented 1 level immediately afterwards, if you're inside of a statement that begins a block.)

    • If tabs, how do you make things actually line up?
    • If spaces, how do you:
      • Get around the inconvenience of not being able to use the tab key to indent continued lines?
      • Avoid accidentally mixing things up?

    Ah, you're talking about the Python 3 no-mixing-tabs-and-spaces rule?

    Again, I like how Boo does it: All rules on indentation are suspended when you're inside of a pair of parentheses. This lets you line up multiple large arguments to a method without running afoul of the indentation rules. Not sure if it's the same for line continuations (eg. for fluent interfaces.) I'd have to check the parser source. But for continuations, you can simply indent 2 levels as described above; arbitrary lining-up really only matters inside a method call.



  • @gordonjcp said:

    @marczellm Why do you think virtualenv is a "huge wtf"? Do you understand what it's for?

    In https://virtualenv.pypa.io/en/stable/ it's very nicely explained. I think it's a :wtf: that there are 3 tools for the same thing, and a fourth tool, named almost identically which does something completely different, but very similar to a fifth tool already included in the distribution.

    I understand that it would be a mess to figure out what import foo does when there are several versions of foo installed; again, how do other languages handle not having a virtualenv equivalent? (Inb4 JavaScript) I don't really know other dynamic languages, but C++, C# and Java manage quite well without any global package system.

    Similarly the whole easy_install, setuptools, distribute, pip thing is a mess. For example, distribute is a fork of setuptools which merged back into setuptools, but a lot of obsolete online docs still don't state that in huge letters on the top.

    Also. MyPy. PyPy. PyPI. PyPA. pip.


  • Impossible Mission - B

    @marczellm said in Python 3 angst 2016 edition:

    I don't really know other dynamic languages, but C++, C# and Java manage quite well without any global package system.

    Nuget?


  • Winner of the 2016 Presidential Election

    @marczellm said in Python 3 angst 2016 edition:

    C++, C# and Java manage quite well without any global package system.

    It's not like anyone ever has issues with linkers or pre-compiled binaries being unable to find the right .so or anything...



  • Oh, and another thing that can make me upset is libraries breaking APIs every release. Maybe, just maybe, if people did actually DESIGN their library APIs, as opposed to throwing some 💩 together, made them maintainable and backwards compatible, and then f**king MAINTAIN them, there wouldn't be issues with libraries breaking your code every few weeks, and there would be no need for stuff like virtualenv.

    Amirite?

    @masonwheeler said in Python 3 angst 2016 edition:

    @marczellm said in Python 3 angst 2016 edition:

    I don't really know other dynamic languages, but C++, C# and Java manage quite well without any global package system.

    Nuget?

    aren't those packages installed per project as opposed to globally?


  • Winner of the 2016 Presidential Election

    @masonwheeler said in Python 3 angst 2016 edition:

    @pydsigner said in Python 3 angst 2016 edition:

    • What if you have a maximum line length enforced across your project?

    <why-would-you-do-that.meme.jpg>

    Because there's such a thing as a line that's too long and not all coders always remember to avoid that?



  • @pydsigner said in Python 3 angst 2016 edition:

    If tabs, how do you make things actually line up?

    You misunderstand. Tabs are for indentation. Alignment is an entirely unrelated matter that most people agree should be done with spaces.


  • Impossible Mission - B

    @pydsigner said in Python 3 angst 2016 edition:

    Because there's such a thing as a line that's too long and not all coders always remember to avoid that?

    Then you haven't taught them correctly.

    If you impose an arbitrary "CODE MUST BE NO LONGER THAN XX CHARACTERS" rule on them, they don't learn anything applicable outside your project. But if you teach them a principle instead, such as "a method should fit entirely within one screen, both horizontally and vertically, because that makes it easier to comprehend if you don't have to scroll around to do it," then there's a good reason attached to it. Suddenly it makes sense instead of being arbitrary, and they're a lot less likely to forget it.


  • Winner of the 2016 Presidential Election

    @masonwheeler said in Python 3 angst 2016 edition:

    @pydsigner said in Python 3 angst 2016 edition:

    Because there's such a thing as a line that's too long and not all coders always remember to avoid that?

    Then you haven't taught them correctly.

    If you impose an arbitrary "CODE MUST BE NO LONGER THAN XX CHARACTERS" rule on them, they don't learn anything applicable outside your project. But if you teach them a principle instead, such as "a method should fit entirely within one screen, both horizontally and vertically, because that makes it easier to comprehend if you don't have to scroll around to do it," then there's a good reason attached to it. Suddenly it makes sense instead of being arbitrary, and they're a lot less likely to forget it.

    Have I ever mentioned that I'm a comparatively young contractor who has had to work with HPCs? People pay more attention when their build fails than when you complain in code reviews about style concerns.


  • Impossible Mission - B

    @pydsigner said in Python 3 angst 2016 edition:

    Have I ever mentioned that I ... [have] had to work with HPCs?

    I'm so sorry.


  • Discourse touched me in a no-no place

    @masonwheeler said in Python 3 angst 2016 edition:

    But if you teach them a principle instead

    That's at best a soft rule. Prefer keeping things visible all at once, but don't tie yourself in knots over it; there are far more important rules (such as making sure that the code doesn't crash and promptly returns the correct result).


  • Discourse touched me in a no-no place

    @LB_ said in Python 3 angst 2016 edition:

    Alignment is an entirely unrelated matter

    Chaotic good, reporting in!


  • Discourse touched me in a no-no place

    @marczellm said in Python 3 angst 2016 edition:

    aren't those packages installed per project as opposed to globally?

    Once there's sufficient packages that exist “out there”, the idea of installing them all globally ceases to make sense. You might have a per system or per user cache of packages ready to use, but you probably wouldn't use all of them in the same overall project, and there's always likely to be something that a project might need that isn't currently in your local cache. All that really matters is that you have a clear way of declaring what packages are required for a project (so building/use when one of the packages is absent fails early, saving a ton of heartache) and a clear way of obtaining those packages that are not currently present.


  • Winner of the 2016 Presidential Election

    @pydsigner said in Python 3 angst 2016 edition:

    Ew. Tab indentation is Evil.

    I don't really get that if we're talking about tabs for indentation + spaces for alignment. If you skip the second part I get that it causes problems for different tab widths (what's aligned on one screen won't be on another), but the combo allows everyone to view it at their preferred indentation level while still maintaining the 'prettiness' of well-aligned continuations. It also makes indentation a single-character thing, rather than an n-character thing (yeah, I know neither the parsing or space savings are significant these days. It just seems more elegant to me).

    Fake edit: :hanzo: d

    @pydsigner said in Python 3 angst 2016 edition:

    @masonwheeler said in Python 3 angst 2016 edition:

    I like the way Boo did it. Its syntax is heavily inspired by Python, but the author got around this problem by checking the first indented line in each file. The parser remembers whether you used a space or a tab for your first indent character, and thereafter it's a parse error to use the other character in an indentation for the rest of the file. It doesn't force you to use spaces or tabs--you can use whichever you prefer--but it does force you to be consistent about it!

    This is how Python 3 does it.

    See my example above.

    @pydsigner said in Python 3 angst 2016 edition:

    What if you have a maximum line length enforced across your project?

    Choose a tab-width for your check-in scripts and use that.

    @pydsigner said in Python 3 angst 2016 edition:

    What do you use to align continued lines?

    Tab to the same indent level, then use spaces. I.e., the method I've supported several times above.

    @pydsigner said in Python 3 angst 2016 edition:

    Get around the inconvenience of not being able to use the tab key to indent continued lines?

    Text editors can magically turn tab commands into space characters.

    @pydsigner said in Python 3 angst 2016 edition:

    Avoid accidentally mixing things up?

    Depends on language support, and how good your idea is. It's possible for that to be impossible in some languages (it ends up being ambiguous), but I think one could make languages where it is possible to be unambiguous. Line continuations are the easiest (and most likely) case for wanting to do that, as they tend to be easy to detect:

    • Inside parentheses but new-line encountered? Keep going on the next line.
    • Next line starts with .something? It's a continuation of the previous line.
    • Next line starts with binary operator? It's a continuation of the previous line.
    • Is it part of a special syntax (like LINQ) and either:
      • Missing the required starting part (e.g. from x?), or
      • The previous line is a non-terminal expression/statement/clause of the same syntax?

    @masonwheeler said in Python 3 angst 2016 edition:

    arbitrary lining-up really only matters inside a method call.

    It's probably desirable for things like LINQ or pushing it in far enough to get past the = of an assignment statement, depending on style guides/reqs and personal preferences.


  • Winner of the 2016 Presidential Election

    @LB_ said in Python 3 angst 2016 edition:

    @pydsigner said in Python 3 angst 2016 edition:

    If tabs, how do you make things actually line up?

    You misunderstand. Tabs are for indentation. Alignment is an entirely unrelated matter that most people agree should be done with spaces.

    You'll note that I allowed for that.


  • Discourse touched me in a no-no place

    @Dreikin said in Python 3 angst 2016 edition:

    Text editors can magically turn tab commands into space characters.

    Next you'll be telling us that there are languages that have extra syntax, perhaps based on curly braces, which enables an IDE to reindent the code correctly at the mere touch of a button. What is this strange witchery?!


  • Winner of the 2016 Presidential Election

    @masonwheeler said in Python 3 angst 2016 edition:

    @pydsigner said in Python 3 angst 2016 edition:

    • What if you have a maximum line length enforced across your project?

    • What do you use to align continued lines?

    Indent as far as the previous line, plus 2 tabs. (2 so that your continuation doesn't line up visually with something indented 1 level immediately afterwards, if you're inside of a statement that begins a block.)

    • If tabs, how do you make things actually line up?
    • If spaces, how do you:
      • Get around the inconvenience of not being able to use the tab key to indent continued lines?
      • Avoid accidentally mixing things up?

    Ah, you're talking about the Python 3 no-mixing-tabs-and-spaces rule?

    Again, I like how Boo does it: All rules on indentation are suspended when you're inside of a pair of parentheses. This lets you line up multiple large arguments to a method without running afoul of the indentation rules. Not sure if it's the same for line continuations (eg. for fluent interfaces.) I'd have to check the parser source. But for continuations, you can simply indent 2 levels as described above; arbitrary lining-up really only matters inside a method call.

    No I'm not. Python supports that anyways. My point is that now you have tabs and spaces that you're trying to keep straight, which may confuse editors as well as humans, and that you'll almost certainly have to use the spacebar to get the desired indentation for the alignment, whereas I don't have to worry about tab key overloading or any such thing because I always get spaces and I always want spaces.

    Overall, I feel like "but people like different tab widths!" is really weak argument compared to all the baggage tabs give you.

    @Dreikin said in Python 3 angst 2016 edition:

    Choose a tab-width for your check-in scripts and use that.

    So now the whole point of using tabs is gone because if people use a different tab width for editing than you use in the checker their lines will be uneven.


  • I survived the hour long Uno hand

    @pydsigner said in Python 3 angst 2016 edition:

    What if you have a maximum line length enforced across your project?

    Generally, it's a character limit. So your tab counts as 1, but your four spaces count as 4.

    And don't get me started on 2-spaces. Everything looks so damn squished and narrow and it's so easy to be off-by-one.


Log in to reply