Hi Fernando,
On Mon, 16 Sep 2019 08:59:17 -0700 (PDT)
Fernando Macedo wrote:
> Hi everyone, I come late to the party and only noticed that Django
> now has support for enums on the 3.0 release notes. As I'm not a core
> developer I never imagined this.
Late is better than never... I should poin
Hi everyone, I come late to the party and only noticed that Django now has
support for enums on the 3.0 release notes. As I'm not a core developer I
never imagined this.
I've wrote a lib that does something similar in mid-2018:
https://github.com/loggi/python-choicesenum
There's one main diff
Hi all,
A bit of an issue came about in the PR: If you define an enum class
which inherits `str`, there's an ambiguity when asking for its string
representation (that is, explicit conversion to `str`) -- between it
simply being a `str`, and Enum's `__str__()` which returns
`Type.NAME'.
The ambig
On 4/13/19 10:22 PM, Markus Holtermann wrote:
Thanks for the proposal, Shai. I quite like it.
As discussed at the DCEU sprints I think I'd like to be able to omit the display form of an item and have it auto
generated from an item's name, i.e. turning "FOO_BAR" into "Foo Bar" (`key.replace("_",
On Sat, 13 Apr 2019 08:22:11 -0400
"Markus Holtermann" wrote:
>
> As discussed at the DCEU sprints I think I'd like to be able to omit
> the display form of an item and have it auto generated from an item's
> name, i.e. turning "FOO_BAR" into "Foo Bar" (`key.replace("_", "
> ").title()`)
>
Yes
I really like this implementation, it seems really clean and simple.
I would suggest that it might be worth seeing it’s simple to make the
display text optional, I think in the general case capitalising the key
name would be acceptable. Users can always override it if required or if
they need tran
Thanks for the proposal, Shai. I quite like it.
As discussed at the DCEU sprints I think I'd like to be able to omit the
display form of an item and have it auto generated from an item's name, i.e.
turning "FOO_BAR" into "Foo Bar" (`key.replace("_", " ").title()`)
Further, we could also simplif
Back to this issue for the DjangoCon EU sprints...
James' objection about the inclusion testing needed for validation
seems moot, because validation can be done by conversion to the enum
type (as noted by Tom).
Raphael's warning about the woes of translation are already handled by
the suggested i
I saw this thread so wanted to share a bit of a gotcha we had with enums
internally for anyone trying to handle this stuff
Internally, we have a wrapper around CharField to work with enums (we go
further than just choices and actually have the values be enums), but
there's unfortunately still a
While I agree that Enum’s are a bit clunky (and IMO removing in is a poor
choice), is this going to really take be that hard to work with or that
difficult to validate?
Enums are types that raise ValueError, like any other, so it’s not that
confusing and fits in with Django’s existing validation c
Shai, your rebuttal still misses an important use case, which is
containment.
To continue with your example of a 'SchoolYear(str, Enum)', the following
will both be False:
'FR' in SchoolYear
'FR' in SchoolYear.__members__
The first of those is also becoming illegal soon -- attempting an 'in'
com
I've also tried to come up with something better than Django's current
default, using Enums, and found them lacking when it comes to the
caption, especially when you need translations.
I would be happy with re-opening the ticket, but in terms of committing
a solution I would be -1 unless we ca
On Mon, 31 Dec 2018 23:40:53 +
Tom Forbes wrote:
>
> We currently have a -1 and a +1, does anyone else have any input on
> this?
>
So, the tally is +3, -1, and the -1 seems to be based on a technical
argument which I believe I refuted; and more than a week has passed
with no further comment
I would also love to see a decent way to use enums as choices. The
translation issues seem the stickiest to me, but I'm kinda hoping we can
come up with something reasonable.
I'm a heavy user, but mostly a lurker on this list, but +1 from me for what
it's worth.
Ryan
On Mon, Dec 31, 2018, 17:41
Unfortunately I made this for a python 2 app before enums where in the
standard library. I think it has some useful ideas though especially around
categories, which I find I needed a lot. I'd be interested to know if
anyone else has written any workflow-driven apps in Django that require
groups of
Hi Tom,
On Mon, 31 Dec 2018 18:26:14 +
Tom Forbes wrote:
> I was describing my django-choice-object library[1] and forgot to
> link it!
>
Thanks, I took a look -- the library looks nice, but notably, Choice
objects are not Python enums, although they share some of their traits.
> I would
Hi James,
On Mon, 31 Dec 2018 10:24:39 -0800
James Bennett wrote:
> The basic problem is that, to take the example in the ticket, if I
> were to issue a request like "/students/?year=FR", and the view were
> to read that "year" param and try to filter on it, it would fail --
> the string "FR" wi
Hey Shai,
I have not had a chance to look at the implementation, but I was describing
my django-choice-object library[1] and forgot to link it!
I would be +1 on re-opening it, I've used enums for this before and I find
it much more DRY than the more 'standard' Django way. Perhaps we could
reduce s
FWIW I'm pretty strongly -1 on this feature because Python's enums don't
behave the way people want them to for many use cases.
The basic problem is that, to take the example in the ticket, if I were to
issue a request like "/students/?year=FR", and the view were to read that
"year" param and try
Hi all,
Lately I've run into ticket 27910[1], which asks for Python Enums to be
usable for generating choices in Django model (and form) fields. This
ticket was closed Wontfix because the original suggestion did not offer
any way to handle translated labels. However, after the ticket was
closed, T
20 matches
Mail list logo