Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed1a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <lhk2pi$nnf$1@speranza.aioe.org>
References: <9daf0806-02de-4447-964c-c8f8953c23e5@googlegroups.com> <lgoh7j$otg$1@speranza.aioe.org> <mailman.8440.1395651801.18130.python-list@python.org> <lgq8th$nj4$1@speranza.aioe.org> <87ior3w740.fsf@elektro.pacujo.net> <lgqgn7$bpd$1@speranza.aioe.org> <mailman.8478.1395710470.18130.python-list@python.org> <lgqq99$v5j$1@speranza.aioe.org> <lgtsga$2ei$1@dont-email.me> <lh1h1f$ov3$1@speranza.aioe.org> <5334c38e$0$29994$c3e8da3$5496439d@news.astraweb.com> <lh4ouu$n8l$1@speranza.aioe.org> <53364327$0$29994$c3e8da3$5496439d@news.astraweb.com> <lh5iqs$j0m$1@speranza.aioe.org> <mailman.8683.1396069736.18130.python-list@python.org> <53365F55.2040302@gmail.com> <mailman.8688.1396073027.18130.python-list@python.org> <lh5vq3$c1j$1@speranza.aioe.org> <533836c4$0$29994$c3e8da3$5496439d@news.astraweb.com> <lhb0on$pcj$1@speranza.aioe.org> <op.xdltbjr05079vu@gnudebeest> <lhfatq$hrj$1@speranza.aioe.org> <mailman.8830.1396532123.18130.python-list@python.org> <lhk2pi$nnf$1@speranza.aioe.org>
Date: Fri, 4 Apr 2014 09:43:15 +1100
Subject: Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
From: Chris Angelico <rosuav@gmail.com>
Cc: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.8863.1396565004.18130.python-list@python.org>
Lines: 44
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:69618

On Fri, Apr 4, 2014 at 3:38 AM, Mark H Harris <harrismh777@gmail.com> wrote:
>    'Useful' must always be taken in context, and also contextually evaluated
> with an on-going methodology which constantly informs 'usefulness' on a
> continuum. I admire and encourage the core devs, in their pursuit of
> excellence. Asking 'what is the practical use case?' is essential. Not
> always is the answer complete.
>    On the python unicode continuum version (3) is more useful than version
> (2). ( this is of course relative and debatable, so the statement is
> rhetorical ) The commitment and dedicated effort to move forward with a
> unicode default is not only commendable, but also admits to the 'usefulness'
> of same. Its not that version 2 was useless, its just that version 3 is so
> much more useful that people are 'using' it and dedicating their resources
> moving forward with python3.
>    This is similar to the decimal module. Of course it had limited
> usefulness in version(2) thru 3.2/  but now, python3.3+ the decimal module
> is truly useful! Why? Glad you asked... because it is now fast enough for
> use cases previously reserved for floats. I found limited usefulness for
> decimal prior to 3.3, but now we're finding decimal so useful that some of
> us are wanting decimal to be the default. ( all of this is also relative and
> debatable )

So your definition of "useful" for the Decimal module is "fast" and
your definition of "useful" for Unicode is "mandated into use".
Neither of those is how any dictionary I know defines that word, and
you're not even consistent (since you said Unicode became useful at
3.0, which didn't - AFAIK - improve its performance any, while 3.3 did
(PEP 393)).

Here's one definition: "able to be used for a practical purpose or in
several ways". Does not say anything about performance. Python is
useful in that I am able to wield it to solve my problems. I don't
care that it's slower than C; in fact, a lot of the problems I solve
with Python are interactive, and run to completion faster than I can
notice them. If I use decimal.Decimal or fractions.Fraction in my
code, it is not because it's fast or slow or anything, it is because
that type matches what I want to do with it. Those types are useful to
me because there are situations in which they match my problem. While
I am interested in seeing a Decimal literal syntax in Python, and I
would support a shift to have "1.2" evaluate as a Decimal (but not
soon - it'd break backward compat *hugely*), I do not by any means
believe that Decimal will only become useful when it's the default
non-integer type in source code.

ChrisA