On 06/27/2018 12:04 PM, Elazar wrote:

בתאריך יום ד׳, 27 ביוני 2018, 11:59, מאת Guido van Rossum:

...

Sounds to me really strange that the nested class would become a member. Probably because everything becomes a member unless it's a function (maybe decorated)?

People working with sum types might expect the instances of the nested class to be instances of the enclosing class. So if the nested class is a namedtuple, you get a sum type. The only problem is that there's no way to express this subtype relationship in code.

I have no idea what you just said. :( Is there a link you can share that might explain it? -- ~Ethan~

Yes, Ryan. I mean a way to express something like sealed classes in scala/kotlin. The Enum class defines a finite region in which subclasses can be defined, thus allows verifying that "elif" cases are exhaustive, for exampe. It mostly helpful for static type checking, but it also helps readability and is a natural way to describe ASTs. class Expr(Enum): class BinOp(NamedTuple): # ideally should subclass Expr left: Expr right: Expr op: str class UnOp(NamedTuple): operator: Expr operand: str ... It's one of the (rejected) ideas here: https://github.com/python/mypy/issues/2464 Not the best link out there but it explains: https://antonioleiva.com/sealed-classes-kotlin/ Elazar On Wed, Jun 27, 2018 at 12:49 PM Ryan Gonzalez wrote:

I *think* he's referring to something like this:

class A(enum.Enum): class Inner(NamedTuple): ...

isinstance(A.Inner(), A()) # True

I *think* that's it.

On June 27, 2018 2:26:23 PM Ethan Furman wrote:

...

On 06/27/2018 12:04 PM, Elazar wrote:

...

בתאריך יום ד׳, 27 ביוני 2018, 11:59, מאת Guido van Rossum:

...

...

Sounds to me really strange that the nested class would become a member. Probably because everything becomes a member unless it's a function (maybe decorated)?

People working with sum types might expect the instances of the nested class to be instances of the enclosing class. So if the nested class is a namedtuple, you get a sum type. The only problem is that there's no way to express this subtype relationship in code.

I have no idea what you just said. :( Is there a link you can share that might explain it?

-- ~Ethan~ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On 06/27/2018 11:52 AM, Guido van Rossum wrote:

Sounds to me really strange that the nested class would become a member. Probably because everything becomes a member unless it's a function (maybe decorated)?

Pretty much. __dunders__, _sunders_, and descriptors do not get transformed. Everything else does. -- ~Ethan~

Greg Or perhaps this could be made to work somehow:

class Color(Enum(int)): RED = 1 GREEN = 2 BLUE = 3 i_get_left_alone = 4.2

Enum already is callable - it creates Enum subclasses. e.g. Color = Enum("Color", ("RED", "GREEN", "BLUE")) (or something similar, I didn't check the docs.) In general, it sounds to me like you already can avoid them becoming members if you want - simply by making them a property. Therefore, letting them be members by default doesn't sound weird to me. As for embedded classes - well, the cannot be subclasses because the outer class is not instantiated. You could perhaps build a class decorator that injects the outer class in the inner class' MRO, but that doesn't sound like code I'd want to debug.

On Thu, Jun 28, 2018 at 06:57:45AM +0300, Serhiy Storchaka wrote:

Making a nested class a member you don't lost anything, because you always can make it not-nested if you don't want it be a member.

You lose the ability to have Colors.RED.NestedClass() # returns something useful # similar to Colors.RED.method() for the (dubious?) advantage of having Colors.NestedClass treated as a colour enum.

But when a nested class is not a member, you would lost the possibility of making it a member (and this may break existing code).

I must admit I'm still perplexed why I might want NestedClass to be an enum member. -- Steve

On 1 July 2018 at 20:47, Ethan Furman wrote:

On 07/01/2018 06:03 AM, Ivan Levkivskyi wrote:> On 27 June 2018 at 15:46, Ethan Furman wrote:

[...]

...

...

So I'm asking the community: What real-world examples can you offer for either behavior? Cases where nested classes should be enum members, and cases where nested classes should not be members.

I wanted few times to make an enum of enums. For example:

class Method(Enum): Powell = 1 Newton_CG = 2 <few more> class Trust(Enum): Constr = 3 Exact = 4 <few more>

So that one can write:

minimize(..., method=Method.Powell) minimize(..., method=Method.Trust.Exact) # this currently fails

In such a case, would you want/expect for

--> list(Method)

to return

[, , ..., ]

?

I am fine with what `list(Method)` does currently: [, , >] I think it is intuitive that the nested enums are _not_ automatically flattened. Also it is easy to write a helper that manually flattens nested enums, but it would be tedious to group them back if they are already flattened. The only thing that I find a bit unintuitive is that one needs to write `Method.Trust.value.Exact` instead of just `Method.Trust.Exact`. Maybe his can be allowed by adding a `__getattr__` to `Method` (by the metaclass) that will check if a value is an enum and delegate the attribute access. -- Ivan