Daniel Lindsley

One of the problems you get is that once something is stable, the maintainers generally don't have a huge incentive to dedicate already-over-committed time to work on features they don't personally need. Just triaging tickets on a popular project can be a major time commitment, particularly since a fair percentage of them will be helping people understand the API or trouble-shoot something in their project which is causing failures in your code.

In the case of tastypie, I think all of the maintainers have switched jobs at least once in the last few years and at the same time the general Django community has been moving in the direction of simplicity rather than complex generic frameworks. Daniel's list of things he's not interested in implementing in restless is a good list of things which have been painful in tastypie: https://github.com/toastdriven/restless#anti-features

I've only been a minor contributor but I've increasingly found myself favoring really simple views – roughly https://docs.djangoproject.com/en/1.7/topics/class-based-views/mixins/#jsonresponsemixin-example – since I work almost entirely on read-only public data.

If you or someone you know would like to work on tastypie, we're looking for new maintainers:

http://toastdriven.com/blog/2014/may/23/state-tastypie/

If you have an urgent patch, let me know & I'll see about merging it.

That is a great resource. Especially pulling Selenium into the picture and showing good functional testing. Thanks to the author for putting this together.

While I understand the need to show how unit tests work do we really need to test Django's ability to save records to the database and retrieve them in part 1? I personally don't follow true TDD, especially with model fields. Am I off in left field? Is this pattern common with other developers? Or perhaps people test for a fields existence by checking _meta.fields?

The example of testing a specific attribute, verbose_name, (that is expected to be altered by the user) in part 2 and the user implemented __unicode__ method test I do think is a great example, though.

I like Daniel's summary in the "What To Test?" section at http://toastdriven.com/blog/2011/apr/10/guide-to-testing-in-django/

I know that web.py was around years before Sinatra. But URL routing in Bottle is more similar to Sinatra than it is to the URL dispatching via a tuple at the top of a file. Even so, perhaps Bottle is influenced more by web.py. That doesn't mean there aren't a ton of ports of Sinatra (like Express for node.js, Scalatra) or those influence by Sinatra like itty (http://toastdriven.com/blog/2009/mar/07/itty-sinatra-inspired-micro-framework/) or even perhaps Flask.

I even noticed a comment above that said Bottle looks just like Itty. Yet because I brought up the Ruby framework that Itty is essentially a port of, I'm getting down-voted like crazy. I will never understand why Python people dislike Ruby so much, and vice versa.

It's sorely needed. Unit testing for django is not very well documented. The best guide I've found out there is probably by Daniel Lindsley @ toastdriven.[0] However, even that guide suggests using fixture data which break badly as a project grows (I've experienced this first hand), so I'd much prefer a factories based testing chapter.[1]

[0]: http://toastdriven.com/blog/2011/apr/10/guide-to-testing-in-django/
[1]: https://pycon-2012-notes.readthedocs.org/en/latest/testing_and_django.html#fixtures,
http://pyvideo.org/video/699/testing-and-django

it probably predates the multiprocessing package (introduced in 2.6, october 2008, although available 3rd party before that) and certainly doesn't mention it.

multiprocessing does use multiple cores, but is a heavyweight solution (separate, communicating processes, wrapped in a thread-like api). if you need multiple threads for cpu-related performance, it can be very useful.

python 2.6+, including 3.

http://toastdriven.com/blog/2008/nov/11/brief-introduction-multiprocessing/

http://docs.python.org/2/library/multiprocessing.html

Back when we were evaluating API frameworks earlier in the year, this is where TastyPie was: http://toastdriven.com/blog/2013/feb/05/committers-needed-tastypie-haystack/

It's still not clear how the project will do without its original maintainer going forward. I don't bring this up as damning evidence against TastyPie, but it is something to consider. Some projects achieve that critical mass where life continues after the original maintainer steps out, but enough time hasn't elapsed to see how it will play out in this case.