Any chance for reconsideration of PEP 335?

[dg-pb]

@ncoghlan

To address the specific question asked in the title of the thread:

• reviving PEP 335 directly has essentially zero chance of success, since the rationale for its rejection is still valid

Thanks for this. And when you say “PEP 335”, does it apply to this specific PEP or “any form of logical operator overloading”?

@ncoghlan

It’s also worth noting that PEP 532/535 don’t fix the problem @gcewing mentioned

This is one of the reasons I took a step back to PEP 335.
PEPs 532/535 looked fairly complex in comparison while achieve pretty much the same thing, but from certain POV even less.

@hprodh

@Rosuav

If you DON’T want it to short-circuit, why do you want it to be written as a or b rather than a | b ?

Totally legit. I think if you want to do such specialized stuff, you better use explicitly specialized operations, because you can specialize yourself in understanding the specialized ops, and leave the general operators alone.

Maybe, maybe not.
If it is possible to achieve something without adding to syntax it is a plus.
Also, if extension to achieve new things makes use of existing syntax while retaining consistency in meaning - it is a big plus.

So in no way I see this argument as “winning by default”.

Yes, from POV of DSL only, leaf problem makes it not very attractive, but there are 3 underlying things behind this:

1. numpy.array() or numpy.array()
2. 1 < numpy.array() < 2
3. Simple DSLs: maybe(a).attr or maybe(b).attr

To me, all of these are of interest to address if possible.
If there is an extension that can address all of these without introduction of new syntax, then the leaf-issue could be a reasonable cost compared to alternatives. And for cases where this issue is a deal breaker, then one should indeed needs to look for alternative solutions, but it doesn’t necessarily invalidate benefits of this.

Although PEP 335 is heavy on complications to deal with, compared to alternatives that I have seen, it is very light in terms of syntax and high level implementation design. Furthermore, as I said, it has a very big advantage - nothing else will be able to address (1) apart from itself.

---

@gcewing

I would rather take a step back and look for a different solution altogether. I have some ideas about that, but they belong in another thread.

Would be interested to hear. Maybe Linked Booleans Logics (rethinking PEP 505) could be a good place for it?