I've written tests on personal projects for all of those reasons at one point or another (except the last).
My current workload is mostly a bunch of data-collect scripts (hitting APIs, building a CSV, loading that to cloud storage and databases), plus prototyping small web apps for internal limited span projects. Testing doesn't make much sense for our current tasks, but I also really don't want to be left in the dust.
On the web side, any generators that create unit tests I normally delete...I know it's terrible.
If I had been a working developer as this nonsense ramped up, I would have avoided it too. Nobody really does TDD. It’s a mythical concept.
Some sanity checks are fine, and some integration tests. Unit tests are often a pit of time waste, depending on the unit. I aim for my unit tests to look like integration tests.
That is 100% not true it is far from a "mythical concept" and you should not be misguiding devs.
Where do you think your testing suite is from? You might even be using their code who knows.
All of my hobby code is unit tested. Writing code is easier with unit tests ... why would I make things harder on myself just because I'm doing it on the weekend?
That's some olympic-level conclusion jumping there
From their methodology section:
> The data include responses only from the official Python Software Foundation channels. After filtering out duplicate and non-reliable responses, the data-set includes more than 18,000 responses collected in October and November of 2018 via promoting the survey on python.org, the PSF blog, the PSF’s Twitter and LinkedIn accounts, official Python mailing lists, and Python-related subreddits. No product-, service-, or vendor-related channels were used, in order to prevent the survey from being slanted in favor of any specific tool or technology.
That might have influenced significantly in the selection of the Python users taking the survey: why answer a survey setup and sponsored by a private company you are not really familiar with and that you don't necessarily trust as a result?
There is also a second selection bias: the people who follow the PSF and the official python.org communication channels are probably nerdier than the average Python programmer. This is reflected in the OS statistics. The survey results suggests than 53% of the Python users do not use Windows at all.
On the scikit-learn online documentation, after removing the mobile traffic we have: Windows at 61%, macOS at 23% and Linux at 15%.
On stackoverflow, the primary OS statistics are: Windows at 47%, macOS at 27% and Linux at 23%.
This is the js survey results all over again: no. Unless you can statistically prove the results are biased, you don’t get to ignore the results because you dont like them.
Finding data points with no methodology that contract the survey result does not invalidate the survey results.
Thats. not. how statistics work.
A great deal of effort was put into this survey, and the stats you’re looking at are more likely biased than the ones in this survey.
The stats and the methodology here are clearly documented; if you want to argue with them, be specific and provide concrete statistical proof for your assertions.
Specifically, why do the stats you have prove anything, and what confidence do you have that they are representative?
In this situation often the smaller dataset is wrong.
...not always. But often.
Human intuition based on limited data can seem compelling, but it’s always worth acknowledging you might be the outlier.
18000 respondents is a lot, especially when a specific effort has been made to sample from various sources.
The parent post didn’t even bother to check their own biases.
I don't know if that's the case here, but I do often think that people gravitate towards the first thing that they can understand that seems to, at a glance, check out, without investigating.
Similarly, stackoverflow has a lot more users than just Python users, so it says little about how many Python programmers use Windows.
The ads wouldn't have appeared on the Requests docs but it could have on many others.
What makes that surprising? A past result? A preconceived idea?
The surveys 9th takeaway is the same:
> Surprisingly, almost two-thirds of Python developers choose Linux as their development environment OS.
... Why is it surprising? Did you expect an equal split? Did you expect Windows to dominate?
There's no answer here. I have no idea why the result is surprising: it fits what I would expect.
I took the survey and I marked both OSX and Linux, because I deploy (local/docker remote/vm) to linux and spend quite some time in linux shells. I think it likely that a lot of windows users would do the same.
To be crystal clear, I wouldn't think that the majority of python developers are using linux as their primary development machine. I bet next year the survey will focus in on selecting primary OS as a choice.
Not necessarily. In absolutely every enterprise Java development environment I've seen in Europe, they're using Windows as the developer OS. Easier to manage using AD.
No worries guys, As a happy CE user, I find it's not only a phenomenal contribution to the overall Python experience but also a huge gesture of goodwill from your part.
Today tools start dropping python 3 versions... like latest numpy and django don't support 3.4
The survey characterizes "Scientific development" as "Data analysis + Machine learning", with 28% of the people selecting one of those two latter categories as the answer for "What do you use Python for the most?"
However, only 6% of the users said they were in a company which did science, and only 2% develop for a science industry.
Now, it's certainly true that a scientist can work for a company which neither does science nor targets science research. As an example, an ice cream company may employ food scientists.
It's also possible that people who do, for example, actuarial science might group themselves as working in "insurance" rather than "science".
But it seems wrong to infer that "Scientific development" is equivalent to "Data analysis + Machine learning" without stronger support.
After all, an engineer uses data analysis to evaluate a design, and while engineering is an applied field of science, with a great amount of engineering science to back it up, I don't think many engineers consider themselves as a scientist or as someone doing scientific development.
These are all in the realm of scientific development, vis-a-vis non-trivial impacts both socially and commercially.
I agree that "science" can be a broad term - I gave the example of engineering as a branch of science. But what use is there to describe 28% of the respondents as doing scientific development if only (say) 6 percent of the people would describe themselves as doing scientific development?
Also, is there nothing else to scientific development besides data analysis or machine learning?
AirBnB? Yup. Uber? Definitely. Facebook? Beyond a doubt. Flickr? Twitter? MySpace? How about open source projects like Apache httpd? Kafka? Linux? What about the guidance software used in the Apollo missions? Think about what the MP3 coding format did for digital media.
It's very easy to take these things for granted, boiled frog and all that.
You agree that there is a mismatch between their classification and yours, and believe it should be 100%.
This supports my argument that their definition is not useful. Rather, it could have been "foobar programmers", and been a more useful as it wouldn't have come with a large amount of existing associations with different meanings.
It is possible that people working for lower systems have different editor choices, making them less likely to have answered the survey.
I dunno... Robotics can be very high level, particularly with ROS.
A smarter way might be to ask when was the first month/year that one got paid for python dev work and then calculate the experience number oneself.
Maybe the Windows support? I'm not sure. It's been a couple of years.
I hadn't even thought about Enthought until I saw your comment.
All my co-worker kids code in python. My 8 year coded python stuff on a kano for Minecraft. So it seems reasonable that folks would work on more and more projects unpaid/oss before entering the workforce.
I like that python is both super easy and super professional and can be used for both.
i know at least another 5~6 people with the same career as me (bar the python experience).
Python sacrifices so much in the way of efficiency, safety, and maintainability that it's hard to justify the wins in expressiveness. Easily checked errors that should have never made it to production manifest at runtime even after rigorous testing. Increasing performance requires moving to asyncio which drastically reduces readability and limits the code reuse from non-async libraries. Eventually code bases grow so large mypy becomes a must, and we have to contend with interfacing untyped libraries and refactoring all of our existing code with annotations.
Python has its place, but in line with how scary modern software practices are to me, it's crazy that Python has become such a mainstay in production software.
With a proper test framework, people can and are building large scale applications. There are plenty of ways to optimize performance without a complete rewrite. Python is really Python+C to a large extent.
As for your jibe, my original point was that there is something between Python and Assembly. There are many languages that provide all or many of the nice things that Python gives us that are staggeringly more efficient and safe.
Python is really Python+C if you’re willing to write C extensions, which completely negates the point of using Python. C extensions also don’t maintain safety, or solve Pythons shift of compile time bugs to runtime. It really only addresses the efficiency losses by making you write code in another language.
People can and will build successful applications in all sorts of crazy ways. It’s a fallacy argument that just because something is done a certain way, that must mean there are no better ways that could save us time, money, and sanity.
Prototyping usually involves working with existing code base and the ecosystem, although if you are building a brand new product or application, your context may be different.
Those sites seem mainstays to me, with good load. Perhaps performance is a problem for you for the server load and costs that you want, but it does allow you to iterate quickly to get your product out the door.
Last thing though: Checked errors. I think that's largely solved with type hinting (along the lines of TypeScript) where you get some guarantees.
Stacks of choice though for me is really Python and Go. I would use Go for when I truly need that raw speed with a lot fewer servers in Go in terms of horizontally scaling.