@SpaceTurtle224 you're "looking for" and easy answer to a question you can answer yourself easily. Your "question" did not even specify what your looking for.
@SpaceTurtle224 Why not just Google? You'll find plenty of what you're looking for, and much quicker than waiting for that one person willing to answer your lazy "question" (which isn't even a question).
@ericjmorey Except it's outdated. Here, I'll write a new paragraph for you: "When you start to learn Python, start with Python 3.10. If you at some point come across an codebase using older versions, you'll have learned enough to get to grips with the differences outlined in Python documentation." There, that's all you need to know.
@ericjmorey Why are you copying part of an article you've already linked to? I'm not sure what your point is.
My point is very simple: don’t spend any time on even considering Python 2. The fact the author spent so much time on it shows it's quite an old guide. (The dates in the git repo confirms this.)
@ericjmorey any guide that even mentions Python 2 is probably outdated and should be met with caution.
@Chais from module import \* should almost never be used anyway, so...
@Sigmatics Habits can be unlearned over a few generations. Doesn't mean in becomes practical all if a sudden. It's just messy to say "I'll do this tomorrow" when "tomorrow" might mean "before I go to bed".
"See you Monday!"
"Eh, before or after sleep on Monday?"
It's just not viable. It requires us to think differently about what a date is, returning the original issue: different people living at different dates.
@Sigmatics you can have everyone on the same time zone and still have different day/night cycles. It just means you have to get up at 14:00 and go to sleep at 5:00. The big problem with this is that the date-switch happens for everyone at the same time, which means you might have breakfast on Thursday and lunch on Friday. That makes it terribly inconvenient, and therefore probably unviable.
@BeardedGingerWonder will you adapt your time to be 7 hours later?
Thought so.
@sugar_in_your_tea Using asserts in any code except testing is frowned upon, afaik. You should use specific exceptions instead of vague unlabeled assertion errors.
You also seem to think that you're not allowed to use exception to communicate the fact a check failed. If that's the case, you're seriously underusing the power of exceptions.
It sounds a lot to me like you don't even want to use Python or think it shouldn't be used for anything serious. Why then even argue about it?
@sugar_in_your_tea I don't think we should change any functionality when it comes to exception handling. Code based documentation would be great for type checking and auto-generated docs, but they can be done using annotations, not changed interfaces.
Monads are already possible, but should not be the normal way to code either. It's clunky and difficult to understand. It might work great for some scenarios, but doesn't for many others.
@sugar_in_your_tea Since when is Python supposed to equal pseudo code? It should be easily readable, but that doesn't mean it should *equal* pseudo code.
You can either test for values being 0 before dividing, or catching an exception when it is. Especially when dividing multiple times in one function, I would go for the latter option.
@sugar_in_your_tea But isn't all that possible in Python? Don't monads cover exactly what you want? Why does it need to be implemented some different way?
Also, divide by zero should be data just as well. Failing to program around having nothing to divide by is not a reason to have a program panic.
Also, having two systems for largely the same behavior doesn't seem to improve usability and clarity, in my opinion.
@sugar_in_your_tea I'm by far not qualified to discuss this in depth. But it seems to me that almost every function call ever can fail. Therefore, do you need to do this with every single function call?
That seems terribly inefficient and bloated. How is that readable for anyone?
@sugar_in_your_tea The idea of exceptions is that you can choose when to deal with them. So if you want to deal with them immediately,
nothing is stopping you.
If you think handling errors with every function call explicitly is easier, I guess you're using very few functions. For the project I'm working on, your proposal would probably double the number of lines. Thanks, but no thanks.
@sugar_in_your_tea If you're expecting exceptions, make custom ones. That's the best way to distinguish between those you expect and those you don't. Using custom exceptions improves readability too.
@onlinepersona It looks sleek and says it does everything. Reason enough to keep away.
@danielquinn agreed! You can work around the performance issues by wrapping it in a function.
@nikaro iterable means: has __iter__() method. So there's no real difference, as far as I can see.