pyninja

So many red flags in the abstract alone. It's no surprise that the article itself looks like a middle school project.

You sound very confused.

How do you screw up tapping with two fingers?

Using `display: table` is a great way to lay out your elements in a grid while keeping your HTML semantic.

> view source

Are you trying to tell me that PG is not a web designer?!

Any chance of doing an internship? I'm doing my master's in maths in Berlin and have experience with development in Python and Clojure.

Are you serious?

No, that's not what he's saying... and I don't know if you realize this, but the author, P.J. Eby, is the same guy who wrote the original WSGI spec.

> Maybe my "simple" is to have the ability to yield chunks of data as it gets generated using chunked transfer.

I'm curious, have you ever actually had to do this? Even Rails only just got this feature in 3.1 (http://weblog.rubyonrails.org/2011/4/18/why-http-streaming).

I agree with you, but Pump is not a web framework. You are not supposed to write your application with Pump. Picasso is a framework I built on top of Pump (https://github.com/adeel/picasso) that's more suitable for that.

(I can see how you could get a mistaken impression from reading the discussion on HN, though.)

I'd like to do that, but I'm afraid of how much time and effort it would take. I really just wrote Pump/Picasso to use at our new startup, Beagle (http://beagleapp.com). I was expecting roughly this kind of response from the Python community, but who knows, maybe someone will use it.

Werkzeug and WebOb are not what I'm trying to do.

I'm reposting a reply I made earlier to irahul:

Pump aims to replace WSGI entirely. That is, I believe it does a better job of what WSGI was intended to do.

I understand your point that web developers don't necessarily work with WSGI on a day-to-day basis. But if you look at the Ruby web community, Rack middlewares are much more prevalent than WSGI middlewares. Application developers (as opposed to framework developers) often add functionality as a Rack middleware, so that it can be reused in different applications, even using different frameworks. Why isn't that happening with Python as much? In the Python world, instead of writing even simple middlewares to for basic functionality like https://github.com/adeel/pump/blob/master/pump/middleware/pa... or https://github.com/adeel/pump/blob/master/pump/middleware/co..., every framework ends up reimplementing it. I believe this is because the WSGI API is ugly and not as easy to understand as it could be (just look at the average WSGI middleware).

Thanks for the feedback. I'm not willing to accept that WSGI couldn't be this simple. Pump's specification is modeled on Ring for Clojure (https://github.com/mmcgrana/ring), and I'm sure there's a way Ring gets around the issues you mention. I'd never had to do any of those things before but I'll look into it now.

Here is an example of a thread where it's discussed: http://mail.python.org/pipermail/web-sig/2009-November/threa...

Pump aims to replace WSGI entirely. That is, I believe it does a better job of what WSGI was intended to do.

I understand your point that web developers don't necessarily work with WSGI on a day-to-day basis. But if you look at the Ruby web community, Rack middlewares are much more prevalent than WSGI middlewares. Application developers (as opposed to framework developers) often add functionality as a Rack middleware, so that it can be reused in different applications, even using different frameworks. Why isn't that happening with Python as much? In the Python world, instead of writing even simple middlewares to for basic functionality like https://github.com/adeel/pump/blob/master/pump/middleware/pa... or https://github.com/adeel/pump/blob/master/pump/middleware/co..., every framework ends up reimplementing it. I believe this is because the WSGI API is ugly and not as easy to understand as it could be (just look at the average WSGI middleware).

The problems with start_response have been discussed at length in Web-SIG. As far as I know, they're planning to remove it from the spec in WSGI 2.0 (whenever that's published).

    # Pump
    def app(request):
        return {
          "status": 200,
          "headers": {"content_type": "text/plain"},
          "body": "Hello World"}

Yes, Pump was heavily inspired by Rack and especially Clojure's Ring (https://github.com/mmcgrana/ring).

I hadn't seen this, looks interesting.

Building web apps! Basically, it's meant to be a replacement for WSGI. In my view, the problems with WSGI are that it has an unpythonic API (see: start_response and environ), and that it doesn't come with standard middleware that all frameworks use, so they all end up reinventing the wheel. Pump does a better job of abstracting out the details of HTTP, and also comes with a lot of useful middleware. This makes it really simple to write a web framework: just implement the routing and glue together a bunch of middlewares. For an example, see Picasso (https://github.com/adeel/picasso), a simple but functional framework I built on top of Pump.

Surprised he didn't link to Reichenstein's essay on the topic: http://www.informationarchitects.jp/en/100E2R

Which is why you should keep your bookmarks in the cloud :)

I solve this problem by bookmarking the website and putting some keywords, like "automated software install", in the description.

I looked at the first few pages and saw only a few math papers, and in those the exercises were uninteresting details (e.g. just computation, or the second of two analogous cases where only the first is proved in the paper).

Do you really think anyone would benefit from such proofs in a paper? I would be interested if you could give an actual example of a paper where a reader might be inconvenienced by something being left as an exercise.

> I mean... isn't the point of academic writing to communicate research and results already performed?

Obviously mathematicians don't leave "exercises for the reader" in research papers, but it is common in textbooks or expository writing.

> I always felt that phrase has no place in the internet age, where the concept of a "page limit" is laughable and a simple hyperlink can point me to chapters upon chapters of appendices.

The constraint is not page length, of course, but time. It is a much better use of a mathematician's time to leave easily reproducible proofs to the reader, and focus on the interesting ideas.

Anyway, doing these kinds of exercises is actually very useful in understanding new ideas.

Sorry, I didn't think of the second interpretation.

What's not clear about it? They die at a steady rate of 25% per 7 years.

This does not make me interested in Fossil.

Great idea. To me, it's useless without an iPhone/iPad app though, looking forward to that.