Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refs #24121 -- Added __repr__() to OrderedSet. #14094

Merged
merged 1 commit into from
Mar 10, 2021

Conversation

ngnpope
Copy link
Member

@ngnpope ngnpope commented Mar 8, 2021

While looking at PR #14089, I noticed that there was no OrderedSet.__repr__().

I've attached this to ticket-24121 as, although OrderedSet is not listed in the ticket description, the ticket title is pretty generic about improving the repr() experience.

Base automatically changed from master to main March 9, 2021 06:22
@felixxm felixxm merged commit afb0eb8 into django:main Mar 10, 2021
@ngnpope ngnpope deleted the orderedset-repr branch March 10, 2021 08:34
Elkasitu pushed a commit to Elkasitu/django that referenced this pull request Nov 16, 2022
…rt it

This commit introduced a new database feature flag
`supports_unlimited_varchar` which denotes which database backends
support defining `VARCHAR` columns with no/unlimited size.

When this feature flag is enabled for a given backend, CharField
definitions may rely on the default `max_length` value of `None` instead
of having to explicitly define one. It is however still possible to
explicitly pass a `max_length` and this will be enforced at the database
level.

This commit also implemented the necessary changes for the feature to
apply to the postgres backend.
Elkasitu pushed a commit to Elkasitu/django that referenced this pull request Nov 21, 2022
…rt it

This commit introduced a new database feature flag
`supports_unlimited_varchar` which denotes which database backends
support defining `VARCHAR` columns with no/unlimited size.

When this feature flag is enabled for a given backend, CharField
definitions may rely on the default `max_length` value of `None` instead
of having to explicitly define one. It is however still possible to
explicitly pass a `max_length` and this will be enforced at the database
level.

This commit also implemented the necessary changes for the feature to
apply to the postgres backend.
Elkasitu pushed a commit to Elkasitu/django that referenced this pull request Nov 22, 2022
…rt it

This commit introduced a new database feature flag
`supports_unlimited_varchar` which denotes which database backends
support defining `VARCHAR` columns with no/unlimited size.

When this feature flag is enabled for a given backend, CharField
definitions may rely on the default `max_length` value of `None` instead
of having to explicitly define one. It is however still possible to
explicitly pass a `max_length` and this will be enforced at the database
level.

This commit also implemented the necessary changes for the feature to
apply to the postgres backend.
Elkasitu pushed a commit to Elkasitu/django that referenced this pull request Dec 14, 2022
…rt it

This commit introduced a new database feature flag
`supports_unlimited_varchar` which denotes which database backends
support defining `VARCHAR` columns with no/unlimited size.

When this feature flag is enabled for a given backend, CharField
definitions may rely on the default `max_length` value of `None` instead
of having to explicitly define one. It is however still possible to
explicitly pass a `max_length` and this will be enforced at the database
level.

This commit also implemented the necessary changes for the feature to
apply to the postgres backend.
Elkasitu pushed a commit to Elkasitu/django that referenced this pull request Dec 15, 2022
…rt it

This commit introduced a new database feature flag
`supports_unlimited_varchar` which denotes which database backends
support defining `VARCHAR` columns with no/unlimited size.

When this feature flag is enabled for a given backend, CharField
definitions may rely on the default `max_length` value of `None` instead
of having to explicitly define one. It is however still possible to
explicitly pass a `max_length` and this will be enforced at the database
level.

This commit also implemented the necessary changes for the feature to
apply to the postgres backend.
Elkasitu pushed a commit to Elkasitu/django that referenced this pull request Dec 15, 2022
…rt it

This commit introduced a new database feature flag
`supports_unlimited_varchar` which denotes which database backends
support defining `VARCHAR` columns with no/unlimited size.

When this feature flag is enabled for a given backend, CharField
definitions may rely on the default `max_length` value of `None` instead
of having to explicitly define one. It is however still possible to
explicitly pass a `max_length` and this will be enforced at the database
level.

This commit also implemented the necessary changes for the feature to
apply to the postgres backend.
Elkasitu pushed a commit to Elkasitu/django that referenced this pull request Dec 16, 2022
…rt it

This commit introduced a new database feature flag
`supports_unlimited_varchar` which denotes which database backends
support defining `VARCHAR` columns with no/unlimited size.

When this feature flag is enabled for a given backend, CharField
definitions may rely on the default `max_length` value of `None` instead
of having to explicitly define one. It is however still possible to
explicitly pass a `max_length` and this will be enforced at the database
level.

This commit also implemented the necessary changes for the feature to
apply to the postgres backend.

Co-authored-by: Mariusz Felisiak <felisiak.mariusz@gmail.com>
Elkasitu pushed a commit to Elkasitu/django that referenced this pull request Dec 16, 2022
…rt it

This commit introduced a new database feature flag
`supports_unlimited_varchar` which denotes which database backends
support defining `VARCHAR` columns with no/unlimited size.

When this feature flag is enabled for a given backend, CharField
definitions may rely on the default `max_length` value of `None` instead
of having to explicitly define one. It is however still possible to
explicitly pass a `max_length` and this will be enforced at the database
level.

This commit also implemented the necessary changes for the feature to
apply to the postgres backend.

Co-authored-by: Mariusz Felisiak <felisiak.mariusz@gmail.com>
felixxm added a commit to Elkasitu/django that referenced this pull request Dec 28, 2022
…eSQL.

Co-authored-by: Mariusz Felisiak <felisiak.mariusz@gmail.com>
felixxm added a commit to Elkasitu/django that referenced this pull request Dec 28, 2022
…eSQL.

Co-authored-by: Mariusz Felisiak <felisiak.mariusz@gmail.com>
felixxm added a commit to Elkasitu/django that referenced this pull request Dec 28, 2022
…eSQL.

Co-authored-by: Mariusz Felisiak <felisiak.mariusz@gmail.com>
sabderemane pushed a commit to sabderemane/django that referenced this pull request Jun 1, 2023
…eSQL.

Co-authored-by: Mariusz Felisiak <felisiak.mariusz@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants