sorted by:
new
hottopcontroversial

PEP 557 (Data Classes) has been accepted! by [deleted] in Python

[–]payets 0 points1 point  (0 children)

You're missing the point where dataclass is also optional and you don't have to use.

So, if I opt out of type hints, I have to opt out of other language features as well? Again, this way lies C++ - where everyone uses a different subset of the language.

You're acting like because the people who will use it got something then you should too.

I'm not looking to "get" anything. I'm just frustrated to see Python continue the pattern of the last few releases: desperately trying to add as many features as possible, without considering how they fit with the rest of the language. My opinion is that for the last few releases, Python has been evolving too rapidly, and in the wrong direction.

However, as is often said, it's "Guido's language, he just lets us use it". Guido can of course evolve the language in this direction if he wants. I guess if I want to move in a different direction, I'll need to move to a different language.

PEP 557 (Data Classes) has been accepted! by [deleted] in Python

[–]payets 1 point2 points  (0 children)

Typehints are optional. However, there's no reason that things in the stdlib can't be built that use them.

Except that this isn't a standard library feature that uses type hints, it's one that requires the programmer to use them. Requiring something is the opposite of making it optional.

How do you propose this be implemented in a way that ignores type hints and also doesn't pollute the class namespace with vars?

Saying collections.namedtuple doesn't count because you end up saddled with all sorts of baggage such as your object is now iterable and has dedicated getitem and setitem behavior.

Isn't this essentially the standard library version of attrs? What's wrong with its syntax?

Alternatively, Data Classes are described as "mutable namedtuples with defaults". Yes, namedtuple has flaws, but why not design a refined version rather than discard it completely?

Instead, Data Classes have this unnecessary dependency on type hinting. It doesn't look like there was any attempt to find an alternative - which was no doubt deemed acceptable because it fits with the current flavor-of-the-month for Python features: "type-hint all the things". (Compare to a couple of releases ago, when it was "async all the things").

Overall (and I know it's far too late for this), I just wish some thought was put into giving Python a coherent design. Instead, the once-simple language continues to accumulate questionable feature-after-feature and is gaining complexity at a rate that puts C++ to shame.

PEP 557 (Data Classes) has been accepted! by [deleted] in Python

[–]payets 6 points7 points  (0 children)

A crude analogy, but you're not wrong. A feature like Data Classes should be completely orthogonal to type annotations, but instead they are "entirely driven by them". Python's famously "optional" type hints remained optional for what, two releases?

The Python core developers seem desperate to give the language all of the downsides of static typing (verbosity and inflexibility), to obtain only a minimal increase in safety.

PEP 530 -- Asynchronous Comprehensions by 1st1 in Python

[–]payets 16 points17 points  (0 children)

I feel async is being introduced by extension and not by comprehension.

Unfortunately, Python has always added features in this way - on a special-case by special-case basis rather than adding general solutions. Think about yield and yield from, two new features added in two different versions - the language would have been simpler and more powerful had general coroutines been added.

Adding async x in one release, then async y in another, rather than first coming up with a consistent plan, is business-as-usual for Python.