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

21–30 of 74 posts

Re: Python for Humans

#21

Post by jwpeddle »

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.

Re: Python for Humans

#22

Post by falcolas »

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 really need both? I think no, but then again for most of what I do, urllib2 just works; I'm not really the target for requests. Just don't expect that requests will ever replace urllib2.

Re: Python for Humans

#23

Post by peter_l_downs »

jwpeddle wrote: post #16
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/

Some feedback from reading this page: - Why is your example logger named d? It might seem nitpicky but it's hard to read an example with a meaningless single character variable. - "d.close() # stop logging" - what is this? What does it mean to "stop logging" and why do I want to? - "Add a coroutine" - I would wager the lay Python developer doesn't even know what this word means. - lggr.Lggr() - Why not just name the…

Hi jwpeddle, thanks for all of the feedback! All of the changes I've made are on a branch called 'hn-fix' (https://github.com/peterldowns/lggr/tree/hn-fix) if you'd like to take a look.

    > Why is your example logger named d? It might seem nitpicky but
    > it's hard to read an example with a meaningless single character variable.
No particular reason -- you're right, I will change this now.

    > "d.close() # stop logging" - what is this? What does it mean to "stop logging"
    > and why do I want to?
This is a way to "close" the logger and clean up all of its associated coroutines. An example of when you might want to is upon catching a fatal error to your program, you might want to log the error and then safely clean up all open files or network sockets to which the logger is writing.

The method name is clearly confusing -- what do you think of using "shutdown" instead?

    > "Add a coroutine" - I would wager the lay Python developer doesn't
    > even know what this word means.
Maybe not, but they should! The readme now includes a link to dabeaz's coroutines page, and I'll add a quick overview in a couple of minutes.

    > lggr.Lggr() - Why not just name the class Logger?
For consistency's sake. Maybe if I had to start again I would call the project `logger`, but I decided to be "hip" and use a vowel-less name instead :)

    > The default format variables are inconsistent about when words are separated
    > with an underscore.
The initial idea was to mimic the variable names from the default logging module (http://docs.python.org/2/library/logging.html#logrecord-attr...). You're right that it is confusing though! I think I will rename everything to be lower case, one word, instead of the default module's mix of camelCase and underscore_separated names. Thoughts?

    > I can't make sense of the example logging calls. In one you pass a
    > dictionary as the second argument, in another you pass three strings
    > as separate arguments. Why would anyone pass a message like this
    > instead of just using standard string formatting? Especially when
    > there's other legit arguments like extra. It's not even really clear
    > why you'd want to pass something in extra instead of in the message.
I should definitely clarify what formats are allowed and aren't. The log message format is using standard string formatting -- string.format(), to be exact. The 'extra' argument is a result of trying to imitate the default library (see http://docs.python.org/2/library/logging.html#logging.Logger... for a description of the 'extra' kwarg), and can be useful when you'd like to pass information to every single log message.

Re: Python for Humans

#24

Post by 3pt14159 »

Was there today at PyCon Canada and not only was the presentation Kenneth gave very good, but he was very awesome to talk to afterwards. I randomly came across his 500px account, so we sent him a shirt, and he wore it on Friday just to say thanks :3 (I actually didn't get to see him on the Friday night party, probably because I know him best by his pixelated twitter pic, but it is super cool that he take the time to think of stuff like that).

Re: Python for Humans

#27

Post by ColinWright »

jwpeddle wrote: post #16
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/

Some feedback from reading this page: - Why is your example logger named d? It might seem nitpicky but it's hard to read an example with a meaningless single character variable. - "d.close() # stop logging" - what is this? What does it mean to "stop logging" and why do I want to? - "Add a coroutine" - I would wager the lay Python developer doesn't even know what this word means. - lggr.Lggr() - Why not just name the…

It's trivial to format a bullet list on HN:

* Leave blank lines between bullet points,

* Start each line with

* Bob's your parent's brother.

Hope that helps. See also:

http://news.ycombinator.com/formatdoc

Re: Python for Humans

#28

Post by codexon »

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.

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.

Re: Python for Humans

#29

Post by scottbruin »

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…

If requests hits the 90% and urllib2 the 10%, then requests should be the standard library and urllib2 a module. I think his point is more to point out good modules that most people should use, and should become common knowledge of what people should turn to when trying to do something. Java, for example, has several date and time options but Jodatime actually does what most people want to do with dates and times.

Re: Python for Humans

#30

Post by emillon »

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…

For new projects the use HTTP at a high level, I believe that there is no reason to prefer urllib2 to requests.

Probably it won't replace urllib2, but it has attained critical mass and won't go away soon.

Post reply on HN