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

41–50 of 74 posts

Re: Python for Humans

#41

Post by peter_l_downs »

unshift wrote: post #40
peter_l_downs wrote: post #5

Slightly off topic: in an effort to become a better programmer, and to improve the Python ecosystem, I've tried to write a "for Humans" style logging library. Would anyone mind giving me feedback? http://peterdowns.com/lggr/

your library has no tests! it's a good effort but I honestly wouldn't use it yet. a few nit picks: i can't imagine a scenario where i'd want my logger to close stdout (or any other file descriptor) for me. there is a lot of missing error handling, which is really important for something critical like a logger. what happens when disk space runs out? no timeouts on network operations? also your SMTP and Gmail loggers d…

    > your library has no tests! it's a good effort but I
    > honestly wouldn't use it yet.
You're right, and I'd love to have you help me add them!

    > i can't imagine a scenario where i'd want my logger to
    > close stdout (or any other file descriptor) for me.
By default it won't -- see https://github.com/peterldowns/lggr/blob/master/lggr/__init_....

    > there is a lot of missing error handling, which is really
    > important for something critical like a logger. what
    > happens when disk space runs out? no timeouts on
    > network operations?
    > [...]
    > you also seem to just swallow exceptions which is totally
    > not what I would want or expect from a logging library.
Lggr will fail silently by default, because your logging library shouldn't cause your code to crash. If you'd like, it's quite easy to stop it from suppressing errors. For more complex error handling, I think users should write their own coroutines for handling log messages -- the default file printing and network sending coroutines are merely the most basic case.

    > also your SMTP and Gmail loggers don't form valid MIME messages
    > (I can't log non-ascii?).
Please help me and add loggers that do format valid MIME message! The included loggers/coroutines are just a few examples I came up with, but I'd love if other people were to contribute more :)

    > keep at it though, the logging module's API (inspired by log4j)
    > is fairly painful.
Thank you, and thanks for your feedback :)

Re: Python for Humans

#42

Post by tnuc »

pav3l wrote: post #11

>lxml is awesome, but difficult to install So true... I often need to write something that will run on a Windows machine and I just end up having to use the old version of Beautiful Soup (before it became dependent on lxml). Pretty frustrating.

lxml is great. The docs and the installation aren't the best.

For a windows install. http://www.lfd.uci.edu/~gohlke/pythonlibs/

Re: Python for Humans

#43

Post by js2 »

urllib2 is so bad (and I know how to use it) that I have at times used subprocess + curl, which says a lot, because subprocess ain't exactly pretty either. But the thing is, urllib2 is included and is the devil I know.

Re: Python for Humans

#45

Post by pav3l »

tnuc wrote: post #42
pav3l wrote: post #11

>lxml is awesome, but difficult to install So true... I often need to write something that will run on a Windows machine and I just end up having to use the old version of Beautiful Soup (before it became dependent on lxml). Pretty frustrating.

lxml is great. The docs and the installation aren't the best. For a windows install. http://www.lfd.uci.edu/~gohlke/pythonlibs/

Thanks so much! Just tried it and the setup binaries worked like a charm! 20 seconds for the whole experience including downloading and testing. Very different from how I remember my experience with lxml on Windows when I tried it before! They should definitely have a link to this website from http://lxml.de/installation.html#ms-windows

Re: Python for Humans

#46

Post by akkartik »

jwpeddle wrote: post #21
codexon wrote: post #15

His requests module is an improvement, but he says being able to specify the outbound IP of an HTTP request is out of the scope of his module??? https://github.com/kennethreitz/requests/issues/394 That's why I am still using urllib2.

I'm not sure why you feel this niche requirement requires three question marks. The point of modules like this is to make it easier to do the tasks that 95% of developers are likely to need to do regularly, at the cost of not covering all rare use cases.

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?

Re: Python for Humans

#47

Post by batgaijin »

js2 wrote: post #43

urllib2 is so bad (and I know how to use it) that I have at times used subprocess + curl, which says a lot, because subprocess ain't exactly pretty either. But the thing is, urllib2 is included and is the devil I know.

I remember writing raw socket stuff and I actually thought that was better than urllib2.

Re: Python for Humans

#48

Post by maaku »

aiiane wrote: post #33
codexon wrote: post #28

Earlier quoted context omitted.

I think it is a fairly common requirement to use multiple IPs to avoid throttling or for APIs that restrict access to individual IPs. The fact that he was confused by it does not help his credibility when he is trying to tell people how to design their libraries.

I have yet to ever have to use multiple outbound IPs from the same machine for an HTTP request from Python. It might be "fairly common" for whatever you do, but in terms of the general population, it's not.

Still, it's a fair point that it at least should be possible. It's fine by me if the uncommon 5% tasks are just as difficult to do in requests or even a little more so, so long as the most common 95% of tasks are a breeze.

Re: Python for Humans

#50

Post by rmccue »

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 ability to do `Requests::get('http://google.com/)` versus all the crap you have to do with cURL. (Plus, it's always >90% test coverage, which I stick to religiously.)

Post reply on HN