Package: pyend
PyEndPython's significantindentationis ahorriblethingthatruinsthelanguageformanypeople.It's now fixed.PyEnd introducesendto mark the end of blocks:frompyendimportendif"tabs">"spaces":print("∎")endWhy is that useful?Because it is also a formatter. You can convert indentation-based code (both the file you are working on and the clipboard) into keyword-delimited code. You can then paste away and afterwards reformat your file automatically instead of manually. It should also be quite helpful for refactoring, when the code structure changes and everything has to be re-indented.StatusThis project is still an experiment. Feel free to play around with it and give feedback but don't use it in production code. You may have noticed there are no unit tests yet. Formatting code (especially with significant indentation) is actually not so straight forward and can easily mess things up. That being said, the formatter does some validation in the end. The formatted code is tokenized again and compared to the tokenized original input.Installationpip install pyendHasn't this whole thing been done before?In contrast topindent, it works with Python3 and in contrast topybraceandpybraces, the output is still valid Python.Does it stop there?It sure does not! It also uses tabs instead of spaces for indentation. Because using tabs instead of spaces is much better. However, if you want to be wrong, you can set the--convert-tabs-to-spaces-despite-tabs-being-objectively-better-than-spacesflag, which will convert indentation tabs into 11 spaces. Should you not like 11 spaces for indentation and you would rather enforce your personal taste onto everyone else, you can set the--use-this-many-spaces-per-tab-cuz-as-a-spacist-i-want-uniformity-but-i-dont-want-the-defaultparameter to whatever your heart desires.Why are tabs better than spaces?At the core of the spacecrafters' arguments lies the conviction that their pristine code must look the same everywhere. This idea is just doomed to failure. While a typical space users' code probably looks something like this on their 79 column console or on their printed handouts:the exact same code will render like this on my monitor:so why even bother with indentation width consistency?Furthermore,Developers Who Use Spaces Make More Money Than Those Who Use Tabs. This is because space invaders need higher monetary compensation to make up for the fact that developers who use tabs are happier in general because they make better life choices.That should settle it.Does PyEnd fix all the bad decisions in Python's language design?Unfortunately not. Empty blocks will still need apass:ifNone:passendFurthermore,myList[0:5]still absolutely counter-intuitively only goes up tomyList[4]and there is alsothis atrocity. But hey, it's a start!What about line breaks?Line breaks are aPandora's boxthat this project is not touching. You have to sprinkle the line breaks in manually (you're much better at this than any tool anyway), or you use another formatter on top of PyEnd.But in my project I have a variable namedend. Am I forced to live under van Rossum's dictatorship then?PyEnd only recognizes anendon an otherwise empty line (except for comments) as block end mark. Usingendotherwise is a bit ugly as every block-endingendthen becomes a reference to your variable but it is possible.This is a great project! You are very clever and handsome! Can you also do this for YAML?Thanks but no. YAML isscrewed up beyond repair, starting with its very funny name and not ending with its ambiguity. Use JSON. It has itsproblemsas well but I feel they aren't really relevant in practice and I also just like it more 😌DisclosureIf I didn't consider Python to be a great language, I wouldn't invest so much time in this project. But significant indentation has been an absolute PITA and the urge to do something about it has been bugging me with every paste. I finally gave in.