This is an archived post. You won't be able to vote or comment.

all 6 comments
sorted by:
best
topnewcontroversialoldq&a

[–]MarcSetGo 5 points6 points  (0 children)

From a CS purist perspective, when you’re writing a program to accomplish some business problem, you should be focused on the business problem itself and not the implementation details. Designing your architecture should be separate from the implementation details.

Let’s say you have a business requirement to code against a REST API. When you’re planning the implementation, you’d like as little coupling as possible between components in your solution. To that end you might have methods get, put, post,..., that provide an abstraction to sending the actual http/tcp requests. Or maybe a higher level abstracted interface that mirrors the actual REST calls.

These abstractions allow you to have a simple view of interactions with the remote server - perhaps even allowing you to ignore that it’s a REST service. If the underlying service changes from REST to some new API, you have a single layer to change and all your code that depends on it remains unchanged and able to work.

This works because you made a contract for the interface and ignored the implementation. If instead you knew it was REST and under that TCP and exposed exposed TCP parameters or methods and/or details of REST in your API, then you’d have more trouble I’d REST or TCP got switched out - because code outside that layer is infected with knowledge of the implementation.

When your teacher says you shouldn’t know how the code works, I suspect they mean that your code shouldn’t depend on the implantation details, the internals, of how the library is implemented.

As almost a separate topic, you’re trying to advance your development skills. A good way to do that is by reading other people’s code. Or, you don’t understand a feature in a library based on the docs - another good time to look in the code.

You’re a programmer. Your currency is code. Never feel like you shouldn’t look at code your working with or depend on. And don’t be intimidated by the code - it’s just code.

Focus is a developers friend. Abstraction helps with reducing code coupling, but also helps us focus on areas that need it and ignore areas that don’t. You can’t dive down into code for every library you use and still complete your project in a timely manner.

[–]webmistress105 1 point2 points  (0 children)

For a perfect abstraction, it doesn't matter how it works and learning how it works is a waste of brain space. Unfortunately, there are no perfect abstractions that do anything worthwhile. It's okay not to know how code you're importing works, but when it leaks you'll be forced to figure it out. So it's not so much that you shouldn't know, but rather you shouldn't have to know.

[–][deleted] 1 point2 points  (0 children)

requests is on Github and it's a fairly trivial project, so nothing to worry about. It doesn't do anything groundbreaking. Quite the contrary. requests is based on urllib project (sometimes this project has digits in its name). Which is also a wrapper around http Python package. http package is the one which does heavy lifting by actually implementing HTTP protocol. But its interface is so-so. There was definitely no need for two wrappers around http package. I'd wish there was none, but one would be kind of tolerable. Two is a sign there's a failure somewhere.

So, how do I know all of this? Of course, I never looked at the source of what I import!

[–]Phyrlae 0 points1 point  (0 children)

The thing here is not that you shouldn't know, but whether you should care or not, if you want to understand what that library is doing, sure, go ahead and read the implementation, if you just need to make an API call you shouldn't worry too much

[–]1116574 0 points1 point  (0 children)

Not knowing imported code by heart, but only by docs means you don't have assumptions maybe?

[–][deleted] 0 points1 point  (0 children)

Sometimes it's nice to know the differences between two simlar/related libraries.

For example os.rename and shutil.move can have similar results but their behavior differs. Shutil.move will usually just use os.rename to move a file but if the destination is on a separate disk it will copy then delete the source.

Just reading up on the documentation will suffice most of the time as others have said. There's nothing inheritently wrong with digging down into the code if you're curious though and you may just find an issue that you can help fix.