4 ms·

<sarcasm> Yeah, great, let's add more syntax to python. Because a cake always tastes much better, the more ingredients it has. Just ask C++! </sarcasm> Sorry b

<sarcasm> Yeah, great, let's add more syntax to python. Because a cake always tastes much better, the more ingredients it has. Just ask C++! </sarcasm> Sorry but did I miss something? When exactly did "this saves 2 lines in the code!" become reason enough to introduce new syntactic elements?

anhner 5y ago
Sometimes it even requires MORE lines of code than before, check out the last "improvement" from the article, the sentinels
returningfory2 5y ago
+1, I find it bizarre that a new language feature is being added to save two lines in a corner case.
Sohcahtoa82 5y ago
> When exactly did "this saves 2 lines in the code!" become reason enough to introduce new syntactic elements? My first thought is decorators. They were added in 2.4, back in 2003: https://www.python.org/dev/peps/pep-0318/ https://www.python.org/dev/peps/pep-0318/ All they are is syntactic sugar for: def decorate(func): doStuff() func() return myFunc = decorate(myFunc) List comprehensions are just a syntactic sugar for a for loop with a single line that appends something. There are plenty of syntactic elements that only exist to save a line or two of code. I much prefer the walrus operator over: x = GetNextObject() while x: doStuff() x = GetNextObject()
- usrbinbash 5y ago
  > List comprehensions are just a syntactic sugar for a for loop with a single line that appends something. They can be that. They can also be syntactic sugar obscuring a construct that would be much more readable if it were written as some nested loops and if statements. Problem with all things that fall under the category of syntactic sugar: The small gain in readbility in some cases is more than offset by the LOSS of readbility when they are overused. Just as an Example: Do I think Decorators are neat? Sure. When they are used in moderation, they absolutely are. However, when codebases start to have decorators everywhere, use multiple Decorators on functions, with some Decs with Args thrown in for good measure, things start to get tricky. And latest when they are used to do something completely different from their original intent (act as syntactic sugar for wrapper functions), what began as a nice idea, can quickly escalate into a debugging nightmare. IMO, Language design needs to be much more careful about what is added to a language than what is left out.
  - Sohcahtoa82 5y ago
    > They can also be syntactic sugar obscuring a construct that would be much more readable if it were written as some nested loops and if statements. For sure. I once wrote a list comprehension that was nearly 200 characters wide. I thought "eh...this is extremely unreadable" and rewrote it into several lines. I figured a rewrite into a few lines of code was the better choice than adding a comment, especially if I decided I needed to change it at some point. There was a performance drop, but it was only about a second, and only when the program was starting up. Every language feature beyond basic binary operators can be abused, but the answer isn't to remove (or refuse to implement) them, but to smack engineers and tell them a firm "NO!" when they abuse them. I have yet to see decorators being abused (Not denying it's happened, but I just haven't seen it myself yet), but I've seen someone abuse operator overloading. Someone had decided to write their own TCP socket class, and decided that "sock += 'some data'" was a great way to send data over the socket. The scapy library kind of abuses overloading the / operator in order to build network packets with multiple layers, but I think it works in that case because anything else might actually be harder to read.

anhner 5y ago

Sometimes it even requires MORE lines of code than before, check out the last "improvement" from the article, the sentinels

returningfory2 5y ago

+1, I find it bizarre that a new language feature is being added to save two lines in a corner case.

Sohcahtoa82 5y ago

> When exactly did "this saves 2 lines in the code!" become reason enough to introduce new syntactic elements? My first thought is decorators. They were added in 2.4, back in 2003: https://www.python.org/dev/peps/pep-0318/ https://www.python.org/dev/peps/pep-0318/ All they are is syntactic sugar for: def decorate(func): doStuff() func() return myFunc = decorate(myFunc) List comprehensions are just a syntactic sugar for a for loop with a single line that appends something. There are plenty of syntactic elements that only exist to save a line or two of code. I much prefer the walrus operator over: x = GetNextObject() while x: doStuff() x = GetNextObject()

usrbinbash 5y ago
> List comprehensions are just a syntactic sugar for a for loop with a single line that appends something. They can be that. They can also be syntactic sugar obscuring a construct that would be much more readable if it were written as some nested loops and if statements. Problem with all things that fall under the category of syntactic sugar: The small gain in readbility in some cases is more than offset by the LOSS of readbility when they are overused. Just as an Example: Do I think Decorators are neat? Sure. When they are used in moderation, they absolutely are. However, when codebases start to have decorators everywhere, use multiple Decorators on functions, with some Decs with Args thrown in for good measure, things start to get tricky. And latest when they are used to do something completely different from their original intent (act as syntactic sugar for wrapper functions), what began as a nice idea, can quickly escalate into a debugging nightmare. IMO, Language design needs to be much more careful about what is added to a language than what is left out.
- Sohcahtoa82 5y ago
  > They can also be syntactic sugar obscuring a construct that would be much more readable if it were written as some nested loops and if statements. For sure. I once wrote a list comprehension that was nearly 200 characters wide. I thought "eh...this is extremely unreadable" and rewrote it into several lines. I figured a rewrite into a few lines of code was the better choice than adding a comment, especially if I decided I needed to change it at some point. There was a performance drop, but it was only about a second, and only when the program was starting up. Every language feature beyond basic binary operators can be abused, but the answer isn't to remove (or refuse to implement) them, but to smack engineers and tell them a firm "NO!" when they abuse them. I have yet to see decorators being abused (Not denying it's happened, but I just haven't seen it myself yet), but I've seen someone abuse operator overloading. Someone had decided to write their own TCP socket class, and decided that "sock += 'some data'" was a great way to send data over the socket. The scapy library kind of abuses overloading the / operator in order to build network packets with multiple layers, but I think it works in that case because anything else might actually be harder to read.