I was kinda expecting this response. 
Somewhat, but the key differentiator is that the assertion is optimized out locally based on the assert, and not globally for all my code and all code that my code depends on, and so on…
So having a way to write some assertions so that they don’t follow the global default behaviour would be sufficient? How about using
if not CONDITION: raise AssertionError(MSG)
for the ones you want to prevent being optimized out?
8 Likes
(I get the feeling I’m being made the butt of a joke here, but I am truly, earnestly just trying to suggest that we can discuss whether a change could be made to help with beginners to the language)
I think you may have forgotten the context here, which is that people (mostly beginners) dont always think about the fact that the global default behavior is toggleable. So, again, the suggestion is making the default beginner-friendly and allowing those who have gone beyond “beginner” to choose how they want to proceed.
So acknowledge the retort, but I don’t think it acknowledges the truth behind the proposal. If Instagram avoids asserts because a developer fell into “the trap”, and they aren’t alone, I think this is worth discussing.
I understand you disagree, but hopefully we can keep the discussion going weighing the proposal, and background, seriously and with info shared in-context
3 Likes
I can’t tell what’s going on or what sides there even are in this topic anymore. Many people are pretty clearly against it, or for it, or swapping between the two, which suggests there’s no consensus to change the current behavior. People keep proposing other ideas and hypotheticals, making it hard to follow what the current state of the idea is. I think the course of action at this point is to create a PEP so that a specific specification and reference implementation can be discussed and have a decision made about, rather than going all over the place.
2 Likes
Not the butt of a joke, precisely, but the point is that you’re arguing about asserts (again) when what you are actually proposing is to deprecate -O. It’s very hard to understand your point when you keep changing the focus, so we’re reduced to slightly confused rebuttals of the immediate point.
If you want to deprecate -O in favour of having explicit optimisation options, then:
- Say so, explicitly, and stick to that proposal.
- Address the question of how this impacts people currently using
-O, and in particular, using it correctly. Don’t dismiss their use cases as not relevant, or assume they are happy to change their (currently working!) code. Acknowledge the costs. Quantify the benefits, and compare the two. - Don’t keep explaining how people can “fix” their asserts. We know, it’s just that having a way to do so doesn’t mean the cost vanishes. Quite the opposite - it means you’re saying that code does need to change, but you’re dismissing the cost.
If you want to pursue this, as @davidism has said, you’re probably at the point where you need to write a PEP, expressing your arguments in a standalone document, taking note of everything that’s been discussed here so far and addressing it. But for a PEP, you need a core developer to sponsor the PEP, so you should start by trying to find a core dev who supports the idea (or at least, supports taking it through the PEP process). But while I haven’t checked every post, I don’t recall seeing any core dev speak in support of this proposal, so you may have a problem there.
Otherwise, drop the matter. Accept that you’ve made your points, they were listened to, but you didn’t convince the right people. Move onto a different discussion that interests you. If it still matters to you, come back to this idea later, when there’s new information to offer, or circumstances have changed. But accept that for now, the debate has run its course.
5 Likes