Bottom Page

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
 New parser enabling more soft keywords
I was reading through PEP 622 and it ocurred to me:
Would it make sense, now that there is a new parser, to change some existing hard keywords to soft ones?
For example, making "class" a soft keyword could make some code more readable... or would useing "cls" as an identifier still be better?
I do get that this may not even be desirable because it may have a big impact in other implementations.
But maybe there is another use case that could benefit from this?
I'm 100% against "soft keywords". With such ideas, Python will someday be as unreadable as Perl, in the name of syntactic permissivity. By the way, I'm also against PEP 622, I don't want Python to look like Haskell either. A clear and simple syntax is one of the main reasons of Python's success. Other languages could replace it in the future if we lose this.
DeaD_EyE and Larz60+ like this post
I wasn't expecting a slipery slope fallacy argument from a forum moderator, and as the first response nonetheless, so I guess that tempers my expectations about this forum.

Snark aside, I've noticed that production code with large numbers of LOC make extensive use of isinstance which is the exact kind of problem that PEP 622 attempts to solve, and reading through all those branching ifs is not at all simple. This seems like an improvement that would benefit large codebases, and have zero impact on small projects.

What would be a better alternative to solve the lack of support for destructuring heterogeneous data, then? Since python provides no specific solution for this common problem, it invites every user to reinvent the wheel, which goes against the principle that there should ideally be "one" way to do it.
arthexis Wrote:Since python provides no specific solution for this common problem,
It is not quite true. One can write generic functions through functools.singledispatch and functools.singledispatchmethod that select a function based on the first argument's type. Of course one can also use normal polymorphism for this. I think a lot of code that uses isinstance() calls in functions could be rewritten differently by using these pythonic tools.

Also such programs should be concerned about improving the code that produces the heterogeneous data. These data may come from poor design choices upstream.

Top Page

Possibly Related Threads...
Thread Author Replies Views Last Post
  parser for LVM head Skaperen 0 266 Nov-02-2019, 04:04 AM
Last Post: Skaperen
  is there an options parser that can handle + and ++ Skaperen 1 336 Jul-20-2019, 07:42 PM
Last Post: metulburr
  cli arguments parser Skaperen 0 1,314 Mar-21-2018, 01:41 AM
Last Post: Skaperen

Forum Jump:

Users browsing this thread: 1 Guest(s)