181–190 of 209 posts
Earlier quoted context omitted.
Why? I thought one should prefer immutability. As for typed dicts.. yes, I’m mostly stuck on old python versions, nice reminder.
You can use: > @dataclass(frozen=True) to create an immutable data class.
Earlier quoted context omitted.
> I think that type hint are making python source code messy and unreadable. I hear this sentiment a lot from people who rarely use strict(er) typed languages: Rust, C++, Java, C#, Go, etc. Can you imagine a developer in any of those languages complaining that "oh, now the code is messy and unreadable because we added explicit types"? It seems bizarre to think about it. Sure, Java and C# is a bit repetitive, but at l…
> Can you imagine a developer in any of those languages complaining that "oh, now the code is messy and unreadable because we added explicit types"? Python used to be described as "executable pseudocode". None of the languages you've listed have ever been considered that easy to read. Making Python look more like them is therefore a step backwards in terms of cleanliness and readability.
And that's never been true once you're past toy examples into real-world programs. I agree that type hints are "ugly" to read, but they make the code much easier to understand. You have to be aware of the types anyway, and it's better to have them explicit in the code than in your head.
You can still have duck typing with Protocols if you like that kind of thing. Explicitly saying what you expect the incoming type to be able to do is much better than reading the code and having to track all the attributes and methods so you know what you can use.
Earlier quoted context omitted.
I encourage you to open the `typing` documentation [0] and search for the word `deprecated`. Spoiler alert: the search result will be three-figure. Some of the results are already scheduled for removal. [0]: https://docs.python.org/3/library/typing.html
This is the relevant bit: > The redundant types are deprecated as of Python 3.9. However, while the aliases may be removed at some point, removal of these aliases is not currently planned. As such, no deprecation warnings are currently issued by the interpreter for these aliases. The idea is that new code shouldn't use them, but they work perfectly fine and will keep working in the near future. Even if they decide to…
Your quote also conveniently left out the following paragraph:
> The aliases are guaranteed to remain in the typing module without deprecation warnings until at least Python 3.14.
Python 3.14 is less than a year away.
> Even if they decide to remove these at some point, you're looking at several years before it actually happens, and you'll have plenty of time to migrate.
I agree. I still think it adds to the pile of chores, especially for people who are on the fence anyway as to whether type annotations are worth the additional mental load to them.
Earlier quoted context omitted.
Every single typed system I have ever worked on, no matter how poorly designed, has been easier to alter than the vast majority of ruby, python, perl, php, and elixir that I've worked on
I have the opposite experience: Inserting a library that wraps an existing one to add new features has been a nightmare in every statically typed language I’ve used — including times it’s virtually impossible because you’d need the underlying library to understand the wrapper type in its methods. In Python (with duck typing), that’s a complete non-issue.
It can be slightly laborious to manually wrap a bunch of operations so you can override something, but it's more of an annoyance/inefficiency than something that adds cognitive overhead. That said, many languages (eg structurally typed ones like TS) it should be a non-issue.
Earlier quoted context omitted.
Can’t honestly remember the details! But it’s very much an AWS-owned org.
I was part of a skunkworks project at eBay a decade ago. eBay's OSPO was pretty loose at the time. We made our own eBay org to release our stuff under, with their blessing. They linked to our projects from their site. We've all since left, and eBay's OSPO has churned too. Some years ago, I ended up with a giant undismissible banner on every GitHub page that the org we made has been "flagged." Apparently someone at mo…
The biggest issue with Python type hints for me isn't the hints themselves, it's that they encourage people to write overly complex, verbose code just to satisfy the type checker. Code like this [0] could simply be 3 functions. Instead it's 3 classes, plus a base class `AstNode`, just so the author can appease the type checker by writing `body: List[AstNode]` instead of the dynamically-typed `body = []`. [0] https://…
Note that you only need `body: list[AstNode] = []` if you declare an empty container since the type checker cannot infer the type. If you're using list comprehensions or initialising the list with an element, the type checker will infer the type. You can even have a heterogeneous list with objects from multiple types, and the type checker will infer the type as the union.
In modern typed Python, you usually only annotate function signatures or stuff like dataclasses.
It seems like the author is looking for the ability to specify types as `typeof :arguments` and `typeof :return`. I can see how this could make prototyping easier. It is also helpful for cases (not uncommon in Python) where you're just proxying another function.
Like `ParamSpec`?
Earlier quoted context omitted.
> The other side is those people who do not find those kind of bugs annoying Anecdotally, I find these are the same people who work less effectively and efficiently. At my company, I know people who mainly use Notepad++ for editing code when VSCode (or another IDE) is readily available, who use print over debuggers, who don't get frustrated by runtime errors that could be caught in IDEs, and who opt out of using codi…
Well, using print over debuggers is fairly common in Rust and other languages with strong type systems because most bugs are, due to the extreme lengths the compiler goes to to able to detect them even before running the program, just lacks of information of the value of an expression at a single point in the program flow, which is where dbg! shines. I agree with all the other points though. Anecdotally, I was just w…
Earlier quoted context omitted.
> The other side is those people who do not find those kind of bugs annoying Anecdotally, I find these are the same people who work less effectively and efficiently. At my company, I know people who mainly use Notepad++ for editing code when VSCode (or another IDE) is readily available, who use print over debuggers, who don't get frustrated by runtime errors that could be caught in IDEs, and who opt out of using codi…
>these people don't push code out as fast they could. Well, one of my coworkers pushes code quite fast, and also he is the one who get rejected more often because he keep adding .tmp, .pyc and even .env files to his commits. I guess "git add asterisk" is faster, and thus more efficient, than adding files slowly or taking time to edit gitignore. Not so long ago I read a history here in HN about a guy that first coded…
Is that a double negative in your title ? Or is it an inside joke I didn't get ?