Comment by hagy | Hacker News Reader

Comment by hagy | Hacker News Reader

Parent Full thread

I've read through PEP 563 several times now and I just don't find the motivation particularly strong. The PEP itself outline two high level goals:

1. simply forward refs in types

2. reduce the runtime costs of type defs

While I can respect both goals, I haven't found either problematic enough to break backwards compatibility, including functionality used in several mainstream libraries.

Further, I have yet to see the runtime costs quantified. So I'm not even convinced this will have a tangible benefit. This PEP rejects the alternative option to just disable typedefs with opt-in __future__ imports or command line optimization args. Yet, they rejected this because it would break existing functionality for code that relies on runtime typedefs. And the proposed solution also breaks existing functionality.

In terms of forward refs, the deferred evaluation just feels like a kludge. Every Python programmer is already familiar with how Python evaluates module code at runtime and understands how this prevents forward refs. If anything, this kludge adds a special case for typedefs.

I really feel its time for Python 3 to freeze language features. This PEP and the previous walrus operator fiasco feel like people trying to morph Python into something that it isn't with one kludge after another. This will not lead to a robust language, but instead another Perl 5 monstrosity of complexity.

Instead, I feel programmers looking for more robust, performant, and expressive languages should start exploring new languages. Let Python be the best possible Python and other language features can be explored in languages that incorporate those features in a holistic design.

> I really feel its time for Python 3 to freeze language features. This PEP and the previous walrus operator fiasco feel like people trying to morph Python into something that it isn't with one kludge after another. This will not lead to a robust language, but instead another Perl 5 monstrosity of complexity.

I disagree entirely. This is how Python will be left behind. It needs to be able to compete with languages that adopt new features and paradigms.

For example, new Ruby releases got optional typing and pattern matching. Even Java is getting pattern matching[1]. This is where the developer zeitgeist is heading, and if Python doesn't keep up, it'll be replaced with a language that does.

[1] https://benjiweber.co.uk/blog/2021/03/14/java-16-pattern-mat...

This is where python3 can be left to rest and be maintained while python4 is trailing forward by being compatible?

That won’t happen though. When the 2->3 split happened, people swore up and down “I won’t stand for this! You can’t break Python! We’ll fork it and nobody will ever have to do these changes.”

Now, everyone is on Python 3 for new stuff, and companies are trying to transition to 3 or paying for the company (who’s name escapes me) that does security updates to 2.7. It never works out. It’s best for the PSF to try to reduce breaking changes and try to keep everyone together.

2 to 3 was about incompatible changes, and many companies switched to 3 because of eol of python 2.7, or its EOL would have been a minor event. What I thought about was a backwards compatible branch. We would then see if people need more features or if its enough, but I understand I'm only suggesting more(maintenance) work.

The last few years the discussions of new features if Python have been in two categories:

1. Changes that broke backward compatibility introducing mostly unimportant features

2. Changes that introduced outright mostly unimportant features adding complexity

Instead python programmers' grievances as per "Desired python features" in python surveys [0] are being pushed back.

Top ten programmers' requests actually as per [0] are: static typing, better performance, better concurrency (async syntax...), switch statement (introduced with mindbending gotcha), jit, improve standard library, improve package management, mobile, multiline lambdas, gui.

It appears conclusive discussions in python boards are similar to what Nokia executive board minutes would look like a few years back.

[0]: https://www.jetbrains.com/lp/python-developers-survey-2020/

Well, this particular change (PEP 563) is IMHO actually striving for improved static typing and better performance, so, I guess they're in sync with that.

-- PEP 649 would undo those performance improvements and possibilities of improved static typing over concerns of libraries that user types at runtime having to adapt (I took a look at the issues reported at pydantic and while the API would need to be adapted when PEP 563 would come into effect, I don't really see the major breakage they're talking about -- not that it doesn't take some work to adapt, but I don't see the reason it'd suddenly become impossible to do, it'd only make their own lives a bit easier over the performance cost of all the libraries that use typing without requiring runtime information).

I agree with your conclusion, but I think the forward refs issue is more annoying than you're giving it credit (not that the fix should break stuff). Type hints happen at a higher level, so things are more strict.

    class A:
        def x(self) -> B:  # doesn't work
            return B()  # works
    class B:
        pass

I find this annoying enough that I've been using the future annotations.

But Python has had this behavior for ever with default values:

    class A:
        def x(self, b=B()):  # doesn't work
            return B()  # works
    class B:
        pass

Generally speaking that's considered unpythonic though. Default values are evaluated exactly once, at function definition time. So if you do this, then your default B() will always be the exact same instance of the B class -- literally the same object in memory -- every time you call the function. That's rarely what you want; you usually want the default to be a fresh instance of B(). So instead, the pythonic way is for the default to be None, and then to convert those Nones into their actual defaults in the top of the function/method. This then has the added benefit of playing more nicely with subclassing (as well as composition), because instead of needing to bubble the defaults up the call chain, you simply pass down None and let the implementing function worry about resolving it into the actual default.

Yes of course, that's just an example. In practice is can happen with immutable values, like a namedtuple.

I make way more small, immutable classes than the average Python developer. I've never had the reference issue with defaults and always have it with hints.

You can use “None” there, and set the default value in the function.

I agree with this pretty much 100%.

Stop adding new features for features sake. I can’t actually think of anything since 3.6 that I yearn to use.

If you can’t add something without breaking backwards comparability, time to release Python 4 and wait another 15 years for adoption.

Well, dataclasses are pretty darn useful and were added in 3.7. I can't imangine writing Python code without them now...

Reply on news.ycombinator.com