On Mon, Dec 2, 2019 at 3:12 PM Jan Bakuwel wrote:

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)

This is your actual problem: you have a whole page of code nested four times. That’s not going to be readable no matter what editor support you have; you need to refactor it. With smaller blocks of code where the whole thing does fit easily on the screen, you usually don’t get lost—and if you do, most editors already help you. They can draw a different colored line down the left side of each block, or have a keystroke to briefly highlight the start of the current block (I use that in emacs whenever I’m forced to edit code that someone insisted on writing with 2 or even 1 space per indent—or, worse, inconsistent indents), or collapse the current block to an outline (which would actually be less useful if the outline had to show 3 lines instead of 2). Sure, none of that is sufficient with huge blocks of code, but I don’t see how an “end if” would help. Who cares if they’re the same color when you can’t see them both anyway (which, by definition, you can’t when there’s a page or more of code between them)? All the “end if” really tells you is that some block whose start you can’t see ends here, which you can already tell from the dedent. (And, unlike C, where you need a closing brace because the dedent could be a lie, in Python it syntactically means the very thing you hope it means.)

On Dec 2, 2019, at 21:00, Guido van Rossum wrote:

3) I have been known to hold a ruler against my screen to double-check indentation.

Well, if that isn’t part of your integrated development environment, you just need to switch to emacs and give it control of a 3D printer and a robot and it can integrate holding up a ruler for you. :) But more seriously, the unobtrusive colored vertical indent-guide lines (that I think Sublime popularized, but lots of editors do it now, including at least two variations for emacs) really do solve this for me just as well, even with horrible random-indentation code. The only reason I still use the keystroke to highlight the start of the block instead is too many decades of muscle memory using emacs. That doesn’t help when there’s so much code in the inner block that it doesn’t fit on the screen, so I can’t trace the line up to the start. But does a ruler help any better? And would an “end for”?

Hi J, On 3/12/19 9:06 pm, J. Pic wrote:

For me it's really easy given your example without the end statements.

I suppose your use case is actually about much longer code, with much more cyclomatic complexity. Indeed.

I recommend you run McCabe's algorithm instead to help refactor your code.

https://pypi.org/project/mccabe/

Thanks. I believe the changes I suggested are still helpful even after the code has been "perfectly" refactored. cheers, Jan

Hi Guido, On 3/12/19 6:00 pm, Guido van Rossum wrote:

To play the devil's advocate...

Thanks :-)

(1) Using the (possible, future) PEG parser https://github.com/gvanrossum/pegen/ this would be easy to add to the grammar, as long as it's optional.

(2) It can actually help readability in some cases, especially when e.g. 'for' and 'if' alternate.

(3) I have been known to hold a ruler against my screen to double-check indentation.

It seems quite a few folks missed the most important argument, which is that apart from the readability argument, there's also the argument that the Python interpreter can help find issues in the code at parse time instead of at run time (way more time intensive) as writing a "end for" where an "end while" should be gets flagged immediately. cheers, Jan

Hi Guido, On 4/12/19 1:06 pm, Guido van Rossum wrote:

I was playing the devil's advocate in jest. There is no way this will be added to Python, for a large variety of sociological and software engineering reasons. While some of the responses may to you seem like they come from inexperienced people who have not carefully read your argument, consider that to us, your proposal appears to come from yet another person who is relatively new to Python asking for their favorite feature from language X without understanding how that feature would interact with the rest of Python.

I was not implying at all that any response was from inexperienced people. However no-one, at least not in a way clear to me, responded to the value of the suggestion to get early warnings (ie. at parse time) when an "end while" is written where an "end if" should have been written. While I like Python a lot, I do miss the support of advanced compilers that tell me at compile time where I made a typo or logic error so I find myself spending relatively more time debugging at runtime. Not a worry as Python easily makes up for the lost time for 1000+ reasons. I'm just thinking aloud how it could, in my eyes, be even better while also considering the sociological and software engineering impact on the Python community to the best of my abilities. I appreciate that I have much less experience with Python than many of the folks on the list here. So please help me understand how the suggested feature would, in any way, unfavorably interact with the rest of Python as you say. cheers, Jan

On Tuesday, December 3, 2019 at 7:54:03 PM UTC-5, Jan Bakuwel wrote:

Hi Guido,

On 4/12/19 1:06 pm, Guido van Rossum wrote:

...

I was playing the devil's advocate in jest. There is no way this will be added to Python, for a large variety of sociological and software engineering reasons. While some of the responses may to you seem like they come from inexperienced people who have not carefully read your argument, consider that to us, your proposal appears to come from yet another person who is relatively new to Python asking for their favorite feature from language X without understanding how that feature would interact with the rest of Python.

I was not implying at all that any response was from inexperienced people. However no-one, at least not in a way clear to me, responded to the value of the suggestion to get early warnings (ie. at parse time) when an "end while" is written where an "end if" should have been written.

I can see how you would find it useful, and I can also see why you're getting a lot of opposition. One compromise suggestion is to take Andrew's advice and add your own # end for's. Then take Serhiy's advice and add the check to a linter. After you've been coding like this for a while, start your movement to popularize "# end for" :)

While I like Python a lot, I do miss the support of advanced compilers that tell me at compile time where I made a typo or logic error so I find myself spending relatively more time debugging at runtime. Not a worry as Python easily makes up for the lost time for 1000+ reasons. I'm just thinking aloud how it could, in my eyes, be even better while also considering the sociological and software engineering impact on the Python community to the best of my abilities.

I appreciate that I have much less experience with Python than many of the folks on the list here. So please help me understand how the suggested feature would, in any way, unfavorably interact with the rest of Python as you say.

cheers,

Jan

_______________________________________________ Python-ideas mailing list -- python...@python.org javascript: To unsubscribe send an email to python-id...@python.org javascript: https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WH4TOP... Code of Conduct: http://python.org/psf/codeofconduct/

On Dec 3, 2019, at 14:34, Jan Bakuwel wrote:

People focus on the silly example and suggest that the code needs refactoring but that is besides the point.

You’re the one who gave that example as motivation, and who specifically highlighted the “more than a page of code” thing; it’s not something everyone else invented and read into your example. If that example is a bad argument for your proposal, the burden of coming up with a good argument for your proposal is on you. (After all, the default for any proposal is to not change anything.) If there are “plenty use cases”, provide one that isn’t silly instead of one that is. While you’re at it, you might want to show some other languages. I think part of the reaction against it comes from the languages people are familiar with. Python, Swift, Ruby, and most other languages people tout as “readable” just have a generic end or } or dedent or whatever for all blocks. So does C and all of descendants. But PHP has endfor, and pl/SQL, and sh has for/do/done… and those aren’t languages people want to use. Maybe that’s an unfair prejudice—but if so, if you can point people to better examples, it might help overcome that.

On Wed, Dec 4, 2019 at 7:28 PM Jan Bakuwel wrote:

It's clear that I failed to convince even a single person so it's time to drop it. Great to have this list to test the waters so to speak :-)

This is exactly why not every idea needs a PEP :) Discuss first, PEP later. ChrisA

On 2019-12-04 11:05, David Mertz wrote:

I've often wanted named loops. I know approaches to this have been proposed many times, and they all have their own warts. E.g. an ad hoc pseudo code that may or may not match any previous proposal:

for x in stuff as outer:     for y in other_stuff as inner:         ...         if cond:             break outer

But we all manage without it.

+1 Nice, find myself with that problem about once a year and it is annoying to code around.

On 4 Dec 2019, at 21:28, Soni L. wrote:



...

On 2019-12-04 5:12 p.m., Mike Miller wrote:

...

On 2019-12-04 11:05, David Mertz wrote: I've often wanted named loops. I know approaches to this have been proposed many times, and they all have their own warts. E.g. an ad hoc pseudo code that may or may not match any previous proposal:

for x in stuff as outer: for y in other_stuff as inner: ... if cond: break outer

But we all manage without it.

+1 Nice, find myself with that problem about once a year and it is annoying to code around.

Just use context managers!

What? How exactly? Can you rewrite the example given?

These are all a little bit ugly IMO. I've never written the contextlib.suppress style, but I have the others. Usually what I'll actually do is: for x in stuff: break_outer = False for y in other_stuff: do_whatever(x, y) if cond: break_outer = True break if break_outer: break I think this is also ugly noise, but it feels like less of a cognitive load than Oscar's approaches. On Wed, Dec 4, 2019 at 5:56 PM Oscar Benjamin wrote:

...

...

On 4 Dec 2019, at 21:28, Soni L. wrote:

...

On 2019-12-04 5:12 p.m., Mike Miller wrote:

...

On 2019-12-04 11:05, David Mertz wrote: I've often wanted named loops. I know approaches to this have been

On Wed, 4 Dec 2019 at 21:16, Anders Hovmöller wrote: proposed many times, and they all have their own warts. E.g. an ad hoc pseudo code that may or may not match any previous proposal:

...

...

...

...

for x in stuff as outer: for y in other_stuff as inner: ... if cond: break outer

But we all manage without it.

+1 Nice, find myself with that problem about once a year and it is annoying to code around.

Just use context managers!

What? How exactly? Can you rewrite the example given?

I guess what is meant is this:

from contextlib import suppress

class Exit(BaseException): pass

stuff = [10, 20, 30] other_stuff = [1, 2, 3]

with suppress(Exit): for x in stuff: for y in other_stuff: print(x, y) if x + y > 21: raise Exit

You can so the same with try/except:

class Exit(BaseException): pass

stuff = [10, 20, 30] other_stuff = [1, 2, 3]

try: for x in stuff: for y in other_stuff: print(x, y) if x + y > 21: raise Exit except Exit: pass

I dislike both of the above though. My suggestion would be to use a function rather than exceptions:

stuff = [10, 20, 30] other_stuff = [1, 2, 3]

def func(): for x in stuff: for y in other_stuff: print(x, y) if x + y > 21: return

func()

In this example it might seem awkward to introduce a function just for this but normally in context the function can have a more reasonable purpose and a good name and return something useful etc.

-- Oscar _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/5FMNLS... Code of Conduct: http://python.org/psf/codeofconduct/

-- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.

On 2019-12-04 6:05 p.m., Anders Hovmöller wrote:

...

On 4 Dec 2019, at 21:28, Soni L. wrote:



...

On 2019-12-04 5:12 p.m., Mike Miller wrote:

...

On 2019-12-04 11:05, David Mertz wrote: I've often wanted named loops. I know approaches to this have been proposed many times, and they all have their own warts. E.g. an ad hoc pseudo code that may or may not match any previous proposal:

for x in stuff as outer: for y in other_stuff as inner: ... if cond: break outer

But we all manage without it.

+1 Nice, find myself with that problem about once a year and it is annoying to code around.

Just use context managers!

What? How exactly? Can you rewrite the example given?

with Label() as break_outer:   for x in stuff:     with Label() as break_inner:       for y in other_stuff:         ...         if cond:           break_outer()

Actually, I found it's rejected PEP: https://www.python.org/dev/peps/pep-3136/. It looks like the first of several ideas there matches my ad hoc syntax. It *was* 2007, in distant pre-walrus memory. But I'm not sure the SC would revisit Guido's ruling. On Wed, Dec 4, 2019, 6:45 PM Andrew Barnert via Python-ideas < python-ideas@python.org> wrote:

On Dec 4, 2019, at 12:14, Mike Miller wrote:

...



...

On 2019-12-04 11:05, David Mertz wrote: I've often wanted named loops. I know approaches to this have been

proposed many times, and they all have their own warts. E.g. an ad hoc pseudo code that may or may not match any previous proposal:

...

...

for x in stuff as outer: for y in other_stuff as inner: ... if cond: break outer But we all manage without it.

+1 Nice, find myself with that problem about once a year and it is annoying to code around

If you want to change this from an aside to a real proposal, it’s probably worth starting a new thread (and providing a real-life use case—if we all run into it once a year, many people probably won’t remember exactly what it looked like when they last ran into it, and how much their workaround bothered them). _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/JUGJIG... Code of Conduct: http://python.org/psf/codeofconduct/

On 5/12/19 1:03 pm, David Mertz wrote:

Actually, I found it's rejected PEP: https://www.python.org/dev/peps/pep-3136/.

It looks like the first of several ideas there matches my ad hoc syntax. It *was* 2007, in distant pre-walrus memory. But I'm not sure the SC would revisit Guido's ruling.

Whoops, didn't realise my remark let this discussion continue in a different direction :-) Just read Guido's reason for rejecting named loops, interesting. It seems we have different ideas about what "code clarity" means and that's perfectly fine of course. Beauty is in the eye of the beholder. To refer once again to Ada (sorry), that language was explicitly designed taking core software engineering principles and various issues with existing languages into account to create "the perfect language" for systems that must not fail (if we can help it). I like systems that don't fail :-). Various key elements are covered, such as readability and predictability. In other words, everything in that language is geared towards that, including named loops. But I digress. Regarding those named loops, I do get across that from time to time (not every month) but don't think that it only occurs in complicated code. I also don't see how it can be "abused". So far when I used it, it was the most elegant way to leave an inner loop. If one can have nested loops then, I think, one should be able to break or continue out of any of those loops without having to resort to yet another single use function that has no other purpose. Raising an exception is an obvious alternative but I've learned that exceptions are expensive. If that's not the case in Python, I'll have to unlearn that :-) Where it comes to the far reaching effects of such a change I'll have to respectfully bow my head and follow the lead of those who know. Guido brings up the topic of using goto (bad) and return (good) in his rejection. I've seen multiple returns in Python functions. I think that is a bad idea; a goto would be better than multiple returns as it results in more predictive behaviour and facilitates having only one clean "exit" point of the function. Compilers (or in case of Python: smart IDEs) can then help find errors in logic that otherwise would only surface at runtime. Don't get me wrong though... I've never needed a goto since I stopped using Basic a few centuries ago. It's easy to avoid. But multiple returns should, following the same logic, ideally not be supported by the language as code using those will be less clear than code that doesn't. cheers, Jan

On Wed, Dec 4, 2019, 6:45 PM Andrew Barnert via Python-ideas mailto:python-ideas@python.org> wrote:

On Dec 4, 2019, at 12:14, Mike Miller mailto:python-ideas@mgmiller.net> wrote: > >  >> On 2019-12-04 11:05, David Mertz wrote: >> I've often wanted named loops. I know approaches to this have been proposed many times, and they all have their own warts. E.g. an ad hoc pseudo code that may or may not match any previous proposal: >> for x in stuff as outer: >>     for y in other_stuff as inner: >>         ... >>         if cond: >>             break outer >> But we all manage without it. > > +1  Nice, find myself with that problem about once a year and it is annoying to code around

If you want to change this from an aside to a real proposal, it’s probably worth starting a new thread (and providing a real-life use case—if we all run into it once a year, many people probably won’t remember exactly what it looked like when they last ran into it, and how much their workaround bothered them). _______________________________________________ Python-ideas mailing list -- python-ideas@python.org mailto:python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org mailto:python-ideas-leave@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/JUGJIG... Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/TU7ABL... Code of Conduct: http://python.org/psf/codeofconduct/

Hi Andrew, On 5/12/19 3:43 pm, Andrew Barnert wrote:

On Dec 4, 2019, at 17:55, Jan Bakuwel wrote:

...

Just read Guido's reason for rejecting named loops, interesting. It seems we have different ideas about what "code clarity" means and that's perfectly fine of course. Beauty is in the eye of the beholder. To refer once again to Ada (sorry), that language was explicitly designed taking core software engineering principles and various issues with existing languages into account to create "the perfect language" for systems that must not fail (if we can help it) Note that it was designed taking core software engineering principles of the 1970s and the distinct languages of the 1970s into account to create “the perfect Pascal”. A lot has changed in the nearly 40 years since the report was published. For just two examples: The notion of what a type system can do has been vastly extended, meaning that Haskell and Rust and Swift can prevent all kinds of errors that nobody believed could possibly be prevented in 1980. And advances in multithreading have opened a whole new class of problems that nobody could have even imagined, much less tried to solve, in 1980, so Go and Java have tools to verify lock-free behavior; Ada does not.

Does Python have tools to do that? I hit one of those snags a few weeks ago. Today's Ada is not the 80-ies Ada either. Fact is, it's still used for mission critical systems and for good reasons. Let me put it this way: I doubt we'll see Python used in aircraft control systems, but will happily stand corrected if I got that wrong. Ada wouldn't be used today if it would be 40 years old technology.

...

Regarding those named loops, I do get across that from time to time (not every month) but don't think that it only occurs in complicated code. I also don't see how it can be "abused". So far when I used it, it was the most elegant way to leave an inner loop. If one can have nested loops then, I think, one should be able to break or continue out of any of those loops without having to resort to yet another single use function that has no other purpose. Raising an exception is an obvious alternative but I've learned that exceptions are expensive. If that's not the case in Python, I'll have to unlearn that :-) Yes, you have to unlearn it. Exceptions are not that expensive in Python (and in a lot of other modern languages)—but even if they were, you’d still have to deal with the fact that Python uses them pervasively. Every for loop ends with an exception being thrown and caught, whether you like it or not.

Sweet, thanks :-) Done.

...

Guido brings up the topic of using goto (bad) and return (good) in his rejection. I've seen multiple returns in Python functions. I think that is a bad idea; a goto would be better than multiple returns as it results in more predictive behaviour and facilitates having only one clean "exit" point of the function. I’ve never understood this idea. The dogma comes from C, where functions usually have to do a lot of explicit cleanup at the end, which means an early return complicates that cleanup, often in really messy ways that people get wrong all the time. So it makes sense for C.

But most languages are not C. Even C++ programmers quickly figured out that this doesn’t even extend to their closely-related language as long as you use it properly. But other people keep trying to extend it to languages like Python where there’s not even a “if you use it properly” condition.

Storing a value in an otherwise-unnecessary variable and then making sure you correctly break out of and/or skip over all of the remaining flow control to safely arrive at the end of a function is complicated. Returning early doesn’t have those problems.

And if you don’t like early return, how could you possibly like labeled break? It’s a similar goto in disguise, it means every loop now has multiple clean exit points that you have to keep track of possibly buried deep down in the nesting, it means any explicit cleanup might get skipped accidentally… if none of that is a problem for labeled break, why is any of it a problem for early return? I agree it's a goto in disguise. But it does have merits in certain cases, for example searching for something in nested data sets and once found you're done.

...

Compilers (or in case of Python: smart IDEs) can then help find errors in logic that otherwise would only surface at runtime. Why do early returns make that any harder? (Other than eliminating some of the sources of those logic errors in the first place, which doesn’t seem like a bad thing.) What’s an example of a logic error that a compiler could catch without early return but can’t catch with it?

I think it's harder to understand how a function works if that function has various ways it could end instead of just one. Maybe that's just me thinking that is cleaner. What is clean is, to a certain extend, in the eye of the beholder. An example of a logic error would be where a variable is used before it's being assigned, which could be the case for one of the returns but not for the other. regards, Jan

My little experiments in 3.7 show exception setup is about 40% more costly than just a do-nothing loop, but execution of is about 9x more expensive than doing nothing, so actually very little cost if your loop only rarely catches the exception (I assume you'll probably actually do something inside the loop, which would reduce the proportional overhead of try-setup). no try : 0.000022s : N= 1000 : stddev=0.00000 unraised : 0.000030s : N= 1000 : stddev=0.00005 raised : 0.000180s : N= 1000 : stddev=0.00000 from tools.timethis import timethis # Dabeaz's timing tool. N = 1_000 for __ in range(1_000): with timethis("no try"): for _ in range(N): pass with timethis("unraised"): for _ in range(N): try: pass except ZeroDivisionError: pass with timethis("raised"): for _ in range(N): try: raise ZeroDivisionError except ZeroDivisionError: pass On Wed, Dec 4, 2019 at 9:22 PM Serhiy Storchaka wrote:

05.12.19 04:43, Andrew Barnert via Python-ideas пише:

...

Yes, you have to unlearn it. Exceptions are not that expensive in Python (and in a lot of other modern languages)—but even if they were, you’d still have to deal with the fact that Python uses them pervasively. Every for loop ends with an exception being thrown and caught, whether you like it or not.

Raising and catching an exception in the C code is much cheaper than in the Python code. In Python you instantiate an exception and set its traceback, context and clause, in C you can just store several threadlocal pointers (most of them NULLs). In python you execute complex bytecode to catch an exception, in C you just read and compare few pointers in common case. StopIteration is not even raised in most case internally in the C code, it is raised only when leaked to the Python code.

So exceptions are still expensive in Python, even comparing with other Python code. But outside of tight loops or if you do some input/output, they are proper tool for control flow. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/KRBXAR... Code of Conduct: http://python.org/psf/codeofconduct/

Hi Andrew, On 3/12/19 5:48 pm, Andrew Barnert wrote:

On Mon, Dec 2, 2019 at 3:12 PM Jan Bakuwel mailto:jan.bakuwel@gmail.com> wrote:

...

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)

This is your actual problem: you have a whole page of code nested four times. That’s not going to be readable no matter what editor support you have; you need to refactor it. This is of course a silly example. With smaller blocks of code where the whole thing does fit easily on the screen, you usually don’t get lost—and if you do, most editors already help you. They can draw a different colored line down the left side of each block, or have a keystroke to briefly highlight the start of the current block (I use that in emacs whenever I’m forced to edit code that someone insisted on writing with 2 or even 1 space per indent—or, worse, inconsistent indents), or collapse the current block to an outline (which would actually be less useful if the outline had to show 3 lines instead of 2).

Sure, none of that is sufficient with huge blocks of code, but I don’t see how an “end if” would help. Who cares if they’re the same color when you can’t see them both anyway (which, by definition, you can’t when there’s a page or more of code between them)? All the “end if” really tells you is that some block whose start you can’t see ends here, which you can already tell from the dedent. (And, unlike C, where you need a closing brace because the dedent could be a lie, in Python it syntactically means the very thing you hope it means.)

I've been doing software engineer for a few decades... I like to think I know a little bit about it :-) ... believe me I have more than one use case where this would be very useful for me. cheers, Jan

On 4/12/19 11:06 am, Jan Bakuwel wrote:

If being brought up many times, .... sounds like a perfect candidate for a PEP to me.

The implication is that it has been brought up AND REJECTED multiple times. But you do have a point -- a rejected PEP would provide documentation of the reasons against for anyone bringing it up again in the future. -- Greg

Jan Bakuwel writes:

Interesting. Has it been rejected as PEP or as an idea?

In this context "PEP" and "idea" are interchangeable, except that "ideas" aren't listed in PEP 0.

Having a list of "rejected" ideas/PEPs with the reasons why it was rejected would indeed be great to have.

The list is in PEP 0. The reasons are in the PEPs themselves.

On 4/12/19 1:51 pm, Jan Bakuwel wrote:

Has it been rejected as PEP or as an idea?

There has never been a PEP on it as far as I remember. Probably because it always gets shot down before it gets anywhere near that stage. One of the probable reasons for that is summed up by "preferably only one obvious way to do it". Python doesn't generally go out of its way to provide alternative ways of writing things. You say that it would be optional, so people who don't want to use it could ignore it. But you can't ignore it if you're reading or maintaining code written by someone else who uses it. Every "optional" feature has a cost to the whole community. - Greg