A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2003-February/033233.html below:

[Python-Dev] vox populii illiterati

[Python-Dev] vox populii illiteratiSamuele Pedroni pedronis@bluewin.ch
Sun, 9 Feb 2003 18:25:24 +0100
From: "Tim Peters" <tim.one@comcast.net>
> [Neal Norwitz]
> > ...
> > One thing to note, many people are saying you can currently do:
> >
> >         cond and true_value or false_value
> >
> > However, many have gotten it wrong, either by reversing the true/false
> > value or by using something in the true_value which may be false
> > (sometimes even constants).  pychecker tries to find this condition
> > (when true_value is a false constant), but it does a poor job
> > of determining the idiom IIRC.
>
> Indeed, that's been the most amazing part of the discussion to me.  Not so
> much the form above:  everyone gets that wrong in the case true_value may
> actually be false, but I don't agree they're prone to swap the values.   But
> *virtually* everyone got the order wrong when rewriting examples with the
> weaker
>
>     (false_value, true_value)[cond]
>
> variant (they swap the values in the tuple).  That's evidence that the
> expression-like workarounds don't really work for real people.
>

does that mean that all the _ and _ or _ in the std lib have been written by
bots <wink>?





RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4