Pydantic: Version 1 Release

[samuelcolvin]

replaces #143

As per the dicussion on #568 we should get pydantic to version 1 then aggressively follow semvar for breaking changes.

However before we release version 1, I want to make any breaking changes that are obviously required now.

So, to do before version 1:

• [x] rename Schema to Field? #577
• [ ] remove references to validation and use parse instead #578
• [ ] decide about load_alias and dump_alias ~~#477 #624~~ not required for v1.
• [x] fix any significant open bugs (see issue tracker / filter by "bug")
• [x] need to decide about #508

anything else? no point in spending too long perfecting the library and never getting to v1, but still, let's get anything obviously wrong right now.

[samuelcolvin]

some things on #577 and #578 and maybe other issues will require deprecation warnings and a couple of versions before we remove the old behaviour.

I guess we should get all these changes out of the way before we get to version 1.

[samuelcolvin]

@tiangolo maybe you have some feedback/input on this?

@gangefors you said "we have considered it [pydantic] really stable" on #568, would the changes above be okay with you? Anything we an do to mitigate the impact?

[gangefors]

We are totally fine with the changes. Moving to 1.x we can feel relaxed that there should not be breaking changes when upgrading within the same major version.

I appreciate all the work you do on this project and I'm really happy that you want to take it out of the pre-release phase. Many good python projects never end up with a 1.0 release.

[tiangolo]

Great. Thanks for tagging me. I agree with all the points.

---

One extra thing that I wanted to propose was when allowing custom data types (currently with __get_validators__), also support:

• __get_json_schema__ (or equivalent): to allow user-defined types to provide their own JSON Schema. E.g. with a class inheriting from MongoDB's ObjectId.
• __get_json__ (or equivalent): to allow user-defined types to have their own JSON encoder.

Still, I think that's an extra feature that could go in a minor version bump, but I wanted to share the idea in case you see some compatibility that could be broken by these next changes or that would make sense to try and do it now.

[samuelcolvin]

__get_json_schema__ and __get_json__ makes sense to me, please create a new issue. I agree this doesn't need to be done before v1.

[jasonkuhrt]

Add https://github.com/samuelcolvin/pydantic/issues/579 to the list of TODOs?

[samuelcolvin]

Agreed

[samuelcolvin]

also #589 if we decide to do it.

[samuelcolvin]

Question: which is better;

1. One big release with many breaking changes, or
2. Multiple releases each with a few or one breaking change

?

1. will be harder work and involve more conflicts, I guess we would need a v1 branch which breaking changes are merged into. But I guess it would be easier for most people.

@tiangolo @dmontagu @jasonkuhrt @gangefors

[tiangolo]

If making them non-backwards-compatible, I guess 1. To avoid scattered mutually exclusive/incompatible versions.

If keeping them backwards-compatible for a while (so, no mutually exclusive scattered versions), then 2 will probably be easier to manage. I imagine having a v1 branch might lead to code diverging and needing to implement fixes/changes in both branches, etc.

[samuelcolvin]

some things like new bool behaviour #617 has to be backwards incompatible, so I guess that should go onto a v1 branch and only be released with version 1.

Everything backwards compatible should be included in minor releases with warnings, then the warnings and fallback behaviour removed in v1?

[tiangolo]

Hmm, right, get it. But I don't think there's much more that is exclusively backwards incompatible, right?

I think it would be ok to release the new bool with the current master, under a minor version bump.

I would like/ask to have the backward compatibility (for the things that we can, like __validator__ and Schema) for a couple of versions after-v1 with warnings, and then drop it after some minor versions after v1. That would give a bit of margin for people to notice the change and upgrade.

But if we can have, e.g. Schema() still working after v1 with a warning while the new Field()/field() is already supported (and used/documented by default), I think it would be OK to just do it in master.

I guess my main concern is that I think it would be quite cumbersome to handle the 2 branches master and v1. And add features to both, etc.

---

What else is exclusively backwards incompatible apart from the strict bool? What am I missing?

[samuelcolvin]

What else is exclusively backwards incompatible apart from the strict bool? What am I missing?

sound about right to me, I don't think you're missing anything.

Otherwise all sounds good to me.

[jasonkuhrt]

I agree with the conclusion/direction you @samuelcolvin and @tiangolo came to. SGTM

[gangefors]

SGTM too.

[samuelcolvin]

See #719, pydantic is now effectively on a sprint for version 1.

(Sprint in the sense of not working on anything else except critical bug fixes, not sprint in the sense of necessarily being fast :smiling_imp: :running_man:)

[jasonkuhrt]

So, to do before version 1:

I would like to see these two BaseSettings Config fields default to the following:

class Settings(BaseSettings):

  class Config:
    env_prefix = ""
    case_insensitive = True

[samuelcolvin]

Couple of points:

• We can add windows only tests, since CI runs in windows and linux that should work fine, just skipIf.
• I'd be entirely up for removing case sensitivity altogether, I can't imagine a situation where you'd ever desire case sensitivity. It was added as an option to avoid a breaking change, but if we think that switch is superfluous, now would be the time to remove it.

I've been thinking about how BaseSettings works, I'll add more general points to #747.

Let's agree there before we move forward here.

(somehow managed to post this on the wrong issue/PR, moved to https://github.com/samuelcolvin/pydantic/pull/747#issuecomment-521248678)

[jasonkuhrt]

I'd be entirely up for removing case sensitivity altogether, I can't imagine a situation where you'd ever desire case sensitivity. It was added as an option to avoid a breaking change, but if we think that switch is superfluous, now would be the time to remove it.

👍

[samuelcolvin]

I'm going to try and get a beta release of v1 out before the end of the week (September 20th). I then go on holiday for 10 days which will give others time to try v1 and give feedback/find bugs.

However to do that I need to merge some PRs without waiting for others to review them. I hope that's okay, I see no other approach.

[samuelcolvin]

Unfortunately I haven't been able to get a beta for v1 out due to a combination of:

• life
• @dmontagu's excellent suggestions around from_orm and root validators #811
• problems around stripe and SCA at my day job

Sorry.

I also wanted to allow more time for feedback on the features/changes I've implemented recently, in particular I'd love y'all's feedback on:

• root validators #817 and an extension to that which improves ORM integration #822
• custom JSON encoding/decoding #823
• renaming of numerous classes, primarily Schema -> Field

As far as I know (apart from merging the above) the only things remaining to do for v1 are:

• better support for env. variables in BaseSettings #721 (will either need to be branched of Schema-2-Field or wait for it to be merged)
• a script to build history from changes/ files

I'd love help on either of those, otherwise I'll fix them and release a beta in the week beginning 30th (promise).

[tiangolo]

I'm sorry I haven't been able to help recently as I wished :disappointed:

Thanks for all this! :tada:

[samuelcolvin]

The first beta of version 1 is released :rocket: :fireworks: :tada:. It should be on pypi soon.

Please try it, break it and give feedback. :bug: :broken_heart:

Unless another beta is required, I'll try and release v1 proper in a couple of weeks. :clock1:

[tiangolo]

Awesome! Thanks for that! :tada: :clap: :rocket: :bowing_man:

[dgasmith]

@samuelcolvin Any ideas on the timeline here? We are pretty excited about a 1.0, but there are some breaking changes for us and we want to be prepared.

[samuelcolvin]

Hopefully very soon, there are already way too many changes since we got to beta, but I really hope they should all make pydantic v1 better once it's released.

Still to do:

• [x] #909 this became a much bigger hassle than I'd hoped
• [x] #913 which I discovered while working on #909
• [x] #523 which hopefully @dmontagu will work on
• [x] #898, just waiting for the docs to be completed by @ashears in #907
• [x] we need a new page for the docs on migrating to v1; part of #862

Once they're all merged, I'll release v1.

[samuelcolvin]

DONE :rocket:

https://pydantic-docs.helpmanual.io/

If anyone in the reddit-sphere felt like crowing about the release, that would be great.

[tiangolo]

That's awesome! Thanks for that. Congrats and great job! :tada: :cake: :rocket:

Also, where is it on Reddit? Didn't see it on r/Python

---

Edit: Ah, wait, you mean like one of us writing about it there?

[samuelcolvin]

Yes please, if possible? :see_no_evil:

I did put it on hacker news

[tiangolo]

Awesome! I'll do it on Reddit!

Edit: I posted it here on Reddit: https://www.reddit.com/r/Python/comments/dly6ha/pydantic_v10_the_awesome_data_validationparsing/

---

Also, don't post the link directly to Hacker News, just that it's on https://news.ycombinator.com/newest, otherwise they don't allow to vote it up.