I believe in this context they’re referring to an Individual Contributor. Pulling the definition from indeed.com:
> a professional without management duties and responsibilities who contributes to a company independently to support its mission and goals. While they typically report to someone within the company, individual contributors aren't responsible for managing anyone except for themselves.
What's the benefit of this over simply adding the type annotations directly? I guess this is mostly for those unwilling to understand types?
Especially given the admitted limitations of inferring types, such as the add exmaple discussed; this seems to be fixing an anti-pattern problem. As this those who would build a project in Python that would largely benefit from these annotations, would be most suited to just spend the couple of hours needed to truly apply it themselves.
One of the core requirements of the type hints design is that they don't affect the Python language.
You can still write python programs without them.
You can add them only partially.
You can also add them later.
Python stays Python.
MonkeyType lets you take a code base that is untyped, or partially typed, for historical or because it was not worth it at the time, and turn it into a fully typed project quickly.
It makes the transition between the exploration phase into the industrial phase much easier.
For me, it's kinda fantastic to be able to fiddle with a design, changing my mind again and again, without having to fight the type system, then once things are settled, add an additional safety net on top.
It's also very reassuring knowing I can just hack things, knowing that later on, if I want to take it to the next level, I have the option to change my mind about type hints.
Totally get that, and agree that this is an aspect if Python that is awesome for iteration on new ideas without many barriers.
However, this seems to make the assumptions that when you, as you say, transition to the industrial phase:
- MonkeyType will get all of the assumped types correct, which at any scale I doubt. Not because of the ability of the projects contributors, but because they warn about this in their own documentation
- If you're doing this at an industrial scale, and you haven't already documented/thought about/understood what these functions are. I'd appreciate that it may help intially, but still runs in to the problem I was discussing above.
Have you actually spent time adding type annotations to existing python code? In my experience it's a huge pain compared to other languages. Documentation is sloppy about types because people aren't used to worrying about them, so even looking at the code it's really hard to even determine the actual types of things without just running it and poking around.
Not sure why the initial tone of your response is quite so dismissive. But I do work with Python on a daily basis, even though this shouldn't be the deciding factor on the validity of any point. Discuss the point, not the individual, if it's so easy to disprove.
It seems that you're talking about poorly documented code, not how type checks effect this. Python code should have at least docstrings for types, or a scrawl with pen and paper describing this. If not, this is a failing of the project, and it's codebase. Not something you should rely on an outside tool to fix.
> In other words, we allow people to post it as a form of expression, but we’re not going to show it at the top of News Feed.
So back to the mantra of, "trust us, we'll show you what you need to know"?
I thought that was exactly the attitude that got them in to this mess in the first place?!?
I assume if each page has the markup tag
> <strong class="fn" itemprop="author">nickmchardy.com</strong>
You can then either attempt an email to info@{} the tld of the author tag or scrape that site for email addressees on there.
Assuming that most of these are blogs, such as the case here, hopefully there wouldn't be too many addresses on each domain. So hopwfully relatively easy to do ... ?
> I only skimmed the article, but it appears to be about the prevalence of tracking in third-party services used by app developers, not in the core distribution, what did I miss?
I think it's at least partly covered on page 2 under Uncovering Parent Companies :
> We obtain the parent organizations of these services (after accounting for business mergers and acquisitions) and identify the dominant organizations in the mobile ATS ecosystem. We find that Alphabet-owned ATSes have presence in over 73% of apps in our dataset. This raises questions about Alphabet’s monopoly in the mobile ATS ecosystem.
So alongside their conclusion that information is shared freely between subsidiaries:
> Our privacy policy analysis of the largest organizations revelaed the prevalence of intra- and inter- organization sharing of user data.
It would suggest that other large "players", along side Alphabet, could have much larger collections of user data than cureently understood.
That would be my guess though.
