PEP308: Yet another syntax proposal

[Andrew Dalke]

Erik Max Francis
> You [Andrew] keep invoking the frequency argument.  I don't find it
convincing.
> How often are Booleans used? metaclasses? generators? list
> comprehensions?  There are plenty of features in Python that _are
> already present_ that are used very rarely.  But when they are used,
> they do their job with flying colors.

Alexander Schmolck and others (including Andrew Koenig, who I think was
the first to mention it) have said

   Frequency * expressiveness

That is one metric.  Howeve, I've also been trying to estimate the
likelihood
of misuse of the if/else expression.  I think it's fair to estimate that in
the
code I'll be looking at I should expect to see about a 20% or higher misuse
rate.

> The question is whether or not _when it's used_ it serves its purpose.
> You may think that it is never useful, but clearly others don't.  Either
> way, the frequency argument doesn't get either side anywhere.

On the contrary, I have pointed out that there are times when it's
a nice solution to a problem.  My problem with many of the arguments
posted here is they only show good use-cases for the if/else expression
and exclude mentioning that people will use it incorrectly and that
the increase in (readability, maintainability, etc.) needs to be balanced
by the decrease in the metric given the misuse.

Booleans are very unlikely to be misused.  Metaclasses are
very likely to be used.  List comprehensions may be misused, but
have not been that misused to date, though list comprehensions
*with* if/else expressions seem prone to misuse where each
alone is appropriate.

> A conditional operator or form should be short-circuiting, because it
> simply doesn't make sense to go through the trouble of adding one that
> doesn't.  Everyone knows that a non-short-circuiting conditional
> function is utterly _trivial_.  Why bother adding it if it doesn't short
> circuit, no matter how rare short circuiting is?

Adding a standard 'bool' class with instances named True and
False make it easier for code to interoperate because no
additional translation is needed to interface between the boolean
type used in one package and the boolean type used in another
package.

Similarly, were an 'ifelse' function to be added, it would be
a common name and hence people would use it who would
otherwise not create a project-specific ifelse function on
grounds that it creates a project-specific idiom.

                    Andrew
                    dalke at dalkescientific.com