HNHacker News
TopNewBestAskShowJobs

pyninja

142 karma · joined March 13, 2011

submissionscomments
pyninja··on Pythagorean Theorem found on clay tablet 1k years older than Pythagoras (2009)
So many red flags in the abstract alone. It's no surprise that the article itself looks like a middle school project.
pyninja··on Pythagorean Theorem found on clay tablet 1k years older than Pythagoras (2009)
You sound very confused.
pyninja··on [dead]
How do you screw up tapping with two fingers?
pyninja··on Why must you laugh at my back end?
Using `display: table` is a great way to lay out your elements in a grid while keeping your HTML semantic.
pyninja··on Why must you laugh at my back end?
> view source

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

pyninja··on Ask HN: Who is Hiring? (August 2011)
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.
pyninja··on WSGI Is Dead: Long Live WSGI Lite
Are you serious?
pyninja··on WSGI Is Dead: Long Live WSGI Lite
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.
pyninja··on WSGI and the Pluggable Pipe Dream
> 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).

pyninja··on WSGI and the Pluggable Pipe Dream
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.)

pyninja··on Show HN: Pump, a dead simple Pythonic abstraction of HTTP.
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.
pyninja··on Show HN: Pump, a dead simple Pythonic abstraction of HTTP.
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).

pyninja··on Show HN: Pump, a dead simple Pythonic abstraction of HTTP.
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.
pyninja··on Show HN: Pump, a dead simple Pythonic abstraction of HTTP.
Here is an example of a thread where it's discussed: http://mail.python.org/pipermail/web-sig/2009-November/threa...
pyninja··on Show HN: Pump, a dead simple Pythonic abstraction of HTTP.
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).

pyninja··on Show HN: Pump, a dead simple Pythonic abstraction of HTTP.
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).
pyninja··on Show HN: Pump, a dead simple Pythonic abstraction of HTTP.

    # Pump
    def app(request):
        return {
          "status": 200,
          "headers": {"content_type": "text/plain"},
          "body": "Hello World"}
pyninja··on Show HN: Pump, a dead simple Pythonic abstraction of HTTP.
Yes, Pump was heavily inspired by Rack and especially Clojure's Ring (https://github.com/mmcgrana/ring).
pyninja··on Show HN: Pump, a dead simple Pythonic abstraction of HTTP.
I hadn't seen this, looks interesting.
pyninja··on Show HN: Pump, a dead simple Pythonic abstraction of HTTP.
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.
pyninja··on Webdesigners: please make text readable
Surprised he didn't link to Reichenstein's essay on the topic: http://www.informationarchitects.jp/en/100E2R
pyninja··on Clever Names Aren’t Always a Good Thing
Which is why you should keep your bookmarks in the cloud :)
pyninja··on Clever Names Aren’t Always a Good Thing
I solve this problem by bookmarking the website and putting some keywords, like "automated software install", in the description.
pyninja··on How to Read Mathematics
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.

pyninja··on How to Read Mathematics
> 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.

pyninja··on About Linkrot: Proportion of Working Links on Pinboard.in, 1997-2011
Sorry, I didn't think of the second interpretation.
pyninja··on About Linkrot: Proportion of Working Links on Pinboard.in, 1997-2011
What's not clear about it? They die at a steady rate of 25% per 7 years.
pyninja··on Fossil Versus Git
This does not make me interested in Fossil.
pyninja··on Show HN: Instafilm -- it's like Instapaper for videos
Great idea. To me, it's useless without an iPhone/iPad app though, looking forward to that.