A look at some of Python's useful itertools • Hacker News Board

Re: A look at some of Python's useful itertools

#11

Post by shavenwarthog2 » Sat, May 25, 2013, 8:16 PM UTC

wting wrote: post #2

My intention is not to be snarky, but people post all the time about discovering the itertools or collections library. I notice it's a common gap in newer Python programmers. Save yourself time and effort down the road and read through both libraries' documentation, they're well worth the effort: http://docs.python.org/3.3/library/itertools.html http://docs.python.org/3.3/library/collections.html I tend to use defaul…

Seconded. I use itertools constantly for data-wrangling on network server and web applications. Specifically:

- processing files with imap and ifilter to rapidly grab data, find a subset of it, then process it with a function

- defaultdict(list) is incredibly useful for collecting data, arranging it by a certain key (like date or object id), then collecting into a list

- namedtuple is occasionally useful for efficiently stuffing data into an object with a few named attributes.

Re: A look at some of Python's useful itertools

#12

Post by Too » Sat, May 25, 2013, 9:23 PM UTC

Silhouette wrote: post #10

pjmlp wrote: post #7

Earlier quoted context omitted.

>My intention is not to be snarky, but people post all the time about discovering the itertools or collections library. I notice it's a common gap in newer Python programmers. Not only in Python, but programming languages in general. I still find people writing Java or .NET code that aren't aware of all nice classes that are part of the runtime and end up creating their half baked solutions for their problems. Nowada…

Nowadays developers seem to code without reading. When your standard library documentation is so vast that it would take weeks to read and understand it all, and you'd never remember most of it anyway without context and experience using it, I don't think "coding without reading" is really a fair complaint. We as an industry need to get better at documentation, and in particular about separating tutorial/overview doc…

Documentation discoverability is one problem. Willingness to learn and trust is another one. People simply want to use things that they themselves have proven to work before.

As an example an old colleague wanted to dump some data from python to a csv-file and did this by for-looping through each row and each item and concatenating each cell and a semicolon to a string. Even after pointing out to him that python already has a built in csv writer, that handles all issues of escaping etc, he didn't want to use it because he didn't know what it did and didnt want to learn anything new. His version didn't even do escaping inside the for-loop and he didn't see the issue of not doing it. To him the for-loop gave exactly the same result and didn't require any learning and was thus better, and why change something that works... My last suggestion was to at least use ";".join(...) but it was also a bit too magic so he stuck to his well known for-loop.

Usually standard libraries are quite reliable but in some cases, and especially if adding third party libraries, bugs and performance issues inside the library can really give you hell. If the library is supposed to just perform a simple task maybe you would rather implement it yourself as you then also have influence to fix those issues yourself later. Experiences like this can scare you away from even the most reliable libraries in the future.

Re: A look at some of Python's useful itertools

#13

Post by pjmlp » Sat, May 25, 2013, 10:38 PM UTC

Silhouette wrote: post #10

pjmlp wrote: post #7

Earlier quoted context omitted.

>My intention is not to be snarky, but people post all the time about discovering the itertools or collections library. I notice it's a common gap in newer Python programmers. Not only in Python, but programming languages in general. I still find people writing Java or .NET code that aren't aware of all nice classes that are part of the runtime and end up creating their half baked solutions for their problems. Nowada…

Nowadays developers seem to code without reading. When your standard library documentation is so vast that it would take weeks to read and understand it all, and you'd never remember most of it anyway without context and experience using it, I don't think "coding without reading" is really a fair complaint. We as an industry need to get better at documentation, and in particular about separating tutorial/overview doc…

I consider it a fair complaint, because young developers seem not willing to learn.

I am old enough to remember the days the only way to learn how to program was to go through, sometimes very dry, books and manuals. There was no Internet on those days.

Young developers seem like spoiled kids that want to do something right away, without setting the time to learn how to do it properly.

Re: A look at some of Python's useful itertools

#14

Post by Silhouette » Sat, May 25, 2013, 11:14 PM UTC

pjmlp wrote: post #13

Silhouette wrote: post #10

Earlier quoted context omitted.

Nowadays developers seem to code without reading. When your standard library documentation is so vast that it would take weeks to read and understand it all, and you'd never remember most of it anyway without context and experience using it, I don't think "coding without reading" is really a fair complaint. We as an industry need to get better at documentation, and in particular about separating tutorial/overview doc…

I consider it a fair complaint, because young developers seem not willing to learn. I am old enough to remember the days the only way to learn how to program was to go through, sometimes very dry, books and manuals. There was no Internet on those days. Young developers seem like spoiled kids that want to do something right away, without setting the time to learn how to do it properly.

I am old enough to remember the days the only way to learn how to program was to go through, sometimes very dry, books and manuals. There was no Internet on those days.

Join the club. We're getting T-shirts made. :-)

The thing is, in those days we really could learn all the commands of an operating system shell by reading the manual cover to cover in an afternoon, or play with graphics demos or write low-level system utilities after reading the Pink Shirt Book.

Today's systems are so vast and complicated that anything offering similar coverage in book form would be the size of an encyclopaedia, so the way we were able to learn doesn't scale to modern needs.

The trend over the years has definitely been towards writing glue code and joining up ready-made components for a lot of professional work rather than reinventing things from scratch, and in some ways that's no bad thing. However, I think it only works if you know what you've got available in your toolbox, and so does being the person who understands and creates new components. Either way, it comes back to needing a way to navigate the vast amounts of information now available and pick out the bits you need to achieve whatever it is that you're trying to do.

Re: A look at some of Python's useful itertools

#15

Post by Silhouette » Sat, May 25, 2013, 11:31 PM UTC

Too wrote: post #12

Silhouette wrote: post #10

Earlier quoted context omitted.

Nowadays developers seem to code without reading. When your standard library documentation is so vast that it would take weeks to read and understand it all, and you'd never remember most of it anyway without context and experience using it, I don't think "coding without reading" is really a fair complaint. We as an industry need to get better at documentation, and in particular about separating tutorial/overview doc…

Documentation discoverability is one problem. Willingness to learn and trust is another one. People simply want to use things that they themselves have proven to work before. As an example an old colleague wanted to dump some data from python to a csv-file and did this by for-looping through each row and each item and concatenating each cell and a semicolon to a string. Even after pointing out to him that python alre…

Usually standard libraries are quite reliable but in some cases, and especially if adding third party libraries, bugs and performance issues inside the library can really give you hell.

I think part of the problem is that the statement above is maybe not as true as it used to be.

Let's stick with Python as an example, though it's far from the only culprit so I hesitate to single it out here. I have a growing list of areas of the standard library that today I just assume won't work acceptably. I have tried to use them before, and I have found them to be either bug-ridden or not robustly portable or so slow as not to be worthwhile or missing enough basic functionality that you need to add something else anyway or just write everything from scratch. The everyday stuff in Python is pretty good, the basic data structures and common supporting functions like itertools, but when you start getting into the less common areas I have a very low opinion of the design and quality of the Python standard library, and that opinion is born of direct personal experience.

On top of the quality and robustness, there's also usability to consider. Even if some of Python's built-in libraries do work, there might be much neater, easier ways to achieve the same result that are only a `pip install` away. Libraries like Kenneth Reitz's Requests come immediately to mind; if I were teaching a newbie to program Python tomorrow, somehow I doubt urllib[N] would feature much.

I'm not sure how that hypothetical newbie is supposed to discover these things today without someone experienced to guide them, though. Whether it's Python and PyPI or Perl and CPAN or C++ and Boost or whatever other language and library repository you like, there's a lot of collective wisdom about the easiest/safest/fastest ways to get things done, but it lives in the combined experience of veterans rather than in comprehensive tutorials to follow once you've got the basics down. And that's only when there is already a recognisable place to look for general use third party libraries, not even considering all the third party libraries that might be out there but for whatever reason aren't incorporated into any de facto standard repository to make discovery (relatively) easy if you at least know what you're looking for.

Is it any wonder that newbies reinvent wheels under these conditions? It seems almost inevitable to me.

Re: A look at some of Python's useful itertools

#16

Post by d0mine » Sun, May 26, 2013, 2:49 AM UTC

Silhouette wrote: post #10

pjmlp wrote: post #7

Earlier quoted context omitted.

>My intention is not to be snarky, but people post all the time about discovering the itertools or collections library. I notice it's a common gap in newer Python programmers. Not only in Python, but programming languages in general. I still find people writing Java or .NET code that aren't aware of all nice classes that are part of the runtime and end up creating their half baked solutions for their problems. Nowada…

Nowadays developers seem to code without reading. When your standard library documentation is so vast that it would take weeks to read and understand it all, and you'd never remember most of it anyway without context and experience using it, I don't think "coding without reading" is really a fair complaint. We as an industry need to get better at documentation, and in particular about separating tutorial/overview doc…

Have you read the tutorial http://docs.python.org/tut ?

Re: A look at some of Python's useful itertools

#17

Post by acjohnson55 » Sun, May 26, 2013, 2:53 AM UTC

Too wrote: post #12

Silhouette wrote: post #10

Earlier quoted context omitted.

Nowadays developers seem to code without reading. When your standard library documentation is so vast that it would take weeks to read and understand it all, and you'd never remember most of it anyway without context and experience using it, I don't think "coding without reading" is really a fair complaint. We as an industry need to get better at documentation, and in particular about separating tutorial/overview doc…

Documentation discoverability is one problem. Willingness to learn and trust is another one. People simply want to use things that they themselves have proven to work before. As an example an old colleague wanted to dump some data from python to a csv-file and did this by for-looping through each row and each item and concatenating each cell and a semicolon to a string. Even after pointing out to him that python alre…

That just sounds like laziness as a coder to me. Would he also output to JSON from scratch?

I taught high school for a while, and I had kids that refused to stop using their fingers for addition, regardless of the fact that it was preventing them from learning how to do more abstract math. What you're describing is pretty much the same attitude.

Re: A look at some of Python's useful itertools

#18

Post by acjohnson55 » Sun, May 26, 2013, 2:55 AM UTC

Silhouette wrote: post #15

Too wrote: post #12

Earlier quoted context omitted.

Documentation discoverability is one problem. Willingness to learn and trust is another one. People simply want to use things that they themselves have proven to work before. As an example an old colleague wanted to dump some data from python to a csv-file and did this by for-looping through each row and each item and concatenating each cell and a semicolon to a string. Even after pointing out to him that python alre…

Usually standard libraries are quite reliable but in some cases, and especially if adding third party libraries, bugs and performance issues inside the library can really give you hell. I think part of the problem is that the statement above is maybe not as true as it used to be. Let's stick with Python as an example, though it's far from the only culprit so I hesitate to single it out here. I have a growing list of…

I haven't come away with the same impression of the Python standard library. Besides urllib, what are the biggest offenders in your mind?

Re: A look at some of Python's useful itertools

#19

Post by Silhouette » Sun, May 26, 2013, 3:34 AM UTC

acjohnson55 wrote: post #18

Silhouette wrote: post #15

Earlier quoted context omitted.

Usually standard libraries are quite reliable but in some cases, and especially if adding third party libraries, bugs and performance issues inside the library can really give you hell. I think part of the problem is that the statement above is maybe not as true as it used to be. Let's stick with Python as an example, though it's far from the only culprit so I hesitate to single it out here. I have a growing list of…

I haven't come away with the same impression of the Python standard library. Besides urllib, what are the biggest offenders in your mind?

From a few recent projects:

The subprocess system is fairly awful in both usability and portability.

The shutil filesystem tools had bugs and documentation issues the only time I ever tried to use them.

The various compression libraries had horrible performance problems last time I tried them; shelling out to various command-line equivalents was around 4-5x faster.

The command-line parsing tools are OK if you want to write a *nix-style command line tool, but not quite flexible enough for more advanced/customised uses.

I have yet to discover any decent GUI library for Python, standard or otherwise, so I'm not sure whether this one counts.

Logging is flexible but can be awkward to configure, particularly across an application that wants various logging itself but also uses libraries that offer to log.

Re: A look at some of Python's useful itertools

#20

Post by brandnewthrow » Sun, May 26, 2013, 4:29 AM UTC

acjohnson55 wrote: post #17

Too wrote: post #12

Earlier quoted context omitted.

Documentation discoverability is one problem. Willingness to learn and trust is another one. People simply want to use things that they themselves have proven to work before. As an example an old colleague wanted to dump some data from python to a csv-file and did this by for-looping through each row and each item and concatenating each cell and a semicolon to a string. Even after pointing out to him that python alre…

That just sounds like laziness as a coder to me. Would he also output to JSON from scratch? I taught high school for a while, and I had kids that refused to stop using their fingers for addition, regardless of the fact that it was preventing them from learning how to do more abstract math. What you're describing is pretty much the same attitude.

I've taken math classes up to Linear Algebra, (so basically what was required for a CS degree) and I still count on my fingers sometimes. In fact I think that math got more intuitive and "mentally pliable" the more abstract it got, but for some reason I'm still pretty hopeless with arithmetic. I also have trouble with telling right from left. Is it really the case that using fingers for arithmetic can hold a person back from learning higher math? Not trying to be snarky, genuinely curious.