Data classes are awesome! No more boilerplate __init__(self) methods needed.

Another notable part of this release is type annotations:

https://www.python.org/dev/peps/pep-0560/

I love python typing, and have been using it extensively in 3.6. Great to see it in the CPython core!

I've been looking forward to trying data classes, should be nice to avoid unnecessary code.

> The typing module is one of the heaviest and slowest modules in the standard library even with all the optimizations made.

Have you noticed any decreases in performance using core typing?

For those wondering, like I was, where that quote comes from, it's from PEP 560 "Core support for typing module and generic types" - https://www.python.org/dev/peps/pep-0560/

Not a python coder, but from my understanding they are essentially auto-constructors?

Technically, no, but that is how they are written. __init__ was always called after the instance was already created. I think it was originally useful for managing inheritance and baseclass initialization, which can be handled other less hard-coded ways now. I could be wrong.

> Dictionaries preserve insertion order. (Implemented in 3.6, but now is part of the official spec.)

That is a terrible decision. Call me a heretic.

Yes, I know it's a side effect of bringing in the bitmap index version from PyPy. Yes, I am aware that collections.OrderedDict is now an alias to internal dictionary type. And yes, I do understand that randomising the key traversal order could incur a performance penalty.

But a dictionary where keys come out in anything other than unspecified order is a subtle trap just waiting to blow up. I personally prefer golang's map behaviour - keys are always in unspecified order, and the order is different even between calls.

Personally I feel it is perfectly in line with one of Python’s core mentality, “We’re all grown-ups here.” The bahaviour is like Python lacking real access control: If you don’t think about it, it does not matter[#]; if you need it, it’s incredibly useful. You may not like it, and that’s fine, we agree to disagree.

[#]: Well, usually it doesn’t matter, and when it does, you have other ways to achieve similar results.

Can anyone explain why you'd want to use dataclasses over attrs in real code? Attrs does everything they do and more.

"Data Classes are intentionally less powerful than attrs. There is a long list of features that were sacrificed for the sake of simplicity and while the most obvious ones are validators, converters, and __slots__, it permeates throughout all APIs."

See: http://www.attrs.org/en/stable/why.html#data-classes

Because they’re in the standard library, and convenient. I would never use a third-party package just for some syntactic sugar.

I don't understand the inconvenience. Isn't it just adding `attrs` to requirements.txt once for the whole project, and then you get more features ever after?

Simple != easy. It is easy to add another dependency, but you've just added another piece to the puzzle that needs to be maintained.

That assumes you have a project. Some people write scripts in Python to use in the shell.

venvs work fine in the shell. See pipsi for automatic creation/management of the necessary venvs.

Some people write simple programs which they then (say) email to others, or put on a blog post, or on a gist, or a SO answer.

If the simple program depends only on core Python, then they don't also have to say "oh, and also install ...".

It's one more thing that can break in production.

Data classes look cool. Maybe replacing named tuples in my future code? They always felt awkward to work with.

Will data classes save a ton of memory since you’re specifying the types?

Data classes are just regular classes with some methods generated for you. For now you still have to specify __slots__ manually to save memory.

So what’s the point of specifying the types?

Over the last few years Python has gained a type annotation system. The primary goals are to improve testing, improve documentation (the type information is more likely to stay synchronized than docstring annotations), and improve user-feedback in environments like an IDE or Jupyter notebook.

These are called "type hints" because they are not enforced by the Python runtime.

Is the breakpoint builtin analogous to binding.pry in Ruby? If so...that is amazing!

Yes, it's quite similar. It's not THAT amazing though since it's just a convenience function over pdb.set_trace() which has been in the Python standard library for a very long time (2 decades or more).

Out of curiosity, I looked it up. According to a 'git annotate' of pdb.py, "def set_trace():" was added by Guido van Rossum on 1994-08-01 at 11:34:53 - almost 24 years ago.

Yeah, the main advantage seems to be that you can configure the debugger to use externally (I often "pip install ipdb" just to use IPython's shell instead of the default).

I have been looking to translate Moo/Mouse type stuff in Perl to a Python equivalent. I think Data Classes will definitely bring me closer to this.

Wow, I'm tempted to make the switch tomorrow but I literally just wrote tons of boilerplate today....