Live data from Hacker News

Python socket programming tutorial

binarytides.com

21–22 of 22 posts

Re: Python socket programming tutorial

#21

Earlier quoted context omitted.

As a python newbie, I couldn't disagree more. I would have saved hours while working on (and possibly completed) the recent Stripe CTF. Frankly, I started to dislike the python docs thoroughly. However, I'm very much looking forward to the much-rumored new docs--I very much dig the language. As an example to my point, however, look at the two side-by-side as an aspiring tinkerer with the desire to send data over a so…

We may have an unreconcilable difference in philosophy here. I understand there is value in jumping straight to code, but I find real value in a (good) treatment of the model you're coding against before jumping in. Both tutorials are good, but I think a Python programmer totally new to network programming, which is the audience of the OP, is better served first reading that HOWTO before following the code samples...

Understood.

For me, I just can't learn that way--that's surely where the discrepancy is. I've never been able to, say, read one of those O'Reilly programming books all the way through (though I have bought a couple with the best of intentions). I just have to start playing around. It's probably not the right way, but its served me well. I think this is why the python docs don't work for me--they don't seem suited to that type of learning.

Re: Python socket programming tutorial

#22

Earlier quoted context omitted.

The point is (or should be) to learn how socket programming works so you know what's going on under all that abstraction and why. That's also why we catch all those exceptions: so we understand why something failed, and how to deal with it in the future. It's also really fun to write complex networking apps from scratch =)

If that was the point we should all break out our chemistry sets to refine elements so we can create our logic chips and build up from there. At some point you have to admit you've climbed down enough turtles and it's time to get some shit done. I'm claiming ZeroMQ is far enough down. It's not that much abstraction. It's mostly avoiding you the annoyances and giving you framework of best practices.

First of all, ZeroMQ is fucking tons of abstraction. It's its own wire protocol. It does crazy advanced things that it would take you forever to figure out and re-implement. It's nice.

You also don't have a clue what it's doing or why, which means you don't have a clue what your program is doing or why. In general it's thought of as a good idea to understand these things.

At the very least learn the tcp/ip stack and why all of the complex things are the way they are. Learn why building a long-distance fault-tolerant fast reliable network protocol is hard. Learn why there's many things that can cause your application to fail to just connect to a remote host. Heck, just learn the differences in different operating systems' tcp/ip stacks and why they are that way. Just using the same framework everywhere isn't going to solve all your problems for you.

Post reply on HN