Check out boto. It's Amazon's official library for interacting with AWS. It is written and tested well. I use it every day. https://github.com/boto/boto
Boto3 might also be worth a read. https://github.com/boto/boto3
Ask HN: Good Python codebases to read?
101–110 of 153 posts
Re: Ask HN: Good Python codebases to read?
#102Peter Norvig's examples. They are quite short and include much explanation in addition to code. They also include tests and benchmarking code. http://norvig.com/lispy.html http://norvig.com/lispy2.html (Lisp interpreter) http://www.norvig.com/spell-correct.html (Spelling corrector) http://norvig.com/sudoku.html (Sudoku solver) Also his online course Design of Computer programs includes many short, well-explained Pyth…
Norvig's code have several qualities to praise
Adherence to Python's best practices / pep-8 are not one of them
Re: Ask HN: Good Python codebases to read?
#103Earlier quoted context omitted.
His coding style is not common to most writers of Python. He's using overly terse, poorly descriptive variable names, not using multiline strings for docstrings, not indenting where he should, and one-lining if/elif statements and function definitions. This style does not contribute to readability. This is not how I would want someone just learning Python to learn it.
Well, between a run of the mill programmer who happens to indent where he/she should vs Norvig, I will likely choose the latter If I could. Reminds me of that blog thread where this design pattern guru hemmed and hawed from his high horse over several posts about how to write constrained based solvers and still did not get to a piece of code that actually solved the problem, whereas Norvig just posted a simple soluti…
>Well, between a run of the mill programmer who happens to indent where he/she should vs Norvig, I will likely choose the latter If I could.
Right.
>Reminds me of that blog thread where this design pattern guru hemmed and hawed from his high horse
I read a similar story a while ago. Two programmers are given the task of writing a program for some non-trivial problem.
One of them, Hoity Toity Harry, tries to apply many of the latest and greatest algorithms, techniques, paradigms, etc., to impress people (of course).
The other, Down To Earth Dan, just strives for a good implementation, with reasonably good algorithms, etc. After a while, Dan finishes his program and does a test run. It works well enough for the task. Meanwhile, Harry is not even near to finishing his code, due to struggling with complexities of the techniques he has tried to use.
The boss comes in, sees the results, and congratulates Down To Earth Dan.
Hoity Toity Harry, of course, has to protest, trying to put down Down To Earth Dan's implementation, saying that it uses simple algorithms, etc., while his own code uses sophisticated, state of the art techniques. Dan replies: "Yes, I could also have used those things. But my program runs, and yours doesn't."
Okay, I changed the programmers' names for fun and effect, but I really did read the story, in some good (and pragmatic) software book, a while ago.
Re: Ask HN: Good Python codebases to read?
#104Check out boto. It's Amazon's official library for interacting with AWS. It is written and tested well. I use it every day. https://github.com/boto/boto
I've had to read the source of boto since there were some boto exceptions I was seeing in stack traces in the fabric deploy process - and ugh, I found the code to be not very intuitive and the documentation poor. Anyone else run into the same issues with boto?
I've found the documentation (not the codebase itself) to be very hit-or-miss. Some components are very well documented, some not at all. Presumably due to maturity of different parts of the stack and the Boto library, but still frustrating from an end-user perspective.
Re: Ask HN: Good Python codebases to read?
#105Earlier quoted context omitted.
> Spare us the half-baked hackery. Ad hominem? I guess I win. > List comprehensions and generator expressions have replaced all need for map, filter, and lambdas Please explain how list comprehensions and generators have replaced the need for lambdas. >>> sorted(((x, -(x**2)) for x in xrange(10) if 0 == x % 2), key=lambda item: item[1]) [(8, -64), (6, -36), (4, -16), (2, -4), (0, 0)] Your "distaste" of functional pro…
Nice lambda. You've defended yourself admirably. Did you know there's an `operator.itemgetter` function that does that? So that's: >>> sorted(((x, -(x**2)) for x in xrange(10) if 0 == x % 2), key=operator.itemgetter(1)) [(8, -64), (6, -36), (4, -16), (2, -4), (0, 0)] Do note that good code and code golf are two different things! :D
> Nice lambda. You've defended yourself admirably.
Thanks!
> Did you know there's an `operator.itemgetter` function that does that?
Yes, I'm quite aware! Are you aware the "useless" functional solution with lambda is two characters shorter?
>>> len('lambda item: item[1]')
20
>>> len('operator.itemgetter(1)')
22
Re: Ask HN: Good Python codebases to read?
#106Here's the link to the Pandas DataFrame source: https://github.com/pydata/pandas/blob/master/pandas/core/fra...
We spent a month of Sundays going through this in the NYC Python office hours. You learn a lot about this object by reading the source, and the WTF per minute rate is fairly low.
The style is also fairly non-controversial.
Re: Ask HN: Good Python codebases to read?
#107Earlier quoted context omitted.
Spare us the half-baked hackery. List comprehensions and generator expressions have replaced all need for map, filter, and lambdas, and are far more readable. For someone new to Python, halfway through LPTHW, they don't need those things. Hey, maybe you can help me decipher this, I've always wondered exactly what's going on here: https://docs.python.org/2/faq/programming.html#is-it-possibl... # Mandelbrot set print (…
> Spare us the half-baked hackery. Ad hominem? I guess I win. > List comprehensions and generator expressions have replaced all need for map, filter, and lambdas Please explain how list comprehensions and generators have replaced the need for lambdas. >>> sorted(((x, -(x**2)) for x in xrange(10) if 0 == x % 2), key=lambda item: item[1]) [(8, -64), (6, -36), (4, -16), (2, -4), (0, 0)] Your "distaste" of functional pro…
>> Spare us the half-baked hackery.
>Ad hominem? I guess I win.
That was not ad hominem, because what you wrote is indeed half-baked hackery.
Nobody said it cannot be done the way you did it. You were just pointed at the shortcomings of your approach and that the Python community generally prefers stupidly simple, easy to understand solutions. Using magic attributes to argue against it just makes it worse - remember this is a thread about idiomatic Python code bases.
Re: Ask HN: Good Python codebases to read?
#108Earlier quoted context omitted.
Nice lambda. You've defended yourself admirably. Did you know there's an `operator.itemgetter` function that does that? So that's: >>> sorted(((x, -(x**2)) for x in xrange(10) if 0 == x % 2), key=operator.itemgetter(1)) [(8, -64), (6, -36), (4, -16), (2, -4), (0, 0)] Do note that good code and code golf are two different things! :D
> Nice lambda. You've defended yourself admirably. Thanks! > Did you know there's an `operator.itemgetter` function that does that? Yes, I'm quite aware! Are you aware the "useless" functional solution with lambda is two characters shorter? >>> len('lambda item: item[1]') 20 >>> len('operator.itemgetter(1)') 22 Cause you're apparently not aware that I was demonstrating a use-case for lambdas as one-off functions that…
I bet you two would be good friends IRL.
Re: Ask HN: Good Python codebases to read?
#109Re: Ask HN: Good Python codebases to read?
#110Earlier quoted context omitted.
> Spare us the half-baked hackery. Ad hominem? I guess I win. > List comprehensions and generator expressions have replaced all need for map, filter, and lambdas Please explain how list comprehensions and generators have replaced the need for lambdas. >>> sorted(((x, -(x**2)) for x in xrange(10) if 0 == x % 2), key=lambda item: item[1]) [(8, -64), (6, -36), (4, -16), (2, -4), (0, 0)] Your "distaste" of functional pro…
>> Spare us the half-baked hackery. >Ad hominem? I guess I win. That was not ad hominem, because what you wrote is indeed half-baked hackery. Nobody said it cannot be done the way you did it. You were just pointed at the shortcomings of your approach and that the Python community generally prefers stupidly simple, easy to understand solutions. Using magic attributes to argue against it just makes it worse - remember…
Now you're moving goalposts...
> Nobody said it cannot be done the way you did it. You were just pointed at the shortcomings of your approach
I "addressed" the shortcomings of "my approach" by showing that Python (the language, not the community) allows you to access and manipulate the data you claimed was important and missing.
I don't believe it is necessary for most simple functions to know what their name is. I do believe the demonstrated code is self documenting enough to not require a documentation string. You made those "requirements". I never claimed that every function must be a lambda - you seem to be implying I am, so I am explicitly stating that I do not.
Here's a place where you really do need a named function (due to deficiencies in Python's lambda implementation):
>>> def named_lambda(procedure, name, documentation=''):
... procedure.__name__ = ''.format(name)
... procedure.__doc__ = documentation
... return procedure
...
>>> absolute_path = named_lambda(lambda path: path if path.startswith('/') else '/' + path, 'absolute_path', 'Return the absolute unix path from a given path name')
>>> absolute_path.__name__
''
>>> absolute_path.__doc__
'Return the absolute unix path from a given path name'
> the Python community generally prefers stupidly simple, easy to understand solutions.
Which, despite your protests, includes using lambdas!
> Using magic attributes to argue against it just makes it worse - remember this is a thread about idiomatic Python code bases.
How else does a function "know its own name" unless it uses the "magic" attribute "__name__"? Oh, you prefer "func_name"? That's cute:
>>> named_lambda.func_name
'named_lambda'
>>> named_lambda.__name__
'named_lambda'
>>> named_lambda.__name__ = 'lol'
>>> named_lambda.func_name
'lol'
>>> named_lambda.func_name = 'named_lambda'
>>> named_lambda.func_name
'named_lambda'