Live Code Review | Requests
HTML-код
- Опубликовано: 15 ноя 2024
- 💡 Learn how to design great software in 7 steps: arjan.codes/de....
In this live stream, I'll dive into the code and design of an open-source project together with you. This is going to be completely unscripted, so you'll see my real-time reactions to the code and how it’s been designed. It's a surprise which project I'm going to be reviewing (also for me! :) ).
🎓 Check out my courses: arjan.codes/co...
#arjancodes #softwaredesign #python
Your videos are very educational and useful. I always learn from you, thank you very much my friend.
Really like these types of videos where we deal more with design and architecture. Once you master the syntax of Python this becomes much more important. Love to see more.
Glad you liked it!
A 1 HOUR VIDEO???? THANKYOU!!!
Awesome video! I love how spontaneous it is, and the way you describe everything on the spot without any preparation. Keep up the great work!
Glad you enjoyed it!
Really enjoyed this new format. Thank you so much for it!!!
But it would also be exciting to check out the same videos but not streams (when the library was not randomly chosen and with deeper explanations of what was well designed in a particular library and so on)
Thanks for the suggestion! I'm glad you like the format :)
I think these livestreams would be a good time and place to revisit some of your older code examples and update them in some way. For instance: new generics, unit tests, code refactors, etc. Basically, I'm just thinking about that next step for whatever code examples were used 2-3 years ago that could maybe use some updates.
Thanks for the suggestion!
great video, thanks a lot!
please continue with this Under the hood series, it is really educational
That's the plan!
@@ArjanCodes great, looking forward to your new videos!
I don't think instance checks are necessarily bad.
There are valid cases for changing function behavior depending on input type.
A good example is writing an interface class for a SQL database that implements a __getitem__ that allows the user to pass a single field to get that field as a one dimensional list or a sequence of fields that returns a 2 dimensional list of field values.
You can even add a third check that allows integers to be used to return the rows with primary keys in that sequence.
This is a pretty specific example though, but I don't think it's all that uncommon. It allows the end user to just interface with the SQL backend using the __getitem__ syntax and avoids having to use a ton of different named functions.
This can obviously be improved by relying on other types that handle those specific queries that are then passed to the SQL interface class so you aren't reliant on the builtin types (e.g. Fields, PrimaryKeys, Field, etc.) so you can have more control over the behavior.
I'm curious about the comments about isinstance, as I have recently been trying to simplify a series of magic methods in one of my classes that currently heavily depend on them. For example, the "__add__" method should behave differently if you are using Class1 + Class1 or Class1 + int. Do you have any suggestions for how to handle this? Or should these be kept in separate methods?
About session and adapters: The idea here is, that you can use other low level HTTP libraries, that you only need to provide an adapter for. And you'd subclass Session and modify the init for that. This isn't really a standard use case of requests. I had tried that once in order to speed up requests. Unfortunately, lots of the overhead is happening on top of the low level adapter, so it was of no use.
I want to know where there are type hints written as strings
Oh man I missed the live stream again!
good stuff tho I love this series ❤
idk if you have already did that but I would love to see NumPy or Pytorch.
EDIT: can you make a series for reviewing our repos?, it could be fun and very helpful and you can roast us too 😅
That's a great idea! Keep an eye on the next livestream ;)
Came for the code; stayed for the code!
Would it be better or even possible to use mocks or something instead of building a test server? Seems like the possibility to implement issues in the server could ultimately propagate up to the test code as ‘ok’. I love the idea of TDD, but I’m really really bad at it in practice because of problems like this. I do a lot of network programming.
Great observation. I think the key here is to stay focused on the kind of test being written.
If writing "integration" or "system" tests - my best guess as to the context of what you point out (unexpected code of "ok") - would probably need a test scenario simulator. I have written a number of these over the years, some generic tools, some were app specific. In there you add code to simulate the response of the server/service being connected to - completely. i.e., including OK (200), 4XX, 5XX, etc. response status codes.
Note these get really fun and maintainable when you can make them data driven to reduce the amount of code and reduce entropy, coupling and increase cohesion.
For example, one API service simulator I wrote simply recognized route paths and used JSON files to provide responses - including status codes and error messages. It was a breeze to maintain by the testers themselves (separate QA team). They simply automated the configuration of the app to point to the simulator instead of the actual service, providing the path to the library of JSON files to use for the scenarios being tested in that session.
In some edge cases additional logic was added to detect when a route was hit first time, Nth time - or when a particular data payload was present. It sounds more complicated then it was. We got a lot of mileage out of that tool - and caught a lot of bugs before they reached production with it!
How can I read a pfx certificate with urllib3?
The reason behind the multiple inheritance in some of the exceptions probably have to do with backwards compatibility. I.e. in later versions you start raising NewException instead of OldException1 and OldException2. To make it easier for old code bases to upgrade to the new version of the library you make NewException inherit from both OldException1 and OldException2. That way the old except-statements will continue to work.
Good suggestion- that might be the reason indeed.
Nice stream, thanks a lot.
I have a question
What do u think about singledispatch decorator in 28:45?
The code will be like that:
from functools import singledispatch
@singledispatch
def check_cert(cert: bool) -> str:
if not cert:
return "No cert"
return "Cert"
@check_cert.register
def _(cert: str) -> str:
return f"Cert path: {cert}"
def main() -> None:
print(check_cert(True))
print(check_cert(False))
print(check_cert("/user/bin/cert.pm"))
if __name__ == "__main__":
main()
In 16:26 you mention more strict annotation types, would you use pydantic or something else?
He means more restricted. That is, rather than it being any of a bool or string or None, let it just be a bool. Or let it just be an optional string. Etc. That way don’t have to check types at runtime.
Arjen carves into one of the most popular Python packages and ends up making a roast 😅
I had to work on a project with similar design issues. Mixin using higher class methods. Code in the unit.py etc etc… It was a pain to understand. We actually decided to rewrite the code. It appeared that 80% of the code could been removed 😅
Crazy to underhood a lib like requests, and find such things
Could you fix the bug?
Yes, it’s gone now, haha.
Very nice video idea!
Sklearn next! :)
Thanks for the idea!
Now we also need to fix bugs in our noses)
you should use some tools to extract visual diagrams of high level architecture and not just digg in code here and there