@jeremyparker Note that for people new to a language it's much harder to distinguish between old and new than someone already familiar with the old. Don't push old on people starting out.
This is starting to feel like arguing kids should learn Latin because it might help them understand medical terms better. Sure, that's true, but a) it's only useful for a small subset of learners and b) is it worth the effort to learn an entire language just for some minor details?
@jeremyparker Those are all valid. But not in a starter guide for someone looking to learn a language. If and when you get submerged into a legacy project you have all the time to find out what's what. But teaching someone outdated syntax and features just because they *might* come accross them maybe is a terrible way to teach.
@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.
@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 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.
@jeremyparker As for myself: I use Python as a scientist on an almost daily basis. I've never learned anything about Python 2, have never touched it and never required it. Maybe if you work in a field with tons of legacy code it's useful, but I and all my colleagues are working with Python 3.7 or newer (mostly 3.10 and newer) only. There is no single argument you could make that would convince me I or any of my colleagues should know *anything* about Python 2.