51–60 of 74 posts
Earlier quoted context omitted.
While not a table of "stdlib package => 3rd party package", there is this: http://docs.python-guide.org/en/latest [ Also by Kenneth Reitz ]
That link doesn't appear to work for me, so I think the same content is available at http://docs.python-guide.org/
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
That link doesn't appear to work for me, so I think the same content is available at http://docs.python-guide.org/
Sorry. Looks like the trailing slash was omitted when I copy-pasted that from the location bar. ^^;;
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…
\Requests\get('http://google.com');Wow, this is cool. Kenneth has started to identify and call out other libraries that are "barriers to entry" in Python. If this is a call to arms to scale the Requests experience, it could grow into something really powerful - a movement to systematically reinvent and rejuvenate the Python standard library.
Yep. I was looking for exactly this list. Incidentally Python could use an more equivalent to djangopackages.com to help in identifying popular alternatives to standard lib packages.
him: "have you ever used urllib2"
me: "not if I can avoid it"
him: "I've just spent 3 days trying to do X"
me: "have you heard of Requests"
him: "nope"
...send URL...
him: "god damn it! Why didn't I talk to you three days ago"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/
A big feature missing, IMHO, is file-based configuration. You definitely want this for larger projects.
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…
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/
d.critical("Someone {} us {} the {}!", "set", "up", "bomb")