As a proponent of "TODOs should always point to a concrete issue", you have 3 ways to resolve a TODO before merging:
1. Just file the issue. If it's something you should actually do, you can take 20 seconds to write it down and track it.
2. Just do it. If it seems like too small of a thing to file an issue for, fix it before you commit it.
3. Turn it into a comment. If it's not worth fixing and not worth tracking, but you want to remember it, that's a fine thing for a regular code comment.
Lots of comments and arguments about async being big or complex, and it's really not, it's pulling in the runtimes that's big and complex, and I think Rust really failed by forcing libraries to explicitly choose a runtime. As a library developer you're then put in the position of not using async, or fragmenting yourself to just the subset of users or other libraries on your runtime.
> Python doesn’t yet have anything remotely close to ggplot for rapidly making exploratory graphics, for example.
Plug for plotnine (https://plotnine.readthedocs.io/en/stable/). I don't know R but use ggplot indirectly through this library for exploratory data analysis, and comparing the experience to any other python plotting library, I understand why R folks are usually so sad to be using Python.
IMO it's a huge advantage to be able to write torch model code that looks like how you'd write the same program in pure python, and still have them be serializable.
As an outsider this may be your perception, but this is not how python's documentation works.
> These documents are just informal prose.
Not true. They're the language spec. Every guaranteed behavior of python is described clearly and concretely in these documents.
> Are they sound?
Yes.
> Does my implementation match what they say?
Yes.
> Does CPython even match it?
Yes.
> Does anyone know?
Yes! There's a very rigorous and thorough set of unit tests that specifically test an implementation's ability to match precisely the behavior described in these documents. All implementations (that I'm aware of, eg. cpython, pypy, jython, etc) state which versions of the spec they are compatible with, in other words they pass the unit test suite for that version.
Further, the maintainers of python (and by that I mean, regular contributors to the python-dev mailing list, not a cabal of robed individuals in a cave somewhere) are deeply aware of the language of the spec, the way the test suite implements it, and the importance of maintaining this relationship.
In case you read the entire article before looking at the author, this is by mchurch so you should take everything it says with a huge crazy egotistical grain of salt. Personal vendettas and hyperbole abound.
I don't think it's true that all non-execute corporate jobs are meaningless, and I've worked at at least one company that mchurch has. Some jobs at some (many?) companies are actually slowly and methodically creating value for humanity at large, and many bosses I've had are not soulless whip-bearers but in fact also determined to make their lives mean something through their work.
That being said I think it does levy some specific good criticisms against PG and silicon valley. It's definitely true that PG has a conflict of interest in his postings, and that the narratives about society that he pushes also happen to be ones that he benefits financially from. It's very fair to compare his views to Ayn Rand's. And it's certainly true that tech and science reporting aren't held to nearly the same ethical standards that other types of reporting are.
Some good points and food for thought, but don't lose too much sleep over another mchurch rant.
Please note that this API does not make any specific attempts to obey the mediawiki etiquette (http://www.mediawiki.org/wiki/API:Etiquette). This sort of API is easy and clean for something like a command line script, but if you're going to do further automation or crawling I strongly recommend using the pywikipediabot library (http://www.mediawiki.org/wiki/Manual:Pywikipediabot) which includes a very full API, has tunable throttling, and makes a more direct attempt to require a user agent string that is in line with the api etiquette.
If you just want a bash script to look things up on wikipedia, you can always use something like
1. Just file the issue. If it's something you should actually do, you can take 20 seconds to write it down and track it. 2. Just do it. If it seems like too small of a thing to file an issue for, fix it before you commit it. 3. Turn it into a comment. If it's not worth fixing and not worth tracking, but you want to remember it, that's a fine thing for a regular code comment.
Eat your broccoli. Track your todos.