Hacker News new | past | comments | ask | show | jobs | submit login

I do use and like both fastapi and pydantic but this situiation is something they brought to themselves by adopting experimenral features into their mainline code and sell it as production ready. Python designers are not responsible for time-to-market decisions of other projects. It comes with the "no liability" part of opensource.



I don’t think calling type hints experimental is accurate. They’ve been in the stable release for 4 years.


I think this is an oversimplification. Just look at the number and the history of PEPs:

- The Theory of Type Hints - PEP 483

- Annotations - PEP 3107 - 3.0

- Type hints - PEP 484 - 3.5

- Variable annotations - PEP 526 - 3.6

- Postponed evaluation - PEP 563 - 3.7 (3.10)

- Core support - PEP 560 - 3.7

- Distribution - PEP 561 - 3.7

- Data Classes - PEP 557 - 3.7

- Literal types - PEP 586 - 3.8

- TypedDict (limit keys) - PEP 589 - 3.8

- Final qualifier - PEP 591 - 3.8

- Static duck typing - PEP 544 - 3.8

- Flexible annotations - PEP 593 - 3.9

- Type Hinting Generics In Standard Collections - PEP 585 - 3.9


Almost all of those are additive changes. PEP 563 is a breaking change.


Thought it has been there for some time, it was added to core Python on a "provisional" basis (it says so in the docs), meaning that they were not bound to keep backwards compatibility with it. In other words, it's an experimental feature.


It's definitely experimental. No other language has an established system like this, although Ruby seems to have acquired one in 3.0. We still aren't close to uncovering all the unsolved problems yet, let alone solving said problems.


You and I seem to have different definitions of "experimental feature" then. By your definition, I don't think they did anything wrong. dataclasses in the standard library also rely on runtime type annotations. (how they don't have the same issue with 3.10 I don't know). I would hope people would start relying on new language features years after their release.


Data classes do not do runtime type checking. They are a way for static type checkers to do validation. So there’s no issue for data classes in 3.10.


Data classes don't do runtime type checking, but they do provide dynamic type info through dataclasses.fields(). This function returns a tuple of Field objects, and according to the documentation[1], Field includes the attribute "type":

  type: The type of the field.
In Python 3.10, this now returns a string. In my opinion that's a bug (perhaps in the docs).

I verified this using a short test program:

  import dataclasses
  
  @dataclasses.dataclass
  class Apa:
      bepa: int
  
  first_field = dataclasses.fields(Apa)[0]
  print(type(first_field.type))
Running with 3.9 and 3.10:

  $ python test.py  # Python 3.9
  <class 'type'>
  $ python3.10 test.py
  <class 'str'>
1: https://docs.python.org/3.10/library/dataclasses.html#datacl...


That is indeed annoying. Thanks for the example.


The variable annotations are used at runtime to define the fields. They aren't type checked.


They appeared in 3.5, and the new pep is from 3.7, which will now be released in 3.10.

This isn’t something sudden especially not to anyone using type annotations.


That, on the other hand, is a very legitimate criticism. They could have raised the issue more aggressively sooner.


We've had type hints since 3.5 - therefore 2015, so 6 years.


We've had function annotations since Python 3.0, so for over a decade now.


I was remembering 3.6 but you’re right. September 2015.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: