thx, saved me 15 minutes

thanks, 15 minutes saved

*1. raise NotImplementedError instead of … *EDIT: this was fixed*

*args instead of *strings

Not all heroes wear capes

I am a C/C++ enjoyer and I do not like that. If you need a statically typed language, you should just use one instead changing Python to resemble C++.

@@vamastah1737 i don't want a statically typed python. i want to force typing on input variables and return. it just makes debugging developing and documentation easier. i have used python, but only in a project for my master (i don't count the projects in which you use python to do ai or image processing and similar things, i am talking about application development). i like the language. it is easy to work with. easy to prototype. it is a great language. however the amount of times that i have suffered debugging line 1003 on a random library because i was allowed to call a function with the wrong input variables is let's say not zero. having the ability to force the type of variables in when a function expect specific function from the object in the input is a good thing, that makes the code more readable

@@hellNo116 well, true, but there are more issues like that in Python and they are solved in statically typed languages by simple syntax checking before actual run. Python got adopted to applications it was not designed in the first place and hence the issue.

@@vamastah1737i will not argue on that. it is true python was not meant to be a application language. however it happened to be because of circumstances. and it is really strong and capable. so i don't know if we can simply ignore it. also its syntax and some other feature that are inherited to the language seem to be the favorites of many python programmers. all i am trying to say is that python has legs and it is not the worst language for what we are using it for.

@@vamastah1737 no. Python with types is the best way to program.

There's a German book called "Weniger schlecht programmieren" (How to program less badly) that has quite a few fun examples of useless comment. Not sure if there's an English version.

Real.

disagree with the "devs shouldn't have to scroll to read the whole function". It is much better to scroll a little and read the whole function, than to jump around the file trying to find the helper function implementations. Internal functionality should only be abstracted to another function if it is going to be used more than once. If not, it just makes the code harder to read.

Do you mind sharing a snippet here regarding what you mean? I didn't quite understand, but am curious to see what it looks like!

yes please I also curious about that thing how you use the iterable. ?

​ @Indently Basically I would rather use "strings : typing.Iterable[str]" instead of "*strings" because it's less complicated and I think it's more readable . As for the second part of my comment I just wanted to ramble about how I last used the *args thingy .Not actually relevant to the discussion..... I automated some browser game and i wanted to be able to do thing while the program was executing a "time.sleep" . So the easiest way to do it that came to my mind was "a="spU9INjHN " . And i generate those functions this way : b="7XDxKTXWN" .Links on "onlinegdb" because i have no idea how to link stuff on yt .

It means I would rather use "strings :typing.Iterable[str]" instead of "*strings" because it is more readable in my opinion . As for the second part of my comment it's kind of irrelevant , i just wanted to talk about how i last used the feature . I automated some browser game and i wanted to do something while the code was executing a time.sleep . So i wrote this : oEOt6J0JM . And i generate the code this way az2r951Ss . The code snippet is hosted on onlinegdb , i dunno how to share links on yt.

​@@IndentlyI think @hriscuvalerica4814 want to say that its more readable when a function accept a list for example instead of accepting an infinite amount of arguments because it is more explicit for the user

It is not always the best idea to use a for-each approach. I developed on python for 2 years and this type of loops implies that you cannot use the full potential of a condition. For example: if you want to execute a for loop only on certain conditions you can't do that in python without declaring before or inside the loop an if statement. This could seem better in terms of readability but if you want efficient code this is not the best. I had to solve this problem with a function called takewhile that takes a predicate and the list of items, but calling a function everytime i need a value is not a good option if I already have all data

some documentation generators cant infer types based on hints, and you have bigger issues if you forget to update docs accordingly, in my opinion.

@@lydellackerman800 That's a really niche case for whoever uses the subpar docgen specifically. It's not so much to do with forgetting to update documentation but more so propagating bad practices, it's like specifying the types in documentation in a statically typed language it's just redundant, remember DRY.

@@senzmaki4890thats a fair point. I was wrong

Pep8

@@replikvltyoutube3727 but so are all of his other videos. Doesnt make a difference. A video form of ideas reaches more beginners then pep8

@@replikvltyoutube3727 *a summary of PEP 8.

word

​@@Indentlysentence

generally when using this you don't type annotate it, but if you want to, i guess you can just type it as typing.Tuple[str]

*strings: str (answer)

He's using type hints. Lookup explicit typing for more in depth information. But by specifying the types within this dictionary you can gain af advantages. First. The code becomes easier you read. You explicitly stated what the types of variable will be, instead of letting python infer it at runtime and thus it never being mentioned directly in your code. Second, if you were to screw up later and try to pass a string into the dictionary key, (where an int was specified) a good modern IDE should warn you about it. Potentially saving debug time later. I'm probably missing more stuff but that's what comes to mind.

Slash means that the name of arguments after the slash don't matter. I'd use it for anywhere the names do not provide any meaning, like for example with mathematical functions: while the argument is typically named x, a, val, arg etc., this name is completely useless for the caller. exp(x=2) is much worse than simple exp(2)

Thanks, @@vytah.

which is why you should never write a function that returns a complicated interface, unless it has a leading underbar in its name, and even then....

Python is executable pseudocode. Same with Haskell.

What's important is that you return something meaningful. dict[int, str] might have been a bad example :)

@@Indently Sorry for using your example as my example. I understood your point about commenting. What bothers me more that I cant formulate a coherent rule of when documenting a function is redundant. Or, does it bring some kind of help somewhere I'm not aware of?

@@Mefodii Documenting a function is never redundant. Think of it that way. You have a very simple function and you think it is obvious what it does, right? Well, from experience, to some people, it really isn't that obvious and they really do need that documentation in a language they are more accustomed to (beginners, usually). It also teaches them how to start documenting their own code as they read simple functions and progress to more difficult ones. Basically, you aren't documenting a function for yourself, but for others, who might not be on your level of coding knowledge. *P.S. Documenting variables is always important, even for you. User_info might be clear enough now, but if you come back to it some time later... @param user_info: Dictionary with personal information, example (example has to be valid): { name: Tony, age: 23, address: USA} is much clearer than no info at all and a debugging session. (For other people as well!) P.S.2. This now means that you have a lot of stuff to update if you change something...so as always, its about tradeoffs. In a team, it is usually very much worth it.

It had to be made public eventually

That is PyCharm.

That is not VSCode, it's PyCharm or IntelliJ Idea. I think the usages come default in that editor.

Inlay hints on PyCharm

Thanks. I found your setup video.

Why not use mocks instead? That way you can separate what's ready and working and what's just for testing.

His KZfaq profile says he's from Denmark if that helps

def func1(self) -> MyClass: return self

@@archardor3392 It gives not implemented error

It's type hints Just hints, they do not provide any contact over the actual variable type

Type hints are just for static code analysis. If you want to perform real type checks and throw exceptions when they don't match, you have to do them yourself. Like using assertions or throwing exceptions when a type doesn't match.

Type hints are the same as comments, they do nothing when you execute the code. If you're using a powerful IDE it'll warn you when the types don't match but it will execute anyway

I recommend not doing it because you don't find it beneficial for your own purposes. Otherwise not doing something just because people recommend it is a bit silly :)

He didn't mean that you never implement it, just that you can have defined several empty functions, for example to name them in the main function and have a global picture of the code in it, and after you write the code of each function independently to make them reusable. It is then possible to forget implementing one of the functions in the process, it is then useful to have the code tell you that when testing

@@dragweb7725 When testing, won’t the expected value not be present because you passed the function and therefore the test would fail causing you to inspect the function causing the failed test?

@@Nerdimo it's not that easy sometimes, I've seen functions using either "pass" or "..." in an SDK of my company, which in turn uses some third party APIs, and debugging that can get hard since there are many layers and you don't know what kind of error is gonna be raised (if any).

@@juanjosefarina Aha, so it's really an issue as a code base grows larger and larger. I can see how that gets annoying. I've only used NotImplementedError for abstract classes, but I can see we're it's useful in general SWE.

Would be nice, but that's only valid if you're using an OOP approach.

kwargs allows you to pass a variable number of arguments that you haven't explicitly defined in your code yet

*args get transformed into tuples, **kwargs into a dict. As per usual you aren't allowed to use positional arguments after keyword arguments.

That's absolutely fair, but as usual, my example was just for demonstration purposes.

Well, considering A has an invalid type annotation "dict[str: int]", I'd have to select B in this case (if you're curious about how annotations work I recommend checking out the Mypy docs for correct typing :) ).

@@Indently thx, but I'm secure af and only use 3.8 on the job. Higher version aren't approved so I can't check the newer features. Haven't had the time to get 3 on the to-be-replaced Mac at home, since my personal lib in 2x is huge.

That's completely fair, if I had your certainty I'd probably also skip on annotations completely.

@@Indently Well I use them in 3.8, just the nested ones aren't implemented. I think they are good if you have functiond that takes a custom class, but that really only happens when two classes are cooperating (dangers of inappropriate intimacy notwithstanding), since classes have method to work with their attributes. So far, I'm 30/70 on whether to use them with primitives.

Is there a way of declaring a type like the typedef in C ? E.g. typedef mytype1 dict[str: int]; Then you could refer to mytype1 in all relevant places...

Pycharm

what does it mean?