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. On one hand I also used vanilla Python instead of something easier to use like Django but the amount of preventable run-time errors and the lack of IDE autocomplete support at various points was kind of off-putting after coming back from very strictly typed languages like Swift, Kotlin or F#.
It also didn't have the simplicity that Phoenix / Elixir still has, for example when you Google how to solve problems you have Python 2 versus 3, the old way to handle requests which is limited and the new way to handle requests which isn't as documented, yes you have type hints and named arguments but they're not everywhere yet and so on.
So I don't think I will circle back to use Python again unless there's some kind of reason I can't easily go around it. There are still some very good ideas in there (I like the braceless approach to code hierarchy and a standard on code formatting in general) and it's definitely not as dumb as JavaScript but it has accumulated too much cruft.
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.
> (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.
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 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.
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 :)
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.
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.
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
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.
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.
> 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?
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 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.
> 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.
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.
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.
It also didn't have the simplicity that Phoenix / Elixir still has, for example when you Google how to solve problems you have Python 2 versus 3, the old way to handle requests which is limited and the new way to handle requests which isn't as documented, yes you have type hints and named arguments but they're not everywhere yet and so on.
So I don't think I will circle back to use Python again unless there's some kind of reason I can't easily go around it. There are still some very good ideas in there (I like the braceless approach to code hierarchy and a standard on code formatting in general) and it's definitely not as dumb as JavaScript but it has accumulated too much cruft.