I view them as similar to python's "private" functions, which are really just functions starting with an underscore. The interpreter will let anyone call them like any other function, but the general rule is don't do it, unless you know what you're doing and are willing to deal with the internals changing.
Python typing is like that. If I say a function takes a List[int], but you know I'm just calling a for loop, you can ignore it and hand me a Set[int]. Maybe it breaks some day, but you're allowed to take that risk, if you have a need.
Do either of these things do anything comments couldn't? Not really. But they're ways of indicating intended semantics without formally documenting your stuff, and when most of what you use the language for is scripts, that's actually pretty helpful. People actually use type hints in a way they didn't with comments, and that's caused a major improvement in code readability. Or at least that's been my experience
You can absolutely look at all this and say python's a crazy, terrible language you never want to touch, but if you've got no choice on language for whatever reason, or you're throwing something together and don't feel like writing `private static final synchronized` forty time, type hints are great.
> I view them as similar to python's "private" functions, which are really just functions starting with an underscore
Good analogy! I wish they were more like "private" class methods, which are prefixed by a double underscore and result in name-mangling: you can still access them from outside if you want, but the code will really look ugly. And you absolutely cannot access them accidentally.
Which is what type checking should be all about, right? Preventing accidental misuse?
> Python typing is like that. If I say a function takes a List[int], but you know I'm just calling a for loop, you can ignore it and hand me a Set[int]. Maybe it breaks some day, but you're allowed to take that risk, if you have a need.
That's what drives me crazy. I come from the statically typed world. This bit of Python's philosophy really clashes with my world view. "These types are just something someone wrote, they may or may not accurately describe the code" seems so wasteful and unhelpful to me...
> That's what drives me crazy. I come from the statically typed world. This bit of Python's philosophy really clashes with my world view.
That’s the kind of the culture shock you get learning dynamic type languages with a static type pov. Type hinting is not really the problem here, but can seem that way because it makes dynamically typed code too superficially similar that it enters the uncanny valley if you treat it like statically typed.
One way that might make this easier is to forget about type hinting entirely at first and learn the language “from scratch”, and add the types back after you get used to write dynamically typed code. Dynamically typed code have its advantage and isn’t bad without type hints (well, at least you have to convince yourself on this, or you’ll never be able to learn a dynamic type language), and the type hints just add back some of the nice things static type provides without compromising dynamic type benefits.
Agreed, but it also clashes with the world view that brought us Typescript, which I also find better than Python's type hinting.
In addition, it makes it harder for me to argue in favor of type annotations with my coworkers. My coworkers come from neither world, static or dynamic; they are learning the ropes. And they just can't see the point. I'm confident I would convince them were this a statically typed language, but with Python I'm lost.
The TypeScript comparison is on an entirely different axis though, the compiled <-> interpreted one. One of the reasons languages go with the type hinting route is actually to avoid a separate compilation step like TypeScript. That may be totally fine for you (again coming from a statically typed language where this is more or less required), but it’s a hill many are willing to die on. It’s all tradeoffs and design decisions.
Agreed it's a different axis, that's why I said "also clashes". I of course think Typescript's choice in this tradeoff was the better one, even though I'm not particularly in love with Typescript either.
At some point everything in proglang is preferences and design decisions, but for me, there are better and worse tradeoffs to make.
The typing (>= python 3.6?) and collections (>= python 3.8?) packages have definitions for a bunch of protocols (basically interfaces for structural typing).
So for that List[int] example, you probably want to take a(n) Iterable[int], Iterator[int], or Collection[int] instead, depending on exactly how you use it.
> don't feel like writing `private static final synchronized` forty time, type hints are great.
We should think about whether there's a reason why we want to be writing `private static final synchronized` over and over again, after looking at the state of the software engineer these days.
>Did pointedly ignoring common usage add anything here?
Yes, there are plenty of words going though the natural process of dilution. Providing some backpressure is, I think, useful to the language to preserve the richness of meaning. I'm responding directly to a discussion about the meaning of a word not interjecting into another conversation with a "well, actually..."
When you're writing a dictionary, words mean what people use them to mean. I'm not writing a dictionary.
Except that your 'well actually' still exists because you ignored the much more common usage when you made your point and didn't mention anything about your valiant effort to preserve etymological treasures until questioned?
Another way to translate it would be “the cost of British labour was reduced, pushing down the artificially high unemployment rate,” but the best way would probably be both of the above at the same time, and some other more complicated stuff I don’t know or understand. My point isn’t this was actually a really good thing, but it’s not as straightforward as you’re making it out to be.
I’m not sure if this is a legitimate question or an attempt to make some sort of “but also not-the-West is bad!” point; if the latter, this is a comment on an article about caste discrimination in California, which is probably why the its observation focuses on the West, instead of talking about parallels in other cultures.
Does anybody have advice for dealing with oncall (for all the software people out there)? My issues are light as they go, and I’m pretty productive for things with timeframes longer than a week, but managing a ticket queue is just brutal, and basically impossible once I end up with pager-induced sleep deprivation. Long-term I think I just need a job that doesn’t involve a lot of ticket management, but switching isn’t an option at the moment, and I need to find something to reduce the amount of slack other people have to pick up.
Oncall shifts shouldn't be so burdensome, even for neurotypical people. That sounds like a real systemic problem. What is happening that regularly requires all the emergency tickets?
I agree with sibling comment, the environment sounds bad. If you need to chat with someone about it let me know, I'm happy to talk through things.
Unrelated, I actually love oncall work. If I get woken for something pointlessly, I fix it immediately. I'm a night person by nature, so staying up until 3am fixing a but and the sleeping during the day feels great. It's a constant stream of shiny things to chase and fix.
From a section on Persian customs, somewhere in 130-135 of book one (which is as precise as my copy gets): “If an important decision is to be made, they discuss the question when they are drunk, and the following day the master of the house where the discussion was held submits their decision for reconsideration when they are sober. If they still approve it, it is adopted; if not, it is abandoned. Conversely, any decision they make when they are sober, is reconsidered afterwards when they are drunk.”
