Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
Steven D'Aprano
steve+comp.lang.python at pearwood.info
Sat Apr 5 06:19:01 EDT 2014
On Sat, 05 Apr 2014 00:02:58 -0500, Mark H Harris wrote:
> Having said that, I do believe that the migration to C python3 has
> been too conservative.
Why? Is it a race? Does Python 2.x turn into PHP at midnight?
Some people think the move to Python 3 has been too radical and too fast
for them. Are they wrong?
> Nobody wants to maintain a fork, not really.
There will be no serious fork of Python 2.7.
Oh, I dare say that when the core developers finally announce Python 2.7
is end-of-lifed, probably in another five or so years, there will be a
flurry of cheap talk about forking Python, and maybe even a few
"Python2.8" projects on Github. But nobody will use them, and they will
fade away into obscurity. I can't see *anyone* with the necessary
resources taking on the job and gathering enough community support for a
successful fork.
With perhaps one exception. Twisted has apparently said they cannot
migrate to 3.x. They might, I suppose, take up maintenance of Python 2.7.
But I doubt it. I expect that when push comes to shove in 4 or 5 years
time, they'll find a way to migrate.
Python 2.7 will continue to get paid-for support from RedHat until 2024,
and I expect that there will be companies like Activestate that will
offer extended support for Python 2.7 for a few years too. But that's it.
> I don't think its something anyone should be afraid of.
Nobody is *afraid* of a fork. But forks do split the community, and
introduce FUD (Fear, Uncertainty, Doubt), except for the rare occasions
like the XFree86 to X.Org fork where the entire community moved almost
overnight to the fork. That was a HUGE vote of no confidence to the
original maintainer, and (so I'm told) deservedly so.
Nothing like that is plausible with Python. There simply isn't anywhere
near that level of dissatisfaction with the way the language is being
managed, mild grumbling from a few people aside. Most importantly, the
core devs have been *very* responsive to people's complaints.
> Somebody should
> put a date on C python 3.4+ migration and cut off support for 2.7.x/
2045-04-01. If you're not migrated to Python 3.4 by then, no cake for you.
A date will be set when the time is right, but rushing to set a date now
when we don't know the state of the language in five years time is just
silly. It is expected to be five years from now, but if there is a flurry
of migration activity it may be brought forward, and if five years is not
long enough it may be delayed. *May* be delayed.
It's fine if people don't migrate to 3.4. Waiting until 3.5 or even 3.6
is perfectly acceptable too. Leaving it to 3.7 (expected about 5 years
from now) is probably okay too. The longer you wait to migrate, the
easier it will be: migrate when the benefit of migrating exceeds the cost.
(I'm talking about application-level projects here. Libraries and
frameworks are somewhat different.)
Each point release of 3.x has added not just new features to entice
users, but new features (and sometimes old features) to aid in porting.
For example, some things that had been dropped, like the callable() built-
in, were re-added in 3.2. 3.3 re-added the u'' syntax solely to aid in
porting from 2.x. There is a lot of discussion going on to make it easier
to deal with mixed bytes and ASCII text, which is a very important use-
case which by accident was suited well to the Python 2.x byte-string
model, but not well suited to the Python 3.x unicode-text versus bytes
model. You should expect that to come into production in 3.5.
> Its
> just an opinion. If 'Twisted' isn't ready for 3.x, well, they need to
> get ready.
Are you volunteering to do the work for them?
> That's also just an opinion.
Ah, but is it an *informed* opinion? Do you know why Twisted say they
cannot migrate to 3.x?
--
Steven D'Aprano
http://import-that.dreamwidth.org/
More information about the Python-list
mailing list