Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A look at some of Python's useful itertools

naiquevin.github.io

Post reply on HN
Print view View original

21–29 of 29 posts

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

#21

Post by Silhouette »

d0mine wrote: post #16
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…

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

Sure. It's a textbook example of the problem I'm talking about, in fact.

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

#22

Post by acjohnson55 »

Silhouette wrote: post #19
acjohnson55 wrote: post #18

Earlier quoted context omitted.

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…

Yeah, I definitely see your point. I haven't used all of those things extensively, but I've got to really agree with you on subprocess and GUI stuff. I'd love to be able to write Python instead of Bash for pretty much all scripting, but working with and connecting subprocesses is a massive pain. I think logging and command line parsing work well, but each seem probably less intuitive than they have to be. But I think the library is pretty awesome for the most part.

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

#23

Post by acjohnson55 »

brandnewthrow wrote: post #20
acjohnson55 wrote: post #17

Earlier quoted context omitted.

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 b…

I'd say the real problem is not the tool itself (finger counting, in this case) but a stubborn reliance on that tool even when it obviously can't scale. Some of these students were more concerned with just executing the algorithm than understanding process of addition, and consequently, some struggled with multi-digit addition, negative numbers, fractions, and so on. They coped with their inability to solve more complicated problems simply by not ever attempting to do the work. The attitude was "I don't get it immediately so I'm not even going to attempt to understand it".

I'm really not trying to bash the students. As a teacher, my job was to invest the students in wanting to learn, and I admittedly wasn't always effective.

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

#24

Post by pjmlp »

Silhouette wrote: post #14
pjmlp wrote: post #13

Earlier quoted context omitted.

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…

Size M please. :)

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

#25

Post by naiquevin »

pjmlp wrote: post #7
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…

>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.

As someone who started programming 4 year back (which from the conversation seems to be pretty much "nowadays" :-)), I think it is a bit of a generalization. I am not saying it's not true. There are certainly places such as StackOverflow, mailing lists etc that attract newbies early on because they provide quick answers or even code, but at some point every developer who is serious about computer programming as a long term profession does need to start reading the docs. There is no other alternative and one eventually comes to realize that it's much faster than arbitrarily hunting for code and asking questions on mailing lists and IRC.

It also depends upon the style of programming language (imperative/functional) and the previous experience of the developer IMO. For eg. I find my self reading the docs significantly more in Erlang/Scala than in Python than in PHP/JS. It is also the reverse order in which I learnt these languages. Of course that is my personal experience.

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

#26

Post by MostAwesomeDude »

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?

asyncore is almost certainly the worst module in the standard library.

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

#27

Post by SEJeff »

Silhouette wrote: post #19
acjohnson55 wrote: post #18

Earlier quoted context omitted.

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…

You can build a cli parser exactly like git uses (positional and short/long) using argparse. What is difficult about that? Opt parse perhaps, but if you're talking about argparse, it seems like you're just whining. The rest of your comments I (overall) agree with

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

#28

Post by Silhouette »

SEJeff wrote: post #27
Silhouette wrote: post #19

Earlier quoted context omitted.

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…

You can build a cli parser exactly like git uses (positional and short/long) using argparse. What is difficult about that? Opt parse perhaps, but if you're talking about argparse, it seems like you're just whining. The rest of your comments I (overall) agree with

You can build a cli parser exactly like git uses (positional and short/long) using argparse.

But what if I want something that isn't like Git? I'm slightly amused that anyone would suggest Git as some sort of example of a good CLI, but in any case, not all platforms share the command line conventions of *nix shells.

Suppose I'm running on Windows (where options conventionally start with '/') and I don't want all the magic that argparse does with initial '-' characters. If I set prefix_chars to '/', does that also disable the '--' pseudo-argument? We were originally talking about documentation, and as far as I'm aware, the documentation for argparse doesn't actually specify this either way.

Suppose I want to have a set of basic choices, each setting a flag to say it's there. What if I also want some shortcut choices that represent combinations of the basic ones and set all of the corresponding flags? As far as I'm aware, you can't quite do this with any of the standard actions, so you have to start writing an entire new class to define a custom action instead. At least you can do that, but what was wrong with accepting a simple function, and where does anything say how argparse.Action is actually defined and why it's necessary instead?

Suppose I want to present the same data as the automatic help option, but reformat it in some completely different way that makes more sense for my program before it gets printed? There are assorted functions to display or return formatted help strings, but nothing seems to just give back a neat bundle of the relevant information for further processing. Collecting the data and rendering it for output are conflated.

Argparse, like much of the Python standard library, has a lot of power as long as you want to do things exactly its way, but it's not designed in a way that is particularly easy to extend. IMHO, a better strategy for designing standard libraries for languages is to create templates/frameworks/whatever you want to call them, and then to provide some specific implementations for basic cases. This way, when inevitably someone needs to go beyond the out-of-the-box functionality, they can still fit in with established conventions instead of starting over from scratch, which is generally better both for compatibility and for minimising the amount of extra logic that much be built on top of the tried and tested standard library. Of course you do have to be careful not to go too far and make simple cases look artificially complicated, but no-one ever said designing good APIs was easy. :-)

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

#29

Post by davvolun »

On the other hand, I suspect some early programmers might get ahold of this and perform a lot of premature optimizations. A piece of code that runs 20 loops instead of 8 once every couple of hours probably doesn't need to be optimized. A piece of code that does two checks when one would suffice that runs 1000 times every second might need optimization. Profile first, then optimize.
Post reply on HN