71–80 of 118 posts
Earlier quoted context omitted.
Yeah same here. It has the cleanest mapping from REST resources to Python class + method. It just made sense to me: The router block at the top plus: class MyResource: def GET(self,...): ... def POST(self,...): ... def PUT(self,...): ... def DELETE(self,...): ... Looks really nice. Haven't tried serving or rendering templates from it, so never tested that code.
Check out Flask's MethodView
Used Tornado, django and flask quite a bit, web.py only once. As others have mentioned, it didn't work that well, and the community around it is smaller than other frameworks. Again today, Django seems a bit cumbersome, Tornado works well but has a very low bus factor. Pretty sure flask is currently the front runner in "python microframeworks".
Used Tornado, django and flask quite a bit, web.py only once. As others have mentioned, it didn't work that well, and the community around it is smaller than other frameworks. Again today, Django seems a bit cumbersome, Tornado works well but has a very low bus factor. Pretty sure flask is currently the front runner in "python microframeworks".
What's bus factor?
Generally refers to "how many people can continue to develop/support this software if original maintainer (and close co-developers) get hit by a bus."
Earlier quoted context omitted.
I knew HN was written in Arc, but I wasn't aware that it is the Lisp clone referred to by this piece. Was it?
When he said "Whatever happened to that Lisp clone?" I'm pretty sure he was referring to the part of the article that mentions the folks on comp.lang.lisp who were discussing writing a competitor to Reddit in Lisp. The discussion was not about writing a new Lisp or Lisp-like language, but a clone of Reddit. The fact that HN is a site that performs a function very similar to Reddit, and happens to be written in a dial…
Yep, spot-on. It's the same with those guys who wanted to make a Facebook clone focused on privacy or whatever. Lots of talk and then you never hear about the project again.
Used Tornado, django and flask quite a bit, web.py only once. As others have mentioned, it didn't work that well, and the community around it is smaller than other frameworks. Again today, Django seems a bit cumbersome, Tornado works well but has a very low bus factor. Pretty sure flask is currently the front runner in "python microframeworks".
What's bus factor?
The number of developers that can be suddenly and totally lost from a project (e.g., by being hit by a bus) without the project itself becoming unable to proceed effectively.
What Lisp webserver was used, originally? Hunchentoot? What web servers/stack are Lispers using these days?
If you're using Clojure, ring + tomcat, etc...
Earlier quoted context omitted.
I'm not too familiar with Django but with several other frameworks and I definitely feel like this applies to lots of them out there. In my experience though, I've worked on teams with developers who criticize frameworks for those reasons, choose a minimal or no framework at all, and spend a ton of extra, unnecessary time reinventing a worse version of a framework they decided 'sucked' once they realize they need sec…
I almost went down this route on a project once. As soon as I noticed myself writing an identity map, I slapped myself in the face and just downloaded Symfony.
The first Python web framework I used was Django. I'm really glad I came across it first because I was inexperienced at the time and it forced me to adopt a lot of good practices. However, now that I'm more experienced, I can relate a little to what Aaron is saying here. Learning all of this boilerplate stuff is annoying! Recently, I started contributing to a friend's rails app and I found the process of learning how…
Now that I get it though, it seems like an interesting framework but not a productive one. I've only dabbled in Pyramid with my free time and have never built a serious project with it, but I can't imagine building anything large scale with it.
(I'm a .NET developer BTW, MVC is what I work with in my day job)
web.py never really worked well, so we ended up rewriting it again. The interesting thing was that Django still wasn't up to the task when we did that, mostly because it's templating engine was too slow. So we chose Pylons instead. It should be noted that Django has since fixed that issue.
Since you guys rewrote over the weekend, I don't understand why anything cannot work well...
I think you can leverage these criticisms at about 90% of the framework software out there written in just about any language. Most developers like to create complex, complicated software mainly to show off their "cleverness" without thinking through the implications for the people that have to use it. It's as if they think that by cramming in every design pattern they can think of and using many different libraries…
One of the more simple litmus tests I use when evaluating a framework: Does it provide (and require you use) its own versions of data types already provided by the language (or the language's standard libraries)? If so, it's a big red flag. Not necessarily a reason to disqualify, but definitely cause to apply extra scrutiny. The thought process is: If I have to spend precious development time converting all my std::s…
Judging a C++ framework by whether it implements its own string type probably isn't a good idea. C++ is inherently limited, and a string type is often the only way to have certain design guarantees. In a performance-critical context, it's sometimes crucial to control the exact pattern of allocation. And not just how they're allocated in memory, but also how often they're allocated. You can control std::string's pattern of allocation by using a custom allocator, but you can't control how often std::strings are created, for example, because std::string implements an interface which is guaranteed to construct temporary strings. This normally isn't a problem, but in contexts where every millisecond is crucial (like gaming) this can be disastrous, since it's very hard to optimize the performance characteristics of std::string once it becomes pervasively used throughout your codebase.
Another reason to make your own string type is for proper unicode support. Maybe C++11 or C++14 added features to help with that, so maybe this is less valid nowadays. I haven't kept up.