Mailman 3 July 2018 - Python-ideas

Including the unparse module in the standard library
by Andre Roberge 16 Jul '18

16 Jul '18

In the cPython repository, there is an unparse module in the Tools section. https://github.com/python/cpython/blob/master/Tools/parser/unparse.py However, as it is not part of the standard library, it cannot be easily used; to do so, one needs to make a local copy in a place from where it can be imported. This module can be useful for people using the ast module to create and parse trees, modify them ... and who want to convert the result back into source code. Since it is obviously maintained to be compatible with the current Python version, would it be possible to include the unparse module in the standard library? André Roberge

4 3

Do not block threads when pickle/unpickle
by Martin Bammer 16 Jul '18

16 Jul '18

Hi, the old and slow python implementation of pickle didn't block background thread. But the newer C-implementation blocks other threads while dump/load is running. Wouldn't it be possible to allow other threads during this time? Especially could load/loads release the GIL, because Python objects are not available to the Python code until these functions have finished? Regards, Martin

3 4

Unicode Name Aliases keyword argument abbreviation in unicodedata.name for missing names
by Robert Vanden Eynde 16 Jul '18

16 Jul '18

unicodedata.name<http://unicodedata.name> raises KeyError for a few unicode characters like '\0' or '\n', altough the documentation is very clear on the implementation, this is often not what people want, ie. a string describing the character. In Python 3.3, the name aliases became accepted in unicodedata.lookup('NULL') and '\N{NULL}' == '\N{NUL}'. One could expect that lookup(name(x)) == x for all unicode character but this property doesn't hold because of the few characters that do not have a name (mainly control characters). The use case where the KeyError is raised when a codepoint for a unused character or newest version of unicode is however still useful. In the NameAliases https://www.unicode.org/Public/6.3.0/ucd/NameAliases.txt one can see that some characters have multiple aliases, so there are multiple ways to map a character to a name. I propose adding a keyword argument, to unicodedata.name<http://unicodedata.name> that would implement one of some useful behavior when the value does not exist. In that case. One simple behavior would be to chose the name in the "abbreviation" list. Currently all characters except three only have one and only one abbreviation so that would be a good pick, so I'd imagine name('\x00', abbreviation=True) == 'NUL' The three characters in NameAlias.txt that have more than one abbreviation are : '\n' with ['LF', 'NL', 'EOL'] '\t' with ['HT', 'TAB'] '\ufeff' with ['BOM', 'ZWNBSP'] In case multiple abbreviations exist, one could take the first introduced to unicode (for backward compability with python versions). If this is a tie, one could take the first in the list. If it has no name and no abbreviation, unicodata.name<http://unicodata.name> raises an error or returns default as usual. lookup(name(x)) == x for all x is natural isn't it ?

5 11

Re: [Python-ideas] Add the imath module
by Jeroen Demeyer 15 Jul '18

15 Jul '18

On 2018-07-12 20:11, Steven D'Aprano wrote: > about 4.7 seconds to test 2**800 + 1; In SageMath: sage: n = 2**800+1; timeit('is_prime(n)') 625 loops, best of 3: 303 µs per loop That's 4 orders of magnitude faster...

7 11

Make import an expression
by Ken Hilton 14 Jul '18

14 Jul '18

Hi all, Just a curious idea I had. The subject says it all. "import" is currently a statement, which means it cannot be used inside anything else. Currently, the only way to import a module inside an expression is to use the __import__ function, which is both cumbersome and takes up more space (which is disadvantageous in things like code golf). I propose making "import" an expression, thus allowing the syntactic sugar of "import module" -> "__import__('module')" to be graduated to the expression level. Because of operator precedence, I suspect that in most cases one would need to surround the expression with parentheses. An additional effect that is not seen with using __import__ is that the module's name is bound to the current scope the way it is with a normal import statement. Examples of where this could be used: Importing on the fly to generate one value: secret = (import random).randint(1, 100) Quick use of itertools in generator expressions: (i * i for i in (import itertools).accumulate(generate_numbers())) Re-using a function from a module after importing it in an expression: b = a * (import math).tan(math.radians(45)) #math.radians is valid because (import math) binds "math" to the current scope What are your thoughts? Sharing, Ken Hilton;

5 4

Re: [Python-ideas] Add the imath module
by Jeroen Demeyer 13 Jul '18

13 Jul '18

On 2018-07-13 14:11, Steven D'Aprano wrote: > What it *actually* does is: > > is_almost_certainly_prime_except_for_a_ludicrously_microscopic_chance_of_error_thousands_of_times_less_likely_than_a_stray_cosmic_ray_flipping_a_bit_in_memory_and_causing_the_wrong_result_to_be_returned() That's just a long variant of is_probable_prime() > If your bank is satisfied with "mere probable prime number" to transfer > billions of dollars around the world, then I'm sure that the users of > Python's std library should be too. That's besides the point. I agree that probable primes are good enough, just don't call them "prime".

6 5

Fwd: grouping / dict of lists
by David Mertz 13 Jul '18

13 Jul '18

Steven: You've misunderstood part of the discussion. There are two different signatures being discussed/proposed for a grouping() function. The one you show we might call grouping_michael(). The alternate API we might call grouping_chris(). These two calls will produce the same result (the first output you show) grouping_michael(words, keyfunc=len) grouping_chris((len(word), word) for word in words) I happen to prefer grouping_michael(), but recognize they each make slightly different things obvious. Absolutely no one wants the behavior in your second output. On Tue, Jul 3, 2018, 9:32 PM Steven D'Aprano <steve(a)pearwood.info> wrote: > Of course you can prepare the sequence any way you like, but these are > not equivalent: > > grouping(words, keyfunc=len) > grouping((len(word), word) for word in words) > > The first groups words by their length; the second groups pairs of > (length, word) tuples by equality. > > py> grouping("a bb ccc d ee fff".split(), keyfunc=len) > {1: ['a', 'd'], 2: ['bb', 'ee'], 3: ['ccc', 'fff']} > > py> grouping((len(w), w) for w in "a bb ccc d ee fff".split()) > {(3, 'ccc'): [(3, 'ccc')], (1, 'd'): [(1, 'd')], (2, 'ee'): [(2, 'ee')], > (3, 'fff'): [(3, 'fff')], (1, 'a'): [(1, 'a')], (2, 'bb'): [(2, ' >

5 11

Re: [Python-ideas] Add the imath module
by Jeroen Demeyer 13 Jul '18

13 Jul '18

On 2018-07-13 04:02, Chris Angelico wrote: > Haha. Okay. I'm not familiar with every possible primality test, so I > had no idea that they ALL have the same failure mode :) There exist guaranteed primality tests, but those are much slower and more complicated. The state of the art is ECPP: https://en.wikipedia.org/wiki/Elliptic_curve_primality

4 3

Re: [Python-ideas] Add the imath module
by Jeroen Demeyer 13 Jul '18

13 Jul '18

On 2018-07-13 14:26, Steven D'Aprano wrote: > I'm pretty sure that Sage is using numpy This computation uses PARI/GP, a dedicated library for number theory (https://pari.math.u-bordeaux.fr/) with a Python interface (https://github.com/defeo/cypari2). > And it's > probably making far less conservative choices about the rate of false > positives it is willing to accept. It's an actual primality test, not a probable primality test. But for numbers which are not prime (like your examples), the difference doesn't actually matter.

1 0

Re: [Python-ideas] Add the imath module
by Jeroen Demeyer 13 Jul '18

13 Jul '18

On 2018-07-13 11:50, Jacco van Dorp wrote: > At the very least, use is_likely_prime() as function name. I agree with you here: the function name should reflect what it actually does. (Note that the technical term is "probable prime", so it should be is_probable_prime) But I don't think that the Python stdlib should have a proven is_prime() function because that would be complicated, slow and have very limited benefit over is_probable_prime().

2 1

Re: [Python-ideas] Add the imath module
by Jeroen Demeyer 13 Jul '18

13 Jul '18

On 2018-07-13 10:43, Jacco van Dorp wrote: > If there's going to be failure possible primality tests, there should > also exist certain ones. No matter how slow it can be to do it. A certain primality test would be too specialized for the Python stdlib. If you really need that (which you typically don't), there are existing number theory packages.

2 1

Re: [Python-ideas] Add the imath module
by Jeroen Demeyer 12 Jul '18

12 Jul '18

If you want inspiration: https://github.com/sagemath/sage/blob/master/src/sage/arith/misc.py

1 0

anyone need a frozenset or bytearray literal?
by Gregory P. Smith 12 Jul '18

12 Jul '18

Completely obvious what it does, but it irritates my aesthetic sensibilities every time I see: frozenset({spam, eggs}) Why? Because I assume under the hood that creates a set of spam and eggs before calling frozenset to copy it into a new frozenset object before the original set is garbage collected. Wasteful. This is in fact what happens in CPython 3.7 today. I'd love to avoid this. I have no rational measured reason to believe it even matters (thus seeding this on python-ideas and not elsewhere), even though it would technically speed up frozenset creation. (a) detecting frozenset({}) as syntax to encode a frozenset in the python bytecode would be somewhat magical. it could break the person unfortunate enough to monkeypatch out the frozenset builtin (really? don't do that!). (b) abusing the concept of letter prefixes as we already have for strings on {} syntax would be possible but not at all obvious to a reader: f{} or c{} or r{} perhaps. but then someone would want a frozendict. (c) adding a .freeze() method to sets which would raise an exception if the set's refcount were > 1 and would mutate the type of the set object into a frozenset object in place. refcount assertions are bad, not all VMs need refcounts. The concept of a method that can mutate the type of the underlying object in place is... unpythonic. even though technically possible to implement within CPython. I'm -1 on all of my ideas above. But figured I'd toss them out there as food for thought for the concept. We lived for years without even having a set literal in the first place. So this isn't a big deal. frozenset is not the only base type that lacks a literals leading to loading values into these types involving creation of an intermediate throwaway object: bytearray. bytearray(b'short lived bytes object') I was going to suggest complex was in this boat as well, but upon investigation we appear to do constant folding (or amazing parsingon that so 0.3+0.6j does turn into a single LOAD_CONST instead of two consts and an addition. Nice! Not that I expect practical code to use complex numbers. -gps

8 11

Add new `Symbol` type
by Flavio Curella 10 Jul '18

10 Jul '18

More than once I've found myself wanting to create a 'sentinel' value. The most common use case is to differentiate between an argument that has not been provided, and an argument provided with the value `None`. This would be solvable by implementing something similar to what JavaScript calls [`Symbol`]( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Ob… ). This could be implemented as a 3rd-party library, but there won't be a way to have ['Global' Symbols]( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Ob… ) Furthermore, without a common implementation in the std library, various Python libraries had to write their own implementations, which all differs in functionality and behavior. Is this something that the Python community is interested in? I'm willing to write the PEP

11 12

Re: [Python-ideas] Calling python from C completely statically
by Barry 10 Jul '18

10 Jul '18

> On 10 Jul 2018, at 19:12, Alberto Garcia <agarciaillera(a)gmail.com> wrote: > > Thank you Barry, > > but I see that the the way yo do it is dropping files to disk. I want to prevent any file to touch the disk except for the actual binary that has everything embedded in it. What file are you refering to? The zip is built onto the elf/exe. BTW this is all off topic for python ideas. You might want to take this offline. Barry > > Cheers > >> On Tue, Jul 10, 2018 at 10:25 AM Barry <barry(a)barrys-emacs.org> wrote: >> >> >>> On 9 Jul 2018, at 21:11, Alberto Garcia <agarciaillera(a)gmail.com> wrote: >>> >>> Hi, >>> >>> thank you for your response. I've downloaded the sources but I couldn't find any documentation. In addition I see that there is not a single C/C++ file. What I want to do is calling python from C. >>> Am I missing something? >> >> You need to grab the sources with an svn checkout. I guess you grabbed the binary kit. >> >> https://sourceforge.net/p/meinc-installer/code/HEAD/tree/trunk/MEINC_Instal… >> >> Docs are in here. >> >> https://sourceforge.net/p/meinc-installer/code/HEAD/tree/trunk/MEINC_Instal… >> >> Barry >> >>> Cheers >>> >>> >>>> On Mon, Jul 9, 2018 at 12:20 PM Barry Scott <barry(a)barrys-emacs.org> wrote: >>>> I think you might find Gordon McMillian's installer interesting to look at. It has a lot >>>> f the tech that I think you are looking for. >>>> >>>> Works up to python 2.7. I ended up taking over when Gordon stopped maintaining >>>> it and kept it going up to python 2.7. In principle the same ideas could be made to >>>> work in python 3 I believe. >>>> >>>> https://sourceforge.net/projects/meinc-installer/ >>>> >>>> The zip file is appended to the end of the .EXE or unix ELF fie. >>>> The boot strap knows how to import form the ZIP at the end of >>>> the binary. >>>> >>>> It also has a way to split out the .SO/.DLL files from the ZIP and >>>> allow them to be loaded. Single EXE mode. >>>> >>>> There are docs that explain how it works in the sources. >>>> >>>> Barry >>>> >>>> >>>> >>>>> On 9 Jul 2018, at 19:40, Alberto Garcia <agarciaillera(a)gmail.com> wrote: >>>>> >>>>> Does the zip need to reside in disk to be loaded. Or can it be loaded from memory? I don't want it to be loaded from disk but from Memory >>>>> >>>>> >>>>> >>>>>> On Mon, Jul 9, 2018 at 9:59 AM Alberto Garcia <agarciaillera(a)gmail.com> wrote: >>>>>> Ohhhhhhhh I guess you mean this: >>>>>> https://github.com/anthony-tuininga/cx_Freeze/blob/master/source/bases/Comm… >>>>>> >>>>>> Right? >>>>>> >>>>>>> On Mon, Jul 9, 2018 at 9:48 AM Alberto Garcia <agarciaillera(a)gmail.com> wrote: >>>>>>> Thank you for your response, >>>>>>> >>>>>>> I was thinking on creating that zip file with the content of the Lib folder and having my c code to download it over the network and have it in memory. >>>>>>> I guess that the zip file should have no compression at all right? >>>>>>> >>>>>>> When you say that I need to use the cx_freeze approach what do you mean? Can you point me to where they do that? >>>>>>> >>>>>>> And why changing sys.path again to the executable again? Which part of the executable? >>>>>>> >>>>>>> I'll put my efforts in this. >>>>>>> >>>>>>> Thank you >>>>>>> >>>>>>>> On Mon, Jul 9, 2018 at 7:16 AM Nick Coghlan <ncoghlan(a)gmail.com> wrote: >>>>>>>> On 9 July 2018 at 03:10, Alberto Garcia <agarciaillera(a)gmail.com> wrote: >>>>>>>> > Hey there, >>>>>>>> > >>>>>>>> > Yes, the part of having the pyd modules built in in library is already done. >>>>>>>> > I followed the instructions in the README. What I would like to know now is >>>>>>>> > how to embed the non frozen python (py) modules. Can you guys please point >>>>>>>> > me in the right direction. >>>>>>>> >>>>>>>> The gist is to: >>>>>>>> >>>>>>>> 1. take the entire Lib directory and put it in a zip archive >>>>>>>> 2. use the approach demonstrated in cx_freeze to point sys.path in >>>>>>>> your static executable at that zip archive >>>>>>>> 3. adjust your C code to point sys.path back at the executable itself, >>>>>>>> and then combine your executable and the zip archive into a single >>>>>>>> contiguous file (similar to what zipapp does with it's helper script >>>>>>>> and app archive) >>>>>>>> >>>>>>>> There are likely to still be rough edges when doing that, since this >>>>>>>> isn't a well tested configuration. When all else fails, find the part >>>>>>>> of the source code responsible for any error messages you're seeing, >>>>>>>> and try to work out if there's a setting you can tweak to avoid >>>>>>>> hitting that code path. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Nick. >>>>>>>> >>>>>>>> -- >>>>>>>> Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia >>>>>>> -- >>>>>>> Alberto García Illera >>>>>>> >>>>>>> GPG Public Key: https://goo.gl/twKUUv >>>>>> -- >>>>>> Alberto García Illera >>>>>> >>>>>> GPG Public Key: https://goo.gl/twKUUv >>>>> >>>>> >>>>> -- >>>>> Alberto García Illera >>>>> >>>>> GPG Public Key: https://goo.gl/twKUUv >>>>> _______________________________________________ >>>>> Python-ideas mailing list >>>>> Python-ideas(a)python.org >>>>> https://mail.python.org/mailman/listinfo/python-ideas >>>>> Code of Conduct: http://python.org/psf/codeofconduct/ >>>> >>> >>> >>> -- >>> Alberto García Illera >>> >>> GPG Public Key: https://goo.gl/twKUUv > > > -- > Alberto García Illera > > GPG Public Key: https://goo.gl/twKUUv

1 0

Calling python from C completely statically
by Alberto Garcia 10 Jul '18

10 Jul '18

Hi, I've been working for a while on having the entire python interpreter with all his modules statically linked in a binary that can be called with arbitrary argument which will be passed to the python interpreter. I've been able to statically compile Python in a single binary with no dependencies for Python2.7 and using using this code to call the interpreter with arbitrary code: #define Py_NO_ENABLE_SHARED #include <Python.h> int main(int argc, char** argv) { Py_NoSiteFlag = 1; Py_InitializeEx(0); PyRun_SimpleString(argv[1]); Py_Finalize(); } This program compiles and does not rely in any dependency but the "non frozen" (.py) modules are not loaded so when I do a simple `import random` I get: Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: No module named random I've created a bug issue (https://bugs.python.org/issue34057) speaking about it and Nick Colghlan pointed: " cx_freeze is an illustrative example to look at in that regard, as it preconfigures the interpreter to be able to find the cx_freeze generated zip archive that has the program's Python modules in it: https://github.com/anthony-tuininga/cx_Freeze/blob/master/source/bases/Comm… The technique that cx_freeze doesn't use yet is to combine the statically linked Python binary and the generated zip archive into a single file (similar to what zipapp does), and adjust the sys.path definition inside the binary to refer back to the executable itself (since executable files can have arbitrary content appended, while zip files can have arbitrary content *pre*pended). " As I understand, cx_freeze creates a zip file with the dependencies for a specific python code and creates a zip with them. My question is, could I create a zip file with every standard module (plus some extra that I may install with pip) and using that zip file from C? If so, how can I do that? I'm happy to work on this if I get indications. BTW: I do not want to convert a python code snippet to exe or anything like that but calling python from C in an absolutely standalone version. Thank you -- Alberto García Illera GPG Public Key: https://goo.gl/twKUUv

5 10

Add `rc` to distutils.version.StrictVersion
by Pål Grønås Drange 06 Jul '18

06 Jul '18

StrictVersion from distutils accepts version tags like 1.14.0 1.14.0a1 1.14.0b2 but not 1.14.0rc1 (nor 1.14.0c1). My suggestion: Add `rc` in the regexp and make it a `prerelease` (the latter comes for free by the current implementation). Most package maintainers have adopted the `rc` abbreviation for release candidate versioning, e.g. - numpy 1.14.0rc1 - scipy 1.1.0rc1 - plotly 3.0.0rc1 - pandas 0.23.0rc1 - matplotlib 2.2.0rc1 - dask 0.13.0rc1 - django 1.9rc1. All of these are available on PyPI. A natural way of sorting version numbers from pip is by simply using sorted(versions, key=distutils.version.StrictVersion), however, due to StrictVersion only accepting `a` and `b` as abbreviations, this does not work for the aforemention packages. The very obvious cons are: - touching 20 years old code [1] - StrictVersion is preserved "for anal retentives and software idealists", and I don't know if they agree. There might be more cons I fail to think of at this moment. [1] https://github.com/python/cpython/blob/master/Lib/distutils/version.py#L130 Pål Grønås Drange

2 1

Re: [Python-ideas] Add new `Symbol` type
by Flavio Curella 06 Jul '18

06 Jul '18

> What functionality does such a thing actually need? I think the requirements should be: * The resulting symbol behave exactly like None. IE: the symbol should not be an instance of object, but an instance of its own class * A symbol can optionally be globally unique. * Two symbols created by the same key must not be equal. IE: they have equal key, but different value * if we're trying to create global symbols with the same key, an exception is thrown This is mostly based on the Javascript spec.

3 2

Add a __cite__ method for scientific packages
by Andrei Kucharavy 04 Jul '18

04 Jul '18

Over the last 10 years, Python has slowly inched towards becoming the most popular scientific computing language, beating or seriously challenging Matlab, R, Mathematica and many specialized languages (S, SAS, ...) in numerous applications. A large part of this growth is driven by amazing community packages, such as numpy, scipy, scikits-learn, scikits-image, seaborn or pandas, just to name a few. Development of such packages represents a significant time investment by people working in academic environments. To be able to justify the investment of time into such package development and support, the developers usually associated them with a scientific article. The number of citations of those articles are considered as measures of the usefulness of articles and are required to justify the time spent on them. Unfortunately, as of now, a significant issue is that such packages are not cited despite being extensively used. Part of this is due to the difficulties with compiling the list of proper citations for each module (and, for libraries associated with multiple update publications, selecting the relevant citation). Part of this is due to users not realizing which of the modules they are using have associated publications and should be cited. To remediate to that situation, I suggest a __citation__ method associated to each package installation and import. Called from the __main__, __citation__() would scan __citation__ of all imported packages and return the list of all relevant top-level citations associated to the packages. As a scientific package developer working in academia, the problem is quite serious, and the solution seems relatively straightforward. What does Python core team think about addition and long-term maintenance of such a feature to the import and setup mechanisms? What do other users and scientific package developers think of such a mechanism for citations retrieval? Best, *Andrei Kucharavy*Post-Doc @ *Joel S. Bader* * Lab*Johns Hopkins University, Baltimore, USA.

18 28

Fwd: grouping / dict of lists
by Chris Barker 02 Jul '18

02 Jul '18

Ivan, Did you mean this to go to the list? I hope so, as I've cc-d it this time :-) On Sun, Jul 1, 2018 at 1:20 AM, Ivan Levkivskyi <levkivskyi(a)gmail.com> wrote: > On 1 July 2018 at 06:18, Chris Barker via Python-ideas < > python-ideas(a)python.org> wrote: > >> I'm really warming to the: >> >> Alternate: collections.Grouping >> >> version -- I really like this as a kind of custom mapping, rather than >> "just a function" (or alternate constructor) -- >> > I wanted the group to be represented as a set, not a list. I however > understand that list may be more common. Can we design an API that > would make this configurable? Something like: > > from collections import Grouping > > deps = Grouping(set) # list can be the default > deps.update(other_deps) # uses set.update or list.extend for every key > deps.add(trigger, target) # uses set.add or list.append > yeah, I thought about that too -- Michael was using set() in some of his examples. But the question is -- do we have a single switchable version or just too classes? > Probably allowing an arbitrary collection for values is to general/hard. > maybe not -- if we had the criteria that you pass in any collection you wanted, as long as it had either an .append() or .add()method, it would be pretty easy to do with duck typing magic. Sure -- a user could make a mess easily enough by passing in a weird custom class, but so what? Using something other than a set or list would be a "at your own risk" thing anyway. > Maybe we can just add a flag `unique=True` to the constructor, that will > cause using sets instead of lists for groups? > That's another, more robust, but less flexible option. Stay tuned for a prototype, if I can get it done fast.... -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

2 5

Should nested classes in an Enum be Enum members?
by Ethan Furman 01 Jul '18

01 Jul '18

Consider the following Enum definition: class Color(Enum): RED = 1 GREEN = 2 BLUE = 3 @property def lower(self): return self.name.lower() def spam(self): return "I like %s eggs and spam!" % self.lower class SomeClass: pass Which of the above Color attributes are enums, and which aren't? . . . Answer: - RED, GREEN, and BLUE are members - lower and spam() are not - SomeClass /is/ a member (but not its instances) Question: Should `SomeClass` be an enum member? When would it be useful to have an embedded class in an Enum be an enum member? The only example I have seen so far of nested classes in an Enum is when folks want to make an Enum of Enums, and the nested Enum should not itself be an enum member. Since the counter-example already works I haven't seen any requests for it. ;) 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. Thanks! -- ~Ethan~

10 15