Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python for Humans

speakerdeck.com

Post reply on HN
Print view View original

61–70 of 74 posts

Re: Python for Humans

#61

Post by antihero »

dave1010uk wrote: post #55
rmccue wrote: post #50

As much as I know everyone dislikes PHP, there's lots of people still working with it. I love Requests in Python, so I built Requests for PHP: http://requests.ryanmccue.info/ I have to agree with Kenneth's points, in that pragmatism should outweigh the theoretical points. For example, in PHP, using a class as a grouping for static methods is a bad idea. I agree to a point, but there's something to be said for the abi…

If autoloading namespaces or namespaced functions was possible then static classes wouldn't be needed and things like this would be commonplace: \Requests\get('http://google.com');

Another reminder of why in the fuck did they use the backslash character.

Re: Python for Humans

#62

Post by antihero »

rmccue wrote: post #50

As much as I know everyone dislikes PHP, there's lots of people still working with it. I love Requests in Python, so I built Requests for PHP: http://requests.ryanmccue.info/ I have to agree with Kenneth's points, in that pragmatism should outweigh the theoretical points. For example, in PHP, using a class as a grouping for static methods is a bad idea. I agree to a point, but there's something to be said for the abi…

A little nitpick. In your tutorial you do:

    $request = Requests::get(...);
This should really be:

    $response = Requests::get(...);
As you get a Response object back.

Re: Python for Humans

#63

Post by porker »

revolutions wrote: post #12

A bit off-topic, but I couldn't find this and was very curious: What font are the slides using in the code snippets? It looks very clean--I didn't realize it was monospace at first.

And also, what's the main font used for all the text? It's a lovely serif

Re: Python for Humans

#64

Post by dmritard96 »

spot on - if only I knew many others felt this way when building projects. lol

Maybe libraries should have a rating or something just for fun. Might help direct attention at problems like this.

Re: Python for Humans

#65

Post by kenneth_reitz »

falcolas wrote: post #22

While I appreciate the effort to make some more simplistic APIs available alongside their more complex counterparts - libraries like urllib2 are not expendable in the process. In the act of making an API simpler and abstracting the details - you loose a lot of the detailed control provided by these lower level libraries. Perhaps you won't miss the 10% as outlined in the slides, but someone out there will. Do we reall…

Anyone needing more power/flexibility should use httplib.

Re: Python for Humans

#66

Post by revolutions »

porker wrote: post #63
revolutions wrote: post #12

A bit off-topic, but I couldn't find this and was very curious: What font are the slides using in the code snippets? It looks very clean--I didn't realize it was monospace at first.

And also, what's the main font used for all the text? It's a lovely serif

Looks like this one: http://www.azfonts.net/load_font/high_tower_text.html

Re: Python for Humans

#67

Post by codexon »

Nagyman wrote: post #52
akkartik wrote: post #46

Earlier quoted context omitted.

It's a reasonable tradeoff for a specific library. But if he's trying to claim that the entire eco-system should put the API above all, then it's worth asking how the 5% use case integrates with this worldview. If I suddenly find I need multiple IPs, do I now need to switch my http client library?

The slides don't mention this, but he did touch on having layered designs so the 5% remains possible. However, the primarily exposed api shouldn't get sacrificed for said features. By conceding on a feature that makes the API less usable, you sacrifice more than not having it in the first place (confusion, complexity). Even the GH Issue linked shows a possible solution to the issue using urllib2, which is just a laye…

I don't understand, what is not usable about being about do to this:

requests.get('news.ycombinator.com', sourceip='1.2.3.4')

Re: Python for Humans

#68

Post by rmccue »

antihero wrote: post #62
rmccue wrote: post #50

As much as I know everyone dislikes PHP, there's lots of people still working with it. I love Requests in Python, so I built Requests for PHP: http://requests.ryanmccue.info/ I have to agree with Kenneth's points, in that pragmatism should outweigh the theoretical points. For example, in PHP, using a class as a grouping for static methods is a bad idea. I agree to a point, but there's something to be said for the abi…

A little nitpick. In your tutorial you do: $request = Requests::get(...); This should really be: $response = Requests::get(...); As you get a Response object back.

Good point, thanks. I'll fix that up.

Re: Python for Humans

#69

Post by rmccue »

dave1010uk wrote: post #55
rmccue wrote: post #50

As much as I know everyone dislikes PHP, there's lots of people still working with it. I love Requests in Python, so I built Requests for PHP: http://requests.ryanmccue.info/ I have to agree with Kenneth's points, in that pragmatism should outweigh the theoretical points. For example, in PHP, using a class as a grouping for static methods is a bad idea. I agree to a point, but there's something to be said for the abi…

If autoloading namespaces or namespaced functions was possible then static classes wouldn't be needed and things like this would be commonplace: \Requests\get('http://google.com');

That's true, and it's something that's being discussed on the PHP core mailing list.

However, I support PHP 5.2 (pragmatic reasons; 5.2 is still used by a huge percentage of hosts), so I wouldn't be able to use that anyway.

Post reply on HN