This is a nonstarter — meaningful indentation is a pretty baked-in ( and
liked ) part of the language.
And yes, it’s been brought up many times before on this list.
And it already exists:
for item in a_sequence:
do_some_stuff
#end for
:-)
-CHB
PS: I’m pretty sure some has written an import hook that does something
like this — but mostly as a joke.
On Mon, Dec 2, 2019 at 3:12 PM Jan Bakuwel <jan.baku...@gmail.com> wrote:
> Hi folks,
>
> I have a few decades of experience with software engineering using
> assembler, C, FORTRAN, Pascal, Ada and a fair number of other languages.
> I've been using Python as well for a number of years now.
>
> Both Pascal and Ada have "end" statements, which make the code (at least
> for me :-) ) a lot more readable and maintainable, especially if the
> code within if/while/for statements gets longer and nested deeper. These
> statements exist in these languages for a good reason.
>
> I had a look in the archives to see if someone else already proposed
> this but couldn't find anything, so here goes.
>
> Please let me know whether you think this idea is worth to convert to a
> PEP.
>
> thanks,
> Jan
>
>
> Idea:
>
> To include optional "end if", "end while", "end for" and "end <function
> name>", "end <class name>" in the language. The Python interpreter would
> test that any "end" matches with the correct corresponding statements
> and have the correct indentation, in other words throw an error if you
> would write "end if" where an "end while" should be. This will be a
> great help preventing errors with procedural logic, that I now have to
> painstakingly debug at runtime, especially after moving bits of code
> around.
>
> Python editors would ideally highlight "if" and "end if" just like they
> now highlight "if". By default different colors could be picked for "if"
> and "end if", "while" and "end while" etc.
>
> All this is completely optional of course, so it won't break any
> existing code.
>
> Advantages:
> - better readability and maintainability
> - help prevent procedural logic mistakes
> - editors could use this for improved highlighting of code
>
> Disadvantages:
> - none :-) it's optional, just like the typing that was introduced in
> Python 3
>
>
> Code example:
>
> def func (i: int, j: int, k: int) -> None:
> if (i == 3):
> while (i < 15):
> i += 1
> if (k == 8):
> lots of other code (think a page or more)
> lots of other code
> here is more code <- to which if or while does this belong?
> and a bit more
>
> further code
>
>
> The code could be rewritten like this:
>
> def func (i: int, j: int, k: int) -> None:
> if (i == 3):
> while (i < 15):
> i += 1
> if (k == 8):
> lots of other code (think a page or more)
> lots of other code
> end if
> end while (writing "end if" would throw an error at parse time)
> here is more code
> and a bit more
> end if
> end func
>
> further code
>
>
>
> Looking forward to your feedback!
>
> regards,
> Jan
> NEW ZEALAND
>
>
>
> _______________________________________________
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/UQ4D63RYZSC2CKSUZFWDDPO3IIFTZFD5/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/ZHS2MCLYGKUSXQOD3R4SXVFPVW7SK5FG/
Code of Conduct: http://python.org/psf/codeofconduct/
