HACKER Q&A
📣 behnamoh

Is Python getting too complicated for its own good?


For example, the following are valid modern Python code:

    var: str = "Haha"
    print(f"{var:_>20}")
    print(f"{var:*^20}")
    print(f"{str.lower() = }")

    def concatenate[T: (str, bytes)](first: T, second: T) -> T:
        return first + second

    items = [1, 2, 3]
    items [:]=[]

    items = [1, 2, 3]
    items *=0

    bowl = ['water']
    drink ,= bowl

    n = 3
    ['a', 'b', 'c', *n* ['.']] #> ['a', 'b', 'c', '.', '.', '.']

    a, *_ = (1,2,3)

  👤 runjake Accepted Answer ✓
This is fine. F-strings are very useful in the absence of something more well-designed.

My main issue with Python is the whole dependency management/venv situation. It's fine for single app/web-app deployment but when I have a hundred different Python projects on my computer and I need to easily run scripts from them several times a day. My solutions are... not elegant. My current scheme is to start moving my most frequently-used scripts into a monorepo under a single venv.

(recommendations happily accepted)

👤 posix_monad
Python has some design mistakes (IMO):

1. No "var" or "let" keyword, which requires you to read code, particularly with loops, more carefully

2. No multi-line lambdas, which forces you to move snippets away from their usage and come up with a name for them

3. Emphasis on classes and annotations over free functions, which is partly due to (2) but also the lack of a pipe operator, like in R

4. Modifying arithmetic operators (*=, +=, ++, --, etc...). These try to do too much at once. Use more intermediate variables and parens; it's much clearer.

5. "with" statement is a decent idea, but it should be usable without increasing nesting

👤 cpburns2009
F-strings (PEP 498) were released the end of 2016 in version 3.6, almost 7 years ago. They're convenient. Just don't get cute with overly complex expressions.

The new type parameter syntax (PEP 695) newly added in 3.12 is certainly busy. I like the feature but I wish there was a better concise syntax. Metatype programming looks ugly in every language I've seen.

The rest of the statements have been around for ages, and I wouldn't call them recent or modern.

👤 sk11001 

    def concatenate[T: (str, bytes)](first: T, second: T) -> T:
        return first + second
This isn't valid Python.

    items = [1, 2, 3]
    items *=0

    bowl = ['water']
    drink ,= bowl

    a, *_ = (1,2,3)
These are actually useful.

None of these are new btw, I don't know about why you're asking the question like it's some new development.

One great thing about Python is that you can do a lot with it but the complexity is gradually exposed to you as you become a more advanced user which makes it both powerful and easy to get into.

👤 roosgit
To me, these features look very unappetizing.

As a teenager I’ve been "traumatized" by Pascal, but I was lucky to find a refuge in HTML and CSS. After I got a job as a web designer I discovered Python and I realized that I could actually program.

The people who came up with this new syntax have different needs that I do and probably have a different kind of brain than mine.

👤 codingdave
What is the complexity you are concerned about? All of those make sense to me even not having touched python in over a decade.
👤 tmaly
I am starting to feel like Python is becoming C++

I looked up PEP 695 mentioned in another comment.

What do you think?

👤 weatherlight
What's the issue? I don't know Python,are these features uncommon?
👤 aristofun
Sorry to disappoint but Python was poorly designed (for professional demanding work) language to begin with. Even from purely syntax perspective.

Its evolution has always been a sequence of compromises and tradeoffs.