Re: [Python-Dev] Is static typing still optional?
On 01/28/2018 07:45 AM, Eric V. Smith wrote: On 1/6/2018 5:13 PM, Eric V. Smith wrote: On 12/10/2017 5:00 PM, Raymond Hettinger wrote: 2) Change the default value for "hash" from "None" to "False". This might take a little effort because there is currently an oddity where setting hash=False causes it to be hashable. I'm pretty sure this wasn't intended ;-) I haven't looked at this yet. I think the hashing logic explained in https://bugs.python.org/issue32513#msg310830 is correct. It uses hash=None as the default, so that frozen=True objects are hashable In a class, `__hash__ = None` means the instances are not hashable... but in a dataclass decorator, `hash=None` means they are? -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is static typing still optional?
On 1/29/2018 3:42 AM, Ethan Furman wrote: On 01/28/2018 07:45 AM, Eric V. Smith wrote: On 1/6/2018 5:13 PM, Eric V. Smith wrote: On 12/10/2017 5:00 PM, Raymond Hettinger wrote: 2) Change the default value for "hash" from "None" to "False". This might take a little effort because there is currently an oddity where setting hash=False causes it to be hashable. I'm pretty sure this wasn't intended ;-) I haven't looked at this yet. I think the hashing logic explained in https://bugs.python.org/issue32513#msg310830 is correct. It uses hash=None as the default, so that frozen=True objects are hashable In a class, `__hash__ = None` means the instances are not hashable... but in a dataclass decorator, `hash=None` means they are? It means "don't add a __hash__ attribute, and rely on the base class value". But maybe it should mean "is not hashable". But in that case, how would we specify the "don't add __hash__" case? Note that "repr=False" means "don't add a __repr__", not "is not repr-able". And "init=False" means "don't add a __init__", not "is not init-able". Eric. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is static typing still optional?
> On Jan 28, 2018, at 11:52 PM, Eric V. Smith wrote: > > I think it would be a bad design to have to opt-in to hashability if using > frozen=True. I respect that you see it that way, but it doesn't make sense to me. You can have either one without the other. It seems to me that it is clearer and more explicit to just say what you want rather than having implicit logic guess at what you meant. Otherwise, when something goes wrong, it is difficult to debug. The tooltips for the dataclass decorator are essentially of checklist of features that can be turned on or off. That list of features is mostly easy-to-use except for hash=None which has three possible values, only one of which is self-evident. We haven't had much in the way of user testing, so it is a significant data point that one of your first users (me) found was confounded by this API. I recommend putting various correct and incorrect examples in front of other users (preferably experienced Python programmers) and asking them to predict what the code does based on the source code. Raymond ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is static typing still optional?
On 01/29/2018 12:57 AM, Eric V. Smith wrote: On 1/29/2018 3:42 AM, Ethan Furman wrote: On 01/28/2018 07:45 AM, Eric V. Smith wrote: I think the hashing logic explained in https://bugs.python.org/issue32513#msg310830 is correct. It uses hash=None as the default, so that frozen=True objects are hashable In a class, `__hash__ = None` means the instances are not hashable... but in a dataclass decorator, `hash=None` means they are? It means "don't add a __hash__ attribute, and rely on the base class value". But maybe it should mean "is not hashable". But in that case, how would we specify the "don't add __hash__" case? I thought `hash=False` means don't add a __hash__ method.. Note that "repr=False" means "don't add a __repr__", not "is not repr-able". And "init=False" means "don't add a __init__", not "is not init-able". Yeah, like that. I get that the default for all (or at least most) of the boring stuff should be "just do it", but I don't think None is the proper place-holder for that. Why not make an `_default = object()` sentinel and use that for the default? At least for __hash__. Then we have: hash=False -> don't add one hash=None -> add `__hash__ = None` (is not hashable) hash=True -> add one (the default... Okay, after writing that down, why don't we have the default value for anything automatically added be True? With True meaning the dataclass should have a custom whatever, and if the programmer did not provide one the decorator will -- it can even be a self-check: if the parameters in the decorator are at odds with the actual class contents (hash=None, but the class has a __hash__ method) then an exception could be raised. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sad buildbots
Hi, test_ftplib just failed on my PR, whereas my change couldn't explain the failure. I created https://bugs.python.org/issue32706: "test_check_hostname() of test_ftplib started to fail randomly" Temporary workaround: restart the failed Travis CI job. Victor 2018-01-29 0:23 GMT+01:00 Ned Deily : > On Jan 28, 2018, at 18:00, Victor Stinner wrote: >> It seems like the feature freeze is close: while I usually get 2 >> emails/day at maximum on buildbot-status, I got 14 emails during the >> weekend: >> https://mail.python.org/mm3/archives/list/buildbot-sta...@python.org/ >> (are all buildbots red? :-p) >> >> I will not have the bandwidth to analyze all buildbot failures. Can >> someone help to investigate all these funny new regressions? >> http://buildbot.python.org/all/#/builders >> >> I would feel safer to cut a release if most buildbots are green again. > > Never fear, we're *not* going to do a release in such a state. That's one of > the reasons we have release managers. :-) > > Not surprisingly, there has been a *lot* of activity over the last few days > as core-developers work on getting features finished prior to the 3.7 feature > code freeze coming up at the end of Monday AoE. Some of the intermediate > checkins cause some breakages across the board, unfortunately, that have > subsequently been addressed. Most of the 3.x stable buildbots are currently > green with some builds still going on. But, yeah, please all keep an eye of > them especially those of you merging code. Just because the CI tests passed > doesn't mean there won't be problems on other platforms and configurations. > > Thanks for everyone's help so far! We're getting close. > > -- > Ned Deily > n...@python.org -- [] > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is static typing still optional?
On 1/29/2018 4:01 AM, Raymond Hettinger wrote: On Jan 28, 2018, at 11:52 PM, Eric V. Smith wrote: I think it would be a bad design to have to opt-in to hashability if using frozen=True. I respect that you see it that way, but it doesn't make sense to me. You can have either one without the other. It seems to me that it is clearer and more explicit to just say what you want rather than having implicit logic guess at what you meant. Otherwise, when something goes wrong, it is difficult to debug. I certainly respect your insights. The tooltips for the dataclass decorator are essentially of checklist of features that can be turned on or off. That list of features is mostly easy-to-use except for hash=None which has three possible values, only one of which is self-evident. Which is the one that's self-evident? I would think hash=False, correct? The problem is that for repr=, eq=, compare=, you're saying "do or don't add this/these methods, or if true, don't even add it if it's already defined". The same is true for hash=True/False, with the complication of the implicit __hash__ that's added by __eq__. In addition to "do or don't add __hash__", there needs to be a way of setting __hash__=None. The processing of hash=None is trying to guess what sort of __hash__ you want: not set it and just inherit it, generate it based on fields, or set it to None. And if it guesses wrong, based on the fairly simple hash=None rules, you can control it with other values of hash=. Maybe that's the problem. I'm open to ways to express these options. Again, I think losing "do the right thing most of the time without explicitly setting hash=" would be a shame, but not the end of the world. And changing it to "hashable=" isn't quite as simple as it seems, since there's more than one definition of hashable: identity-based or field-based. We haven't had much in the way of user testing, so it is a significant data point that one of your first users (me) found was confounded by this API. I recommend putting various correct and incorrect examples in front of other users (preferably experienced Python programmers) and asking them to predict what the code does based on the source code. I agree it's sub-optimal, but it's a complex issue. What would the interface look like that allowed a programmer to know if an object was hashable based on object identity versus field values? Eric. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Making "-j0" the default setting for the test suite?
I was going to argue, but it's not worth it. What you propose is fine. On Sun, Jan 28, 2018 at 10:03 PM, Nick Coghlan wrote: > On 29 January 2018 at 14:43, Guido van Rossum wrote: > > So why can't you just run "make test" if that's faster? > > I can (and do), but I also run it the other way if I need to pass > additional options. I'll then notice that I forgot -j0, ctrl-C out, > then run it again with -j0. > > That's a minor irritation for me, but for folks that don't already > know about the -j0 option, they're more likely to just go "CPython's > test suite is annoyingly slow". > > To provide a bit more detail on what I'd suggest we do: > > * "-j1" would explicitly turn off multiprocessing > * "-j0" and "-jN" (N >= 2) would explicitly request multiprocessing > and error out if there's a conflicting flag > * not setting the flag would be equivalent to "-j0" by default, but > "-j1" if a conflicting flag was set > > The testing options that already explicitly conflict with the > multiprocessing option are: > > * -T (tracing) > * -l (leak hunting) > > "-j1" would likely also be a better default when the verbosity flags > are set (since the output is incredibly hard to read if you have > multiple verbose tests running in parallel). > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Making "-j0" the default setting for the test suite?
> * "-j1" would explicitly turn off multiprocessing Running tests "sequentially" but run them in one subprocess per test file is interesting for tests isolation. Runing tests one by one reduces the risk of triggering a race condition (test only failing when the system load is high). -jN was always documented as "use multiprocessing". Maybe we need a new option to explicitly disable multiprocessing instead? vstinner@apu$ ./python -m test Run tests sequentially vs vstinner@apu$ ./python -m test -j1 Run tests in parallel using 1 child processes By the way, Python 2.7 behaves differently and it's annoying: vstinner@apu$ ./python -m test -j0 Run tests sequentially I'm in favor of modifying Python 2.7 to detect the number of cores for -j0, as Python 3.6 does, and run tests in parallel. Python 3.6: vstinner@apu$ ./python -m test -j0 Run tests in parallel using 10 child processes About the default: run tests in parallel or -j1 are the two most reliable options. While -j0 is faster, sometimes it triggers race conditions. I'm not sure that it's safe to change that, at least maybe don't do that in stable branches but only master? Note: Obviously, I'm strongly in favor of fixing all race conditions. I'm doing that for years. We are better today, but we are still not race-condition-free yet. Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is static typing still optional?
I don't think we're going to reach full agreement here, so I'm going to put my weight behind Eric's rules. I think the benefit of the complicated rules is that they almost always do what you want, so you almost never have to think about it. If it doesn't do what you want, setting hash=False or hash=True is much quicker than trying to understand the rules. But the rules *are* deterministic and reasonable. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] cls for metaclass?
Dear Python developers, PEP 8 says: "Always use self for the first argument to instance methods. Always use cls for the first argument to class methods.” But what about metaclasses? PEP 3115 seems to suggest `cls`, and so do many Python books, however tools such as flake8 don’t seem to like it. Is there a consensus opinion, and should PEP 8 be updated? Kind regards, Pim Schellart ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cls for metaclass?
I think it should be `cls` and flake8 etc. should be fixed. On Mon, Jan 29, 2018 at 11:34 AM, Pim Schellart wrote: > Dear Python developers, > > PEP 8 says: > > "Always use self for the first argument to instance methods. > > Always use cls for the first argument to class methods.” > > But what about metaclasses? > PEP 3115 seems to suggest `cls`, and so do many Python books, however > tools such as flake8 don’t seem to like it. > Is there a consensus opinion, and should PEP 8 be updated? > > Kind regards, > > Pim Schellart > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido% > 40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cls for metaclass?
Coincidentally, I changed this in flake8's pep8-naming plugin about a month ago[1], although the change has not yet made it into a release. [1]: https://github.com/PyCQA/pep8-naming/pull/47 On Mon, Jan 29, 2018 at 11:53 AM, Guido van Rossum wrote: > I think it should be `cls` and flake8 etc. should be fixed. > > On Mon, Jan 29, 2018 at 11:34 AM, Pim Schellart > wrote: > >> Dear Python developers, >> >> PEP 8 says: >> >> "Always use self for the first argument to instance methods. >> >> Always use cls for the first argument to class methods.” >> >> But what about metaclasses? >> PEP 3115 seems to suggest `cls`, and so do many Python books, however >> tools such as flake8 don’t seem to like it. >> Is there a consensus opinion, and should PEP 8 be updated? >> >> Kind regards, >> >> Pim Schellart >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40p >> ython.org >> > > > > -- > --Guido van Rossum (python.org/~guido) > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > jon%40indelible.org > > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is static typing still optional?
Raymond Hettinger wrote: That list of features is mostly easy-to-use except for hash=None which has three possible values, only one of which is self-evident. Maybe the value of the hash option should be an enum with three explicitly-named values. Or maybe there could be a separate "unhashable" boolean flag for the third option. -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Friendly reminder: be kind to one another
Over the last 3 days I have had two situations come up where I was asked for my opinion in regards to possible CoC violations. I just wanted to take this opportunity to remind everyone that open source does not work if we are not open, considerate, and respectful to one another (which also happens to be the PSF CoC that we are all expected to follow when working on Python). When we stop being kind to each other is when open source falls apart because it drives people away, and for a project that is driven by volunteers like Python that will be what ends this project (not to say people should be rude to corporate open source projects, but they can simply choose to switch to a core dump approach of open source). I gave a talk at PyCascades this past week on setting expectations for open source participation: https://youtu.be/HiWfqMbJ3_8?t=7m24s . I had at least one person who was upset about no one getting to their pull request quickly come up to me afterwards and apologize for ever feeling that way after watching my talk, so do please watch it if you have ever felt angry at an open source maintainer or contributor to help keep things in perspective. I also wanted to say that I think core developers should work extra hard to be kind as we help set the tone for this project which can leak into the broader community. People with commit privileges are not beyond rebuke and so people should never feel they are not justified speaking up when they feel a core developer has been rude to them. Anyway, the key point is to remember is that people are what make this project and community work, so please make sure that you do what you can to keep people wanting to participate. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Friendly reminder: be kind to one another
On 1/29/2018 6:16 PM, Brett Cannon wrote: Over the last 3 days I have had two situations come up where I was asked for my opinion in regards to possible CoC violations. I just wanted to take this opportunity to remind everyone that open source does not work if we are not open, considerate, and respectful to one another (which also happens to be the PSF CoC that we are all expected to follow when working on Python). When we stop being kind to each other is when open source falls apart because it drives people away, and for a project that is driven by volunteers like Python that will be what ends this project (not to say people should be rude to corporate open source projects, but they can simply choose to switch to a core dump approach of open source). I gave a talk at PyCascades this past week on setting expectations for open source participation: https://youtu.be/HiWfqMbJ3_8?t=7m24s . I had at least one person who was upset about no one getting to their pull request quickly come up to me afterwards and apologize for ever feeling that way after watching my talk, so do please watch it if you have ever felt angry at an open source maintainer or contributor to help keep things in perspective. I also wanted to say that I think core developers should work extra hard to be kind as we help set the tone for this project which can leak into the broader community. People with commit privileges are not beyond rebuke and so people should never feel they are not justified speaking up when they feel a core developer has been rude to them. Anyway, the key point is to remember is that people are what make this project and community work, so please make sure that you do what you can to keep people wanting to participate. Thanks Brett, I'll have to watch that. But even before I do, let me comment that being kind is not something you will have to regret later. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Making "-j0" the default setting for the test suite?
On 1/28/2018 11:30 PM, Nick Coghlan wrote: On my current system, "make test" runs in around 3 minutes, while "./python -m test" runs in around 16 minutes. And that's with "make test" actually running more tests (since it enables several of the "-u" options). Did you test with current 3.7.0a+, soon to be 3.7.0b1, repository? For me, recent changes, since 3.7.0a4, have greatly reduced the benefit of j0 = j14 on my system. For 3.6.4 (installed), the times are around 13:30 and 2:20, which is about the same ratio as you report. The times for 3.7.0a4 (installed) are about the same parallel and would have been for serial if not for a crash. For 3.7.0a4+ recompiled today (debug), the times are around 24:00 and 11:10. Debug slows down by nearly half. The extra slowdown by a factor of more than 2 for parallel is because parallel tests are now blocked (on windows). Before, a new test was starting in one of the 14 processes whenever the test in a process was finished. All 12 cpu were kept busy until less than 12 tests remain. Now, 14 new tests are started when the previous 14 finish. Therefore, cpus wait while the slowest test in a batch of 14 finishes. Beginning of old log: Run tests in parallel using 14 child processes 0:00:00 [ 1/413] test__opcode passed 0:00:00 [ 2/413] test__locale passed 0:00:00 [ 3/413] test__osx_support passed 0:00:00 [ 4/413] test_abc passed 0:00:01 [ 5/413] test_abstract_numbers passed 0:00:01 [ 6/413] test_aifc passed 0:00:02 [ 7/413] test_array passed 0:00:02 [ 8/413] test_asdl_parser skipped test_asdl_parser skipped -- test irrelevant for an installed Python 0:00:03 [ 9/413] test_argparse passed 0:00:04 [ 10/413] test_ast passed 0:00:04 [ 11/413] test_asyncgen passed 0:00:05 [ 12/413] test_unittest passed 0:00:06 [ 13/413] test_asynchat passed 0:00:06 [ 14/413] test_atexit passed 0:00:06 [ 15/413] test_audioop passed 0:00:06 [ 16/413] test_augassign passed 0:00:07 [ 17/413] test_asyncore passed 0:00:07 [ 18/413] test_baseexception passed 0:00:07 [ 19/413] test_base64 passed 0:00:07 [ 20/413] test_bigaddrspace passed 0:00:07 [ 21/413] test_bigmem passed 0:00:07 [ 22/413] test_binascii passed 0:00:07 [ 23/413] test_binop passed 0:00:07 [ 24/413] test_binhex passed 0:00:08 [ 25/413] test_bool passed 0:00:08 [ 26/413] test_bisect passed 0:00:10 [ 27/413] test_doctest passed 0:00:10 [ 28/413] test_types passed 0:00:10 [ 29/413] test___future__ passed 0:00:10 [ 30/413] test_dict passed 0:00:10 [ 31/413] test_exceptions passed 0:00:10 [ 32/413] test_support passed 0:00:10 [ 33/413] test_builtin passed 0:00:10 [ 34/413] test_opcodes passed 0:00:10 [ 35/413] test_grammar passed 0:00:10 [ 36/413] test_doctest2 passed 0:00:10 [ 37/413] test___all__ passed 0:00:10 [ 38/413] test_cmath passed 0:00:11 [ 39/413] test_cmd passed 0:00:15 [ 40/413] test_cmd_line passed 0:00:15 [ 41/413] test_buffer passed 0:00:15 [ 42/413] test_code passed 0:00:16 [ 43/413] test_code_module passed 0:00:16 [ 44/413] test_codeccallbacks passed 0:00:16 [ 45/413] test_charmapcodec passed 0:00:16 [ 46/413] test_class passed 0:00:16 [ 47/413] test_capi passed 0:00:16 [ 48/413] test_call passed 0:00:16 [ 49/413] test_bytes passed 0:00:16 [ 50/413] test_cgitb passed 0:00:16 [ 51/413] test_calendar passed 0:00:16 [ 52/413] test_c_locale_coercion passed 0:00:16 [ 53/413] test_bz2 passed 0:00:16 [ 54/413] test_cgi passed 0:00:17 [ 55/413] test_codecencodings_cn passed 0:00:17 [ 56/413] test_codecencodings_iso2022 passed 0:00:17 [ 57/413] test_codeop passed 0:00:17 [ 58/413] test_codecencodings_tw passed 0:00:17 [ 59/413] test_codecencodings_hk passed 0:00:17 [ 60/413] test_codecmaps_kr passed 0:00:17 [ 61/413] test_codecmaps_tw passed 0:00:17 [ 62/413] test_codecmaps_cn passed 0:00:17 [ 63/413] test_codecencodings_kr passed 0:00:17 [ 64/413] test_codecmaps_jp passed 0:00:17 [ 65/413] test_codecmaps_hk passed 0:00:17 [ 66/413] test_codecencodings_jp passed 0:00:19 [ 67/413] test_bufio passed 0:00:19 [ 68/413] test_collections passed 0:00:19 [ 69/413] test_contextlib_async passed 0:00:19 [ 70/413] test_copy passed 0:00:19 [ 71/413] test_copyreg passed 0:00:19 [ 72/413] test_coroutines passed 0:00:19 [ 73/413] test_codecs passed 0:00:20 [ 74/413] test_crashers passed 0:00:20 [ 75/413] test_crypt skipped test_crypt skipped -- No module named '_crypt' 0:00:20 [ 76/413] test_cprofile passed 0:00:20 [ 77/413] test_curses skipped (resource denied) test_curses skipped -- Use of the 'curses' resource not enabled 0:00:20 [ 78/413] test_csv passed 0:00:20 [ 79/413] test_dataclasses passed 0:00:21 [ 80/413] test_cmd_line_script passed 0:00:21 [ 81/413] test_dbm passed 0:00:21 [ 82/413] test_dbm_gnu skipped test_dbm_gnu skipped -- No module named '_gdbm' 0:00:21 [ 83/413] test_ctypes passed 0:00:22 [ 84/413] test_dbm_ndbm skipped test_dbm_ndbm skipped -- No module named '_dbm' 0:00:22 [ 85/413] test_decorators passed 0:00:22 [ 86/413] test_datetime passed 0:00:22 [ 87/413] test_defaultdict passed 0:00:23 [ 88/413
