Hacker News Reader

dataclasses are the best recent addition to Python, IMO, maybe tied with ordered dicts.

Python definitely doesn't have conceptual simplicity, because there are many competing concepts in the language, and lack of focus on uniformity. (Example - enums are implemented with a metaclass and dataclasses with a class decorator - arguably the latter is the wrong choice, because it is already evident it limits what kind of features can be added to dataclasses).

Another example just because it makes me irate - `typing.NamedTuple` has been added as an "alternative" to `collections.namedtuple`. Same name, new capitalization, slightly different features. Add to that, a collection type that's inside the module `typing` which is supposed to be for.. type annotations, not actual implementations.

Author of dataclasses here.

> (Example - enums are implemented with a metaclass and dataclasses with a class decorator - arguably the latter is the wrong choice, because it is already evident it limits what kind of features can be added to dataclasses).

I'm curious about what features can't be added to dataclasses because it's not using a metaclass.

If anything, I think that not using a metaclasses is a good thing: it allows you to use @dataclass with classes that do require a metaclass. That metaclass would likely be incompatible with the metaclass that such a hypothetical @dataclass implementation would use.

Thanks for not using metaclasses for dataclasses. I’m looking forward to all libraries replacing metaclasses. For instance, in Django, I think all their metaclasses can be replaced by __init__subclass__. The main issue I have with them is how difficult it can be to compose a new abstract class using upstream classes with them.

I love dataclasses, incredibly simple to use but so useful. My only gripe is no first-class support for "__slots__".

I have a decorator to add support for slots: https://github.com/ericvsmith/dataclasses/blob/master/datacl... (although I'll admit I haven't tested it in a while).

The reason it's not an option by default is because it would be the one case where the decorator would have to return a new class, and I didn't want to do that on the first version. As it is, @dataclass just modifies an existing class. I might bite the bullet add a slots option, and we've had discussions on adding a language feature to automatically add slots to a class, based on annotations and maybe some other magic. If we did that, we wouldn't need to return a new class. But it's not a front-burner task for me.

I believe this is the example where dataclasses could have supported __slots__ better with a metaclass?

Thanks for working on dataclasses :) - as I said, it's my #1 new feature in Python.

Maybe that would have worked better with a metaclass.

But still, I think not using a metaclass is the more flexible design. Maybe I'll add the "add_slots" behavior into the @dataclass decorator in 3.10, even though it would need to return a new class. At least it could be well documented, and I doubt it's a concern for most people.

> Thanks for working on dataclasses :) - as I said, it's my #1 new feature in Python.

I'm offended! I also wrote f-strings, but maybe that's not considered new anymore. In any event, you're welcome!

Maybe the __slots__ discussion is not really that important - it's just convenience, and the regular old method of adding slots still works. So it's a minor thing.

I have diligently converted to f-strings but it doesn't give me new expressibility like I feel dataclasses do, just convenience :)

fstrings and datclasses changed my life. thank you :)

I really appreciate it! Only issue I see is that it won't support inherited dataclasses where the base class already defines __slots__, but I should be able to hack together support.

FYI if you haven't heard of it, attrs (https://www.attrs.org/en/stable/) is a package very similar to dataclasses that does support aromatically adding __slots__. I believe dataclasses was bases on it.

*based. Also @ericvsmith please correct me if I'm wrong - don't remember where I read that.

Yes, attrs is the spiritual parent of dataclasses, including the decision to not use metaclasses. Thanks for mentioning this: I try to always give credit to Hynek and attrs.

No, (optional) static typing is the best recent addition to Python. It allows IDEs to catch a large variety of errors. The static type system is part of the language and has multiple implementations. It's Hindley-Milner, making it two-way, like Haskell's type system.

There is no "No", you can just add your opinion about your favourite feature instead.

Wait what? Are you saying Python has a Hindley-Milner type system?

What's it called? Google didn't turn up anything.

Python doesn't have it but I think they are talking about mypy, options typechecker tool that has type inference.

It's called PEP-484, and it's part of the language https://www.python.org/dev/peps/pep-0484/

Pyre and PyCharm are third-party implementations of PEP-484.

Pycharm autocomplete is very good - I don’t know if that is what you mean by autocomplete support

Requests is one of the modules that had more change on 2-3, but being basically the most popular language (for good reason), it’s pretty easy to find documentation for either version. I imagine a lot more than for Phoenix/elixir whatever that is.

I think you’re being difficult for the sake of being difficult. I am not a leet programmer and that is why I use python- it does everything for you very well and no more. If you want more “cruft” pip install cruft

You might be surprised to see the quality of the docs in the Elixir world: https://hexdocs.pm/phoenix/Phoenix.html

That looks … like many Python projects? It's slightly prettier than the default Sphinx theme but I'm not seeing anything which wasn't common a decade or two back.

IMO part of the quality here is these docs are generated from comments in the code. All you have to do is document your functions and modules properly, run a command, and you have an entire set of docs.

It reminds me a lot of JavaDocs, although I never used them extensively. I'm also not very aware of how documentation looks in the Python world.

Another interesting thing is the code examples. You write them in the comments as "Doc tests", and they are run and tested like normal tests. This means that all the code snippets are up to date with the latest version of the project (as long as you do test!).

The best part, also imo of course, is that it all works out of the box.

That’s how it works in Python, too. You add text descriptions (docstrings), automatic documentation generated from function/class definitions (comments can add prose), and you can run doctests to test things like examples.

See e.g. https://www.sphinx-doc.org/en/master/index.html and https://docs.python.org/3/library/doctest.html

Very nice, I'm glad to see it elsewhere. Maybe Elixir even took inspiration (or it's just a plain good idea). I'm really surprised that I had never heard of or encountered it, maybe it's just an accepted part of the ecosystem so no one talks about it and/or I assumed everything was written manually. Also haven't used Python professionally which doesn't help.

Yeah, I don't care who came up with it first as much as it spreading widely. We waste far too much time on bad documentation as a field.

> I think you’re being difficult for the sake of being difficult.

Why? I was just trying to get something done that I've done in a variety of different languages already so there's a perfect comparison.

> I imagine a lot more than for Phoenix/elixir whatever that is.

I don't know how you manage to come to Hacker News often enough to find exactly my post to answer to but at the same time managed to have never heard about Phoenix/Elixir. What's the point of coming here if you're not interested in staying current in your field?

I moved/was pushed over to Python around a year ago, after writing C# for 15 years.

My Python setup is as follows:

* vscode

* pylance

* black formatter

* flake8

* python typing annotations used as much as possible

This seems to work very well with regards to autocomplete and preventing run-time errors.

One thing I do miss is proper refactoring support.

> One thing I do miss is proper refactoring support.

You should try PyCharm then. That, and their debugger is orders of magnitudes better than VSCode.

Seconded. I had an IDE I was used to and loved and the first time I pair-programmed with someone using PyCharm I threw it out and switched. Doesn't mean it will be the same for you, but it's miles ahead of everything else I have used in 15 years for Python. FWIW, I like VSCode just fine for everything else, PyCharm is just so handy.

I did try PyCharm a few times, but it seemed too complicated - and this was after using Visual Studio for 15 years!

The debugging support in VS Code is fairly good, so it's just the refactoring I'm missing.

I'll give PyCharm another go when I get some spare time.

I don't understand why someone would use Python instead of say using Ruby. I think right now it is a matter of "synergy" given that Pandas, Torch and all those libraries are more tailored for Python, but as a scripting language Ruby is just so much easier, elegant and intuitive [ len(something) vs something.length ]

FWIW, I found Python far more intuitive than Ruby. For the most part, Python works like I expect it to, meaning I can write large swaths of functional code without having to look at documentation, something I was never able to do in Ruby.

> [ len(something) vs something.length ]

The first reads like english, the second doesn't.

> as dumb as JavaScript

Could you elaborate on this?

Much better base packages. Date handling. Type hints. Not an OO fan but it does have real classes. IMHO handles complex applications better.

Though Python can look a bit more clunky than modern JS.

What IDE do you use, that doesn’t have full autocomplete support?

> The past month I have used Python again after a few years and I have to say I didn't quite like the experience as much as before.

Python is really a Perl replacement. It was meant for the scripting world, not software development - pretty much stuff that was too complex or cumbersome to do in bash.

Your blaming Python because you used a poor IDE and failed to use type annotations?

I'm using PyCharm, if you have anything better than that don't hesitate. But the type annotations are obviously something that also needs to be added to all other code I touch, not just my own.

eclipse + pydev + mypy/pylint integration

I’ve used PyCharm from time to time and I find it great but I kind of feel like you need a different approach. Coming from Java it made sense but Python is a different mindset once you get into it. I think you’re far better off treating Python as a highly structured scripting language and using an advanced text editor. I’ve come to believe that these very powerful IDEs are a kind of a window dressing that makes the more serious languages easier to work with. With more flexible languages the language itself is the tooling but it’s not so easy to audit at the end of the day.

Although arguably a more 'difficult' language I sleep much better at night when using Rust, because Python is always in a hurry to get a wrong program running. So then, one has to test like hell. So I feel I'm still ahead of the game.

It’s horses for courses. I’d never use Python for the kind of thing that rust is for. At the same time, I’ve never had occasion to use rust for the stuff I do.

EDIT - just want to add: I'm not au fait with the specifics of Rust but I presume from what I've heard about it that it also supports my position, as an advanced language, that the features you need are in the language so a heavy-weight IDE isn't so necessary.