3 ms·

Author of Pydantic here, very sorry you've had problems migrating. We were very aware this was going to cause problems, and have done our best to make migrating

Author of Pydantic here, very sorry you've had problems migrating. We were very aware this was going to cause problems, and have done our best to make migrating easier. I truly believe that v2 will be a big improvement. I think there are two things going on: 1. Python: Python's laxness doesn't make it easy to define strict APIs or know when you're breaking them. The lack of export controls also means defining what's in the API and what's not is hard. Also Python's strong introspection makes it possible to do crazy things further blurring the API boundary. 2. The ecosystem: with pydantic as an example - the library has grown enormously, more than I ever imagined from an experiment in a file in another project to a major library used by thousands of millions of developers, for a very wise range of applications. I never imagined that happening, do I didn't think all that hard about the interface at the beginning, or even at the v1 release. I also knew much less back then. I'm not sure this kind of growth is very common in other languages except JavaScript. (Written on my phone, sorry for typos)

kazinator 3y ago
> Python's laxness doesn't make it easy to define strict APIs or know when you're breaking them. That is poppycock. Every time you make any change, you have to ask the questions: 1. Can the application use the API to tell the difference? (As in, tell whether the proposed change has been implemented or not?) (If this is not directly used by the API, what intermediate layers use this, which are connected to what APIs, and to which of those does the change matter, and how?) 2. Could an application so affected by the difference plausibly exist today, and would that application be doing something that is documented as valid? (Or that is not documented as valid only by neglect, and that should be valid the way it de facto works now?) 2. b) Do we have a test case for this (either way)? This is not rocket science. Safe, high-level languages mostly make it easier, not harder, whether they are dynamic or not. You can do this. You pretty much have to do this. How can you not know if you're breaking an API; it's ridiculous. Imagine if Intel said, oh, assembly language's laxness makes it hard for us to know when we're breaking the instruction set. Sorry your old Core 2 Duo stuff doesn't run on Core i9.

kazinator 3y ago

> Python's laxness doesn't make it easy to define strict APIs or know when you're breaking them. That is poppycock. Every time you make any change, you have to ask the questions: 1. Can the application use the API to tell the difference? (As in, tell whether the proposed change has been implemented or not?) (If this is not directly used by the API, what intermediate layers use this, which are connected to what APIs, and to which of those does the change matter, and how?) 2. Could an application so affected by the difference plausibly exist today, and would that application be doing something that is documented as valid? (Or that is not documented as valid only by neglect, and that should be valid the way it de facto works now?) 2. b) Do we have a test case for this (either way)? This is not rocket science. Safe, high-level languages mostly make it easier, not harder, whether they are dynamic or not. You can do this. You pretty much have to do this. How can you not know if you're breaking an API; it's ridiculous. Imagine if Intel said, oh, assembly language's laxness makes it hard for us to know when we're breaking the instruction set. Sorry your old Core 2 Duo stuff doesn't run on Core i9.