The Python Standard Library - Where Modules Go To Die • Hacker News Board

Re: The Python Standard Library - Where Modules Go To Die

#71

Post by slurgfest » Wed, May 02, 2012, 4:29 AM UTC

chaostheory wrote: post #25

nkoren wrote: post #19

I'm not really a Python programmer, but a hacker who occasionally has cause to pick up Python scripts and do stuff with them. Perhaps I've been unlucky, but every time I've done this, it's turned into a profoundly frustrating exercise. There have always been dependencies outside the standard library, and those have had dependencies -- which more often than not, are incompatible with whatever version of Python my envi…

I think the problem is because when you used it the Python community probably still hadn't decided on a one true dependency system like Gems / rvm for Ruby, and Maven for Java. It's been about four years since I've heavily used Python, but hopefully this has been fixed by now. I don't have this problem on either Ruby or Java.

Nope, pip and virtualenv are pretty much it. Use 'em

Re: The Python Standard Library - Where Modules Go To Die

#72

Post by slurgfest » Wed, May 02, 2012, 4:30 AM UTC

zeeg wrote: post #16

true_religion wrote: post #11

Earlier quoted context omitted.

How is it not well defined in Python?

Well it would work just fine, but you'd always end up requiring the external dependency even if you didn't need to. For example, let's say there was a new urllib released (its still called urllib). It's now version 2.0, but the stdlib version is 1.0. If your package said "I need urllib==1.0", it would have know way of understanding that the version was already included within the standard library. That said, it would…

Since it would work just fine, what is the problem you are trying to solve? Having to download too much stuff?

Re: The Python Standard Library - Where Modules Go To Die

#73

Post by slurgfest » Wed, May 02, 2012, 4:33 AM UTC

EvilTerran wrote: post #44

It's funny, I've had the opposite problem. I was trying to write an IRC bot in Python, noted there didn't seem to be a standard library module for the IRC protocol, and so found myself looking at this: http://pypi.python.org/pypi?%3Aaction=search&term=IRC That's 400+ results - at least 20 of which are actually IRC protocol modules. There's no way of telling how mature each one actually is 'til you download it. It tur…

I believe that PyPI used to have some kind of popularity contest functionality that got killed.

I have to say I'm not sure that selecting the package you want to use is really the problem which PyPI needs to solve. It isn't the app store. That said, PyPI does provide a 'weight' in searches, which seems to track with popularity and freshness somehow.

Re: The Python Standard Library - Where Modules Go To Die

#74

Post by EvilTerran » Wed, May 02, 2012, 10:46 AM UTC

slurgfest wrote: post #73

EvilTerran wrote: post #44

It's funny, I've had the opposite problem. I was trying to write an IRC bot in Python, noted there didn't seem to be a standard library module for the IRC protocol, and so found myself looking at this: http://pypi.python.org/pypi?%3Aaction=search&term=IRC That's 400+ results - at least 20 of which are actually IRC protocol modules. There's no way of telling how mature each one actually is 'til you download it. It tur…

I believe that PyPI used to have some kind of popularity contest functionality that got killed. I have to say I'm not sure that selecting the package you want to use is really the problem which PyPI needs to solve. It isn't the app store. That said, PyPI does provide a 'weight' in searches, which seems to track with popularity and freshness somehow.

The title text on "weight" says "Occurrence of search term weighted by field (name, summary, keywords, description, author, maintainer)". So, not popularity/freshness, just a rough metric for how well it matches your search.

Indeed, PyPI might not be the right place for a community rating system -- perhaps a site could be built on top of it to provide that sort of functionality.

Re: The Python Standard Library - Where Modules Go To Die

#75

Post by IgorPartola » Fri, May 04, 2012, 9:58 AM UTC

slurgfest wrote: post #70

IgorPartola wrote: post #35

Agreed with the OP. The following is a shameless plug: Python's ConfigParser module is a pain to use. It provides no validation, only supports a limited number of types of data you can retrieve, etc. Similarly, getopt vs optparse vs argparse is a mess. getopt is universal: not only is it going to be in all versions of Python, but it is also the same library available in virtually every other language. The problem wit…

I don't understand why I shouldn't be using argparse. Just using argparse means no mess of 'getopt vs optparse vs argparse' because I am not using all those other libraries. I don't see anything seriously wrong for argparse. How does it help me to use a third party module rather than argparse?

Using argparse is probably the safest approach. However, argparse does not work with config files; groper does. So if you have more than a half-dozen options, you should use groper (or something similar).